Panel-based Datashader dashboard

[jbednar]

This PR closes #358, #618, and #221 by providing a Panel-based dashboard to replace the current pure Bokeh version that has been broken for several releases now, with the Intake support provided by @jsignell. The old Bokeh dashboard was over 500 lines of code that I was never able to update or even keep running, hence the long period of breakage. This new version fits into 50 lines of code (so far) and has nearly the same functionality, once the to-do items below are addressed:

• opacity (of the data) and spread_size are not hooked up to the control
• the widgets aren't in any order yet
• it would be nice to separate some widgets to be on top of the plot and others down the side, if there is a clear semantic distinction
• colormaps should be updated when the plot changes
• opensky data is not tested
• osm data is not tested and is not yet listed in the .yml file
• the basemap argument doesn't update the map tiles, due to an open Bokeh bug in caching tiles (now fixed in Invalidate TileSource cache on property changes bokeh/bokeh#8594)
• should probably add a logo
• Need to allow field (fare, etc.) to be selected

There are also other to-do items that weren't supported in the last working version of the dashboard:

• Hover info (Hover not showing up in dashboard.py nyc taxi example #252)
• Colorbar and/or categorical legend

[jbednar]

Old (hacked to be runnable, but doesn't show the data):

New:

[philippjfr]

I think I've arranged it so you can simply provide lists and they are cast appropriately.

[philippjfr]

Actually I'm probably wrong about that, I think that was explicitly for dimension ranges.

[jbednar]

Would be good to provide support for such casting if you can, to avoid this awkwardness.

[jsignell]

I think tuple is right and the awkwardness is yaml's fault.

[jbednar]

Oh, it's definitely YAML's fault, or at least JSON's fault (from which YAML inherits its scope). But the fact remains that it's awkward for Python users to write code like the above, so we should probably accept a list as well as a tuple unless we are already using the list/tuple distinction for some semantic purpose in this case.

[jbednar]

Fixed in holoviz/hvplot#248.

[philippjfr]

I've pushed updates to apply opacity and spread_size, however control over global opacity required a small fix in holoviews, which we can push out as part of a 1.11.1 release (see holoviz/holoviews#3371).

[jbednar]

Current version:

Still just 54 lines. Need to add support for selecting which field to plot.

[jbednar]

I've made a number of changes in the above commits:

• Added nyc_taxi_50k to datasets.yml as a quick test case to use
• Updated the .yml file to consistently list "counts" as the first item in the list of plottable fields, as it makes a good default.
• Removed any mention of "fare" from the .yml, because the nyc_taxi parq files don't currently include the fare column. (At some point I need to make new Parquet files including fare and also adding JFK to the visible range of points.)
• Added an "agg_fn" parameter that allows the user to select min, max, mean, etc.

All of that seems fine so far. I've also made some changes that don't quite work yet:

• I changed the .points method to .rasterize so that it could specify the agg_fn, which works but required me to make rasterize no longer be dynamic, which means that RangeXY is no longer tied to this object and zooming no longer updates the datashaded plot.
• I added a "field" parameter, which is populated correctly but doesn't seem to have any effect yet, despite being applied in the same method as the agg_fn and having the same dependency structure.

[jbednar]

Thanks, @philippjfr for re-connecting RangeXY and for realizing that the field parameter is working, it just has no noticeable effect for a counts aggregator; e.g. switch to Mean to see the field having an effect. I've renamed .points to .elem because the plot isn't always a points plot; depends what's declared in the data catalog.

I also reorganized the code a bit and added a very extensive section at the end unpacking how it works. It would be nice not to have to use three different mechanisms for getting the DynamicMaps involved, but I'll open a separate issue about that. Meanwhile, I think it's a very concise and mostly understandable way to express some quite complicated relationships between user-visible controls and computations, and it's a massive improvement over the old dashboard, so it should be ready to merge when tests pass.