Follow-ups on Delaunay/Voronoi

[Fil]

• In delaunay + voronoi #917, the Voronoi mark uses the full frame. As a consequence, it doesn't work well with clip: true (since it is exactly on the clipping path). the way to fix it might be to add a padding (or inset) option.
• Add a curve option on the voronoi cells
• Add a curve option on the hull
• Add a padding option on the hull (see https://observablehq.com/@fil/hull-padding)
• Add an alpha option on the hull (for alpha shapes)
• Create a voronoiLabel mark that does occlusion https://observablehq.com/@d3/voronoi-labels
• Sub-graphs: Gabriel, Urquhart, and minimal spanning tree #941
• The Delaunay/Voronoi/Hull marks require x and y, and a such don't accept the result of the dodge transform. Not sure how to approach this generic issue, but a simple work-around is to specify a fake and empty y channel: Plot.voronoiMesh(penguins, Plot.dodgeY("middle", {x: "body_mass_g", y: []})) (solved by delaunay X and Y are optional #931)
• Delaunay and voronoi can work in 1-d (delaunay X and Y are optional #931)
• would be nice to have an option to clip the resulting polygons with an arbitrary geometry (Clip Voronoi cells to arbitrary geometry? #1635 or Arbitrary clip paths #1109)

[mbostock]

The Delaunay/Voronoi/Hull marks require x and y, and a such don't accept the result of the dodge transform.

Hmm, this is a bummer. 🤔 This is the same issue we ran into in #889 (review):

Since initializers run after mark construction, there’s no longer a guarantee that the mark will know which channels will be available on render at the time the mark constructor is called. So either we say it should be the responsibility of the initializer to indicate that the channels will be available (which this PR does only for the r channel on the hexbin transform, but not in general); or we say that marks shouldn’t assume to know which channels will be available. #891 takes the latter approach which feels a little bit more robust in this regard, even though the constructor is arguably “confused” about what will happen on render.

So, we’re kind of back to where we were. Since the initializer constructs the channels dynamically, if we don’t want to declare the channels statically in the Mark constructor, the only way to know that the channels are missing would be to initialize the mark and apply its initializer (which currently means rendering the mark… there’s no method for just “fully” initializing a mark).

It definitely seems possible for the initializers to declare which channels they will create: dodgeX creates x, dodgeY creates y, hexbin creates whatever’s declared in outputs. So maybe we just have a convention for declaring these dynamic channels so that mark constructors can know what will happen.

[mbostock]

This umbrella issue is over a year old. We should close it and re-open more specific issues as needed.