Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make Plot more geojson-aware #1745

Closed
Fil opened this issue Jul 10, 2023 · 3 comments · Fixed by #2092
Closed

Make Plot more geojson-aware #1745

Fil opened this issue Jul 10, 2023 · 3 comments · Fixed by #2092
Assignees
Labels
enhancement New feature or request

Comments

@Fil
Copy link
Contributor

Fil commented Jul 10, 2023

Only the geo mark knows that data can be a FeatureCollection of a GeometryCollection. This makes pivoting from Plot.geo to Plot.dot a 3-changes operation:

Plot.geo(countries) => Plot.dot(countries .features, Plot.centroid())

In the spirit of #1743/#1744 we could have all the marks:

  1. accept geo collections as data, and add a geometry: d => d option
  2. apply the centroid initializer if they consume x, y and there is a geometry (and no x, y or frameAnchor); similarly, apply a bounds initializer if they consume x1, y1, x2, y2 and …
@Fil Fil added the enhancement New feature or request label Jul 10, 2023
@mbostock
Copy link
Member

I don’t understand the rationale here and this feels like it will be a bit too magical. Why not use the geo mark, or why not let the user handle the mapping from geo to point/bounds?

@Fil
Copy link
Contributor Author

Fil commented Jul 10, 2023

I see this happen a lot during pairing sessions and workshops: people (me included) often start from the geo mark on a geojson, then want to duplicate the mark and change it to something else (e.g. a dot or a text label).

There's often a moment of doubt when nothing shows up on the screen. You have to remember to:

  • get a point (centroid, geocentroid, pole of inaccessibility…)
  • get the features as data, instead of the collection that worked in the geo mark
  • also, find the values in the properties (d => d.properties.name instead of "name") — this is covered by Shorthand for GeoJSON properties #1172

I feel that it would be helpful if (some of) these were automagical, in cases where there is no ambiguity. For instance, a {type: "FeatureCollection"} object can't be a data iterator.

I understand that the application of the centroid to get x,y is a bit more difficult (since we can have points defined without x or y, e.g. when we're using frameAnchor), but it doesn't seem impossible.

@mkfreeman
Copy link
Contributor

I've run into this a number of times, finding it easy to forget to append .features to a mark's data when using a centroid transform.

I would have expected centroid transforms -- perhaps only if there is a projection? -- to be geoJSON aware, using logic like this line from the Plot.geo mark:

  switch (data?.type) {
    case "FeatureCollection":
      data = data.features;
      break;

That being said, I'm not familiar with how (if) transforms make checks like that.

If nothing else, it would be nice to add a warning when Plot.centroid is passed a geoJSON object.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants