Fix bugs related to extent-cropping #1774
Merged
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.
Overview
Currently in RV, the concept of extent is overloaded to refer to the both the full extent of the data in the data source file as well as a user-specified subset of it. See #1766 for more discussion.
This PR attempts to correct this by disentangling these into extent and bbox. A
RasterioSource
that reads from a 100x100 GeoTIFF that is cropped to exclude 10 pixels on all sides, for example, will now have.bbox == Box(10, 10, 90, 90)
and.extent == Box(0, 0, 80, 80)
. Moreover, the user is expected to interact with theRasterioSource
using local coordinates; i.e. coordinates relative to itsbbox
rather than global coordinates. See "option 2" here.Checklist
needs-backport
label if PR is bug fix that applies to previous minor releaseNotes
N/A
Testing Instructions
See updated unit tests.
Closes #1766