Introducing voronoi new trace type

[archmoj]

Friday's hack and marathon addressing #2221 😎

@plotly/plotly_js
cc: @ndrezn @chriddyp

TODOs:

• Implement cornerradius option
• Improve positioning text and size
• Improve hover label positions
• Adjust few failing jasmine tests

[emilykl]

This is so cool @archmoj . 🤯

Couple of high-level questions:

• Instead of making this a separate trace type, could/should it be a subtype of treemap and accessed (for example) via vornoi=True? Mostly just playing devil's advocate here but curious about what is the line between a new trace and a subtype of an existing trace.

• The multiple levels of hierarchy sort of blend together visually -- for example, the blue and orange regions below each blend together into a single unit even though there are two levels of hierarchy. How can we make the multiple levels more clear?

[archmoj]

• Instead of making this a separate trace type, could/should it be a subtype of treemap and accessed (for example) via vornoi=True? Mostly just playing devil's advocate here but curious about what is the line between a new trace and a subtype of an existing trace.

@emilykl Good question. I also thought about that at the start.
Obviously there are attributes supported in treemap that are not useful for voronoi like the marker.pad.(t|b|l|r), tiling.packing, etc. We could possibly not make them available for voronoi treemaps but its getting hard to document all these details. On the other hand voronoi has options that are not supported by treemap e.g. tiling.shape and seed. Some attributes work differently in voronoi graph now e.g. padding is added to the parents instead of the children to help preserve areas displayed for the children. Treemaps has transition by default but not the voronoi maps. Also this way it would be easier to switch from other traces treemap, icicle, sunburst to voronoi and back. And having this separation help us better design the defaults (initial look) of voronoi graphs, add & document the options and test the functionalities.

[archmoj]

• The multiple levels of hierarchy sort of blend together visually -- for example, the blue and orange regions below each blend together into a single unit even though there are two levels of hierarchy. How can we make the multiple levels more clear?

@emilykl
Users could use layout.voronoicolorway to paint the layers differently.
One could also add an option to help control how depthfade function is working.
I could try to see what happens if for voronoi traces we may revese the fading order as the children take more space compared to treemaps.

[alexcjohnson]

@archmoj very cool!

I'm not totally set on either way, but a couple other arguments in favor of making this a subtype of treemap:

• The name "treemap" itself doesn't say anything about how the regions are packed, so this could just be a different packing type (and we could add others, like circle packing)
• We have other uses of the voronoi / delaunay algorithm in plotly.js today (eg delaunayaxis in mesh3d) and eventually we should support this in more places - for example I'd love to make contour maps for arbitrary xyz triplet data using delaunay triangulation. Calling this "the voronoi trace" implies that this is the only place we're using that algorithm.

And to @emilykl's comment "The multiple levels of hierarchy sort of blend together visually" - I agree, with the parents only visible in the gaps between children, I find it hard to really see the hierarchy. One option would be to expand the parent nodes so that they actually surround their children, similar to how treemap works. I know this breaks the exact correspondence between area and data value, but that was true for treemap as well and we chose clarity over fidelity for the same reason. Or perhaps for voronoi packing we don't show the parent nodes at all, we just decrease the line width as the nesting level increases? That's the approach I see most often elsewhere, and I think it makes sense. As a side-effect though, since we don't have a place to display text for the parent nodes I think the proportions need to be relative to the entire data set rather than each parent. In the image in @emilykl's comment #6987 (comment) there are nine 33% and eight 50% labels but unless we find a way to label the intermediate parents and THEIR proportions, all those numbers should sum to 100% rather than summing to 100% within each subset.