-
Notifications
You must be signed in to change notification settings - Fork 26
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
fix: handle 180th meridian case for tms.tiles()
#150
Merged
vincentsarago
merged 3 commits into
developmentseed:main
from
ljstrnadiii:case_180th_meridian
Jul 26, 2024
Merged
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
This file contains 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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could we just do a tests to see if the
w > e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The specific case I am hoping to handle is when the
tms.bbox
lons contain the antimeridian, but also the bounds provided for tiles is on either side of the antimeridian or overlaps. This requires we swap the underlying operator (min to max or max to min on a w/e basis) in order to truly clamp and avoid generating many many tiles that don't intersect the provided bounds.Here is an example:
Given a
tms.bbox
(110, 0, -158, 90) and bounds used to find tiles of (-179, 45, -178, 46), the final clamped box we want is the bounds itself since it is fully contained inside thetms.bbox
i.e. (-179, 45, -178, 46).w > e
for bounds only:w > e
evaluates toFalse
, and we keepw = max(self.bbox.left, w)
giving us a neww
of 110, but we should have -179 so that won't work (hence the need to swap max to min).w > e
fortms.bbox
only:w > e
evaluates to True, so we would swap max to min and get -179, which is what we want! However, consider the sametms.bbox
, but new bounds that are completely west of the antimeridian (150, 45, 155, 46) and still contained insidetms.bbox
, then applying the swapped max to min would give us 110, which is not what we want. We would actually need to keep max (not min) here to get the expected 150. That is the reason for needing to check if the anti-meridian is inside interval (tms.bbox.west
, bounds.west) to swap the operator in order to truly clamp to intersection of the provided bounds andtms.bbox
.Sorry for all the words, happy to illustrate this better if the added test does not highlight this well enough.