Make plot options available to operations?

[jbednar]

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 (#2195, #2398, and #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]

One thing that Jean-Luc is working on is to make it more feasible to use rasterize rather than datashade in more cases, which allows hv/gv options to control more of the behavior rather than using arguments to the operation. But that's only a small step forward, and there are many remaining options like those discussed above that must be given to the underlying operation or they won't be respected.

[philippjfr]

My proposal when discussing this with @kcpevey is that we could start by adding a flag to rasterize/datashade operations that enables usage of options, which a user can enable. If that turns out to be very helpful to users we can then decide whether to enable it as part of a 1.0 release.

[jbednar]

Sounds like a good plan. It's a bit tricky, because we'd want to have all options we ever want to map into the operation enabled when we make it the default, because otherwise behavior will change every time we realize how to map an option into an argument for the operation. Definitely a case where we'd want to be systematic and think about all the relevant options and arguments in one go...

[csheaff]

Hello, in the original post it says "Such information can then be supplied manually to the datashade() call". Is there a guide for doing this? And does this apply to all hv opts?

[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!