The ridgeline plot example doesn’t handle overlapping correctly

[mbostock]

trafficstars

Since 0.6.7, facets are no longer drawn as separate layers, so the lines are drawn atop all the areas.

0.6.7:

0.6.15:

We could use a custom mark to fix this that draws the line within the area mark, so that overlapping facets behave as desired. But that might be a fair amount of work?

[Fil]

We used to have one mark per facet:

    d3.groups(traffic, d => d.name).map(([, values]) => [
      Plot.areaY(values, {x: "date", y: "value", fy: "name", curve: "basis", sort: "date", fill: "#ccc"}),
      Plot.lineY(values, {x: "date", y: "value", fy: "name", curve: "basis", sort: "date", strokeWidth: 1})
    ])

I've now reverted https://observablehq.com/@observablehq/plot-ridgeline to that version. I'm also suggesting an optimized approach in https://observablehq.observablehq.cloud/pangea/plot/ridgeline

[mbostock]

I appreciate the exploration and quick fix to the docs.

The optimized approach seems slower than the notebook version, I think because the filter transform only applies to rendering after all the channels have been initialized — filtering the data beforehand as in the notebook (using d3.groups) saves a lot of redundant computation.

But of course it would be faster still if the area mark supported stroking just the top line, since then you wouldn’t have to compute the path twice for each series. (There’s a similar optimization we want for the horizon mark, since recomputing the area for each band in the horizon is wasteful. Perhaps the horizon mark could also be done more efficiently with a render transform and use elements.)

[Fil]

D'oh! I've now adopted a different approach that is both fast (and I think, readable), by creating the two marks then moving the paths around (to enforce some kind of z-index): https://observablehq.observablehq.cloud/pangea/plot/ridgeline

Agree it would be much better with #1866. We should also probably introduce a global zIndex option?

[mbostock]

Nice, that’s much faster. Because of the way we share properties with G elements, it would be hard to implement the zIndex option across marks & facets (without native SVG support — it was part of the SVG 2.0 spec but that seems dead).