Improve versatility of Contours

[jlstevens]

Currently, Contour elements accept a single level value, assigning all the contained contour paths to that level. For multiple levels, you need to overlay multiple contours.

The suggestion here is to allow Contours to support a value dimension such that each point along a contour is associated with a value. As setting a value for each point is awkward and memory efficient in the case of iso-contours, there will be two ways of specifying contours:

• Explicit values using a collection of (x,y,value) triples.
• By a single value and a path of (x,y) points. This specifies that all the points have the one specified value. This is similar to the current behavior and avoids wasting memory with redundant values compared to the equivalent in the first format.

There are a few more possible niceties that we have discussed:

• Contours could be used even without specifying values by automatically assigning a value if not supplied. The simplest approach is a simple integer counter - the first path added could have a level value of 0, the second could have a value of 1 etc. This would allow a collection of (x,y) paths to be passed to Contours where they will render with different colors (see Multiple curves plotting is too much work (feature request) #100).
• The explicit format of a value per point would allow some nice visualizations we cannot do now, namely the ability to change color along a path. See this matplotlib page for examples of the sort of effect that would become possible.

Note that for now, I am only considering a single value dimension but you can imagine support multi-dimensional values along a contour as well (a possible future extension).

One other thing to note is that in the explicit format, we relax the notion of a contour from necessarily being an iso contour but I think this is ok as iso-contours will still be the common and easy case.

[basnijholt]

In #100 I asked for the behaviour that is now implemented in hv.Path((x,y)) and I happily changed all my hv.Contour plots to Path's.

Although now I discovered why I was using Contour instead of Path. I use an Overlay of an Image and Contour, such that I can use .select(), unfortunately Path doesn't have the same number of key_dimensions as Image.

Considering the speeds with which you guys implemented the multiple curve plotting with hv.Path((x,y)), could you also do this for Contours?

[philippjfr]

unfortunately Path doesn't have the same number of key_dimensions as Image.

How did you get that idea? Path and Contours are largely identical, both have two key_dimensions and both should accept the new (x, y) signature. In this issue we're proposing changing the behavior of Contours to allow more complex behaviors, so it's probably not what you want to use. What happens if you just use Path? It should just work!

[basnijholt]

Ah, my bad, I did something stupid... All works fine.

[philippjfr]

Great, thanks.

[jlstevens]

There are a few more notes I want to make about Contours, namely that even with this proposal, Contours aren't easily interchanged with other elements (including Tables).

The main issue is that if you tabulate a contours object, there is no way to recover the original contour lines. This is because

1. Tables columns are lexically sorted.
2. You have no idea what the point ordering is along a path.
3. Even then, you don't know if points are connected along the same continuous path or not.

In other words, currently Contours are keeping a lot of implicit information that needs to be made explicit for conversion to work properly. In the end, I think Contours actually need four key dimensions and one value dimension!

contours[<path numbers>, <point numbers>, <x-range>, <y-range>]

This would then be an example of an Element with key-dimensions that aren't completely independent: if you select a particular point, that constrains the x and y positions completely. Although unusual, I think everything would still work.

The path numbers and point numbers would not need to be store explicitly as they can be easily computed from the data supplied in the constructor. The .data attribute would then be a property to compute all the necessary information which would then allow conversion to a tabular format.

This approach also suggests Path could be like Points with only four key dimensions instead of two (and no value dimensions) whereas Contours would be the same with a value dimension. The .data of Path would be an Nx4 array and the .data of Contours should have a shape of Nx5.

[philippjfr]

So this was a long time coming but this is finally done.