derive x & y scale domains from geometry

[mbostock]

While writing the documentation for the geo mark, I was thinking about how we can use the geo mark independent of a projection. It bothered me that you can use the geo mark in conjunction with predefined scales, or scales derived from other marks, but that the geo mark itself could not assist in the automatic definition of the scales like other marks.

So now it does. The geometry channel now produces derived x and y channels that can be used to initialize the x and y scales, just like normal marks. Which means you can now say

Plot.geo({type: "LineString", coordinates: aapl.map((d) => [d.Date, d.Close])}).plot()

and it behaves almost identical to

Plot.line(aapl.map((d) => [d.Date, d.Close])).plot()

This is still a draft because I think we should skip constructing the derived x and y channels in a couple cases:

• If there’s a projection (because then there won’t be x and y scales by definition)
• If the x or y scales have pre-defined domains (because then we don’t care about these derived channels)

This changes the behavior of one of the tests, but I think it makes sense, and you can still get the old behavior by setting the projection to identity if you want it.

Fixes #1507.

[Fil]

This makes it much easier to just pass in a GeoJSON file. No more quarter-Earth!

[Fil]

https://observablehq.com/@observablehq/test-1468

[Fil]

follow-up in #1663

[mbostock]

This looks good to me. What do you think @Fil?

[Fil]

🎉 We should now be able to throw any valid GeoJSON file at Plot.geo(…).plot(), and have something show up on the screen—independently of the file’s coordinate reference system (CRS). Plus, the x and y axes will show the extent of the coordinates, which will help evaluate if the file is “unprojected” or “projected”, and even maybe (with a bit of practice) which CRS is more likely.