derive x & y scale domains from geometry#1468
Merged
Conversation
07be0c6 to
d71e888
Compare
Contributor
|
This makes it much easier to just pass in a GeoJSON file. No more quarter-Earth! |
d71e888 to
0dea987
Compare
Contributor
Contributor
|
follow-up in #1663 |
0dea987 to
a6d4533
Compare
* fix pending issues and add tests * optimize and comment * move hasProjection --------- Co-authored-by: Mike Bostock <[email protected]>
mbostock
commented
Jun 2, 2023
mbostock
commented
Jun 2, 2023
Member
Author
|
This looks good to me. What do you think @Fil? |
Fil
approved these changes
Jun 2, 2023
Contributor
|
🎉 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. |
Fil
added a commit
that referenced
this pull request
Aug 21, 2023
* derive x & y scale domains from geometry * follow-up: derive x & y scale domains from geometry (#1663) * fix pending issues and add tests * optimize and comment * move hasProjection --------- Co-authored-by: Mike Bostock <[email protected]> --------- Co-authored-by: Philippe Rivière <[email protected]>
chaichontat
pushed a commit
to chaichontat/plot
that referenced
this pull request
Jan 14, 2024
* derive x & y scale domains from geometry * follow-up: derive x & y scale domains from geometry (observablehq#1663) * fix pending issues and add tests * optimize and comment * move hasProjection --------- Co-authored-by: Mike Bostock <[email protected]> --------- Co-authored-by: Philippe Rivière <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
and it behaves almost identical to
This is still a draft because I think we should skip constructing the derived x and y channels in a couple cases:
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.