Make plot options available to operations?

Right now, operations like datashade and rasterize have access to whatever is stored directly in an Element or Container, but cannot use the plot options that were specified on that object. In general, this approach makes perfect sense, because the plot options can be specific to the given backend, and something like datashade will work entirely differently from whatever backend happens to be in use. Plus it’s difficult to figure out the options that will later apply on display, for an operation that is called before display.

While acknowledging those issues, it’s clear that this design is causing issues for multiple users (https://github.com/ioam/holoviews/issues/2195, https://github.com/ioam/holoviews/issues/2398, and https://github.com/ioam/holoviews/issues/2609). The underlying issue is that many of the plot options we provide are not simply about trivial tweaks to one plotting library, but are about declaring fundamental facts about what type of visualization this is. For instance, if you set logx=True, logz=True, and color_index='value' on a plot, you get a very specific sort of plot that has meaning across backends. But if you then take such an Element and use datashade() or rasterize() on it, the information about logarithmic mapping and color mapping is lost. Such information can then be supplied manually to the datashade() call, but the benefits of having declared it are lost – the information has to be re-applied every single time the operation is called.

In these cases, I believe that there is a subset of plot options that are declarations about “which data you want to see” (e.g. color_index) and “what properties does the data have” (log...), not simply plotting-library directives (though they are also that). In these cases, I think we should figure out some way to declare that information in a way that it becomes available in the Element so that it can be respected by an operation. Can anyone think of a way we can make this feasible?

[kcpevey]

I don’t have any great suggestions, but this has confused me for a long time. It DOES make sense from code perspective that rasterize/datashade would have no knowledge of the original data or plot options, BUT from a user perspective, its highly confusing - I’m left wondering where my options went or why they aren’t working on this drawing, but they’re working on another (when the difference is simply datashade vs non-datashade). I’d love some method of handling this that was more apparent to users.

[jbednar]

datashade() and rasterize() take options entirely independent of any hv options; they pass arguments down to the underlying Datashader functions, which are implemented by the separate Datashader library that was designed independently of HoloViews or any of the HoloViews backends. So for the moment, you just have to look at the output of hv.help(datashade), etc., to see what’s available and how that maps to what you want to do. To make plot options available to operations we will have to map hv’s options onto Datashader’s options automatically where possible, which will take some time and effort. It’s still worth it, because the only other alternative is that users have to do such mapping every time they use one of these operations, which is also a good bit of effort. So anyone who wants to work out that mapping would be a real help here!