GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
GeezerVison is showing github.com — fix: Handle geojson features that cross antimeridian in computeBbox by camdecoster · Pull Request #7891 · plotly/plotly.js Conversation
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Before | After |
|---|---|
![]() |
![]() |
@turf/bbox doesn't handle geometry that spans the antimeridian and there's been no movement to fix that issued3-geo.geoBounds, that does work with the antimeridian) to do the same thing (along with a turf utility used within @turf/bbox)
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
| * @return {[number, number, number, number]|null} `[west, south, east, north]` | ||
| * in degrees; `east` may exceed 180° when the input crosses ±180°. | ||
| * Returns `null` for input with no extractable coordinates (e.g. `Sphere`, | ||
| * empty FeatureCollection). |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Can you expand this docstring to clarify the numeric range of each coordinate, and any constraints on the output, and also whether east is guaranteed to exceed 180 if the input crosses the antimeridian?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
I'll add a bit more info, but some of what you're asking for seems out of scope of a docstring.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| // Pass as MultiPoint to sidestep d3-geo's polygon winding assumption (CW | ||
| // exterior, opposite of RFC 7946) and geodesic apex overshoot |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
I don't know what CW exterior or geodesic apex overshoot mean, could you tweak this comment to be a bit more readable?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's confusing. I'll simplify it.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| return [ | ||
| west, | ||
| south, | ||
| east < west ? east + ANTIMERIDIAN_LON_SHIFT : east, // Unwrap antimeridian crossing; east may exceed 180° |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Can use unwrapLonRange() here now that #7881 is merged, right?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
This check is slightly different, but I can probably get everything to use the same calc. I'll update it.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
| @@ -54,17 +54,25 @@ function calcGeoJSON(calcTrace, fullLayout) { | |||
| calcPt._polygons = geoUtils.feature2polygons(feature); | |||
|
|
|||
| var bboxFeature = geoUtils.computeBbox(feature); | |||
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
I realize this issue predates your changes, but it seems a little silly to compute bounding boxes for all the features here if they might be ignored in the next step. Maybe a small refactor would make sense?
It's beyond the scope of this PR though so not necessary.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Good idea! That does seem a bit wasteful. Let me poke at it.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| } | ||
|
|
||
| describe('Test geo fitbounds with antimeridian-straddling points', function() { | ||
| describe('Test geo fitbounds with antimeridian-straddling points', function () { |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Is it worth adding a similar test here for choropleth to verify the changes end-to-end? And/or an image test? (I'm a little surprised that none of the existing image baselines changed as a result of these changes, but I guess it requires a pretty specific combination of factors to surface this issue.)
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
In the follow up work to default to fitbounds = "locations", I'll address adding tests. This one just needed to be updated because of computeBbox changed.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Left some nitpick comments, but LGTM.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.