Repository navigation
get bounding box for data in UTM or polar-stereo projections - #1522
Open
Alex-Lewandowski wants to merge 4 commits into
Open
Alex-Lewandowski wants to merge 4 commits into
Alex-Lewandowski wants to merge 4 commits into
Conversation
Contributor
Reviewer's GuideProjected datasets now use their declared EPSG coordinate reference system to calculate geographic bounding boxes, correctly supporting polar stereographic data while preserving the existing UTM-specific path. Flow diagram for projected-data bounding-box calculationflowchart TD
A[get_bounding_box] --> B{Y_UNIT is degrees?}
B -->|Yes| C[Keep geographic coordinates]
B -->|No| D{EPSG is declared}
D -->|Yes| E[Transformer.from_crs EPSG to EPSG:4326]
E --> F[Transform all four bounding-box corners]
F --> G[Compute latitude and longitude extrema]
D -->|No| H{UTM_ZONE is declared}
H -->|Yes| I[ut.utm2latlon for bounding corners]
H -->|No| J[No projected conversion]
C --> K[Return geographic bounding box]
G --> K
I --> K
J --> K
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Hey - I've found 2 issues
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="src/mintpy/tropo_pyaps3.py" line_range="344" />
<code_context>
if not meta.get('Y_UNIT', 'degrees').lower().startswith('deg'):
- lat0, lon0 = ut.utm2latlon(meta, easting=lon0, northing=lat0)
- lat1, lon1 = ut.utm2latlon(meta, easting=lon1, northing=lat1)
+ epsg = meta.get('EPSG')
+ transformer = Transformer.from_crs(
+ f'EPSG:{epsg}',
</code_context>
<issue_to_address>
**UTM bounds fail without EPSG**
When geocoded projected UTM metadata has `UTM_ZONE` but no `EPSG`, `meta.get('EPSG')` returns `None`, so `Transformer.from_crs` receives `EPSG:None` and raises; bounding-box calculation aborts and weather processing fails.
Use `UTM_ZONE` to determine the CRS when `EPSG` is absent.
</issue_to_address>
### Comment 2
<location path="src/mintpy/tropo_pyaps3.py" line_range="350-351" />
<code_context>
+ 'EPSG:4326',
+ always_xy=True,
+ )
+ lon0, lat0 = transformer.transform(lon0, lat0)
+ lon1, lat1 = transformer.transform(lon1, lat1)
else:
</code_context>
<issue_to_address>
**Bounds exclude raster coverage**
When a projected raster's geographic extrema fall outside the two transformed diagonal endpoints, including along an edge, `get_bounding_box` transforms only two diagonal corners, so its bounds omit geographic extrema; weather requests or OPERA cropping then exclude part of the raster.
Transform or sample the full projected footprint, including its edges, and compute bounds from the resulting coordinates.
</issue_to_address>
Alex-Lewandowski
marked this pull request as draft
October 7, 2026 22:58
…g box coords when transofrming polar-stereo to avoid underestimating bbox extents
|
I ran into this same problem today for NISAR data over Iceland. |
Alex-Lewandowski
marked this pull request as ready for review
October 8, 2026 17:32
Contributor
There was a problem hiding this comment.
Hey - I've found 1 issue
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="src/mintpy/tropo_pyaps3.py" line_range="362-365" />
<code_context>
+ else:
+ lat0, lat1 = min(lats), max(lats)
+
+ if lon0 > lon1:
+ lon0, lon1 = max(lons), min(lons)
+ else:
+ lon0, lon1 = min(lons), max(lons)
+
+ elif meta.get('UTM_ZONE'):
</code_context>
<issue_to_address>
**Dateline bounds span nearly globe**
When a projected footprint crosses the antimeridian and its transformed corner longitudes lie on both sides of ±180°, `get_bounding_box` takes numeric longitude minima and maxima, producing a nearly 360° interval; `get_snwe` can make an oversized or invalid weather request, and `get_opera_crop_indices` can select nearly the entire longitude axis.
Compute the narrow wrapped longitude interval across the antimeridian instead of taking the numeric minimum and maximum.
</issue_to_address>
Comment on lines
+362
to
+365
| if lon0 > lon1: | ||
| lon0, lon1 = max(lons), min(lons) | ||
| else: | ||
| lon0, lon1 = min(lons), max(lons) |
Contributor
There was a problem hiding this comment.
🟡 Medium · Dateline bounds span nearly globe
When a projected footprint crosses the antimeridian and its transformed corner longitudes lie on both sides of ±180°, get_bounding_box takes numeric longitude minima and maxima, producing a nearly 360° interval; get_snwe can make an oversized or invalid weather request, and get_opera_crop_indices can select nearly the entire longitude axis.
Compute the narrow wrapped longitude interval across the antimeridian instead of taking the numeric minimum and maximum.
Prompt for AI agents
In `src/mintpy/tropo_pyaps3.py` at lines 362-365:
**Dateline bounds span nearly globe**
When a projected footprint crosses the antimeridian and its transformed corner longitudes lie on both sides of ±180°, `get_bounding_box` takes numeric longitude minima and maxima, producing a nearly 360° interval; `get_snwe` can make an oversized or invalid weather request, and `get_opera_crop_indices` can select nearly the entire longitude axis.
Compute the narrow wrapped longitude interval across the antimeridian instead of taking the numeric minimum and maximum.This branch has not been deployed
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
2 participants
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.
Description of proposed changes
tropo_pyaps3.get_bounding_boxassumes that ifmeta['Y_UNIT']is not degrees, it must be UTM, and then transforms bbox coords to lat/lon using theutmpackage. This causes incorrect transformations for data in polar-stereo projections, which like data in UTM, also have units of meters.For example, a subset Copernicus DEM for NISAR in EPSG:3413 had bounding coords of:
When running
tropo_opera, a call totropo_pyaps3.get_bounding_boxresulted in nonsensical lat/lon coords:Instead of the expected:
The proposed solution performs the transformation with
pyproj.Transformerinstead ofutm.to_latlon. Additionally, all four corners are used to find the maximum rectangular bounding box when performing transformations from polar stereographic coordinates. This is important because significant tilting may occur when projecting from polar coordinates which makes using only two corner coordinates an unreliable way to cover all the valid data.Reminders
Summary by Sourcery
Use CRS-aware transformations to derive accurate geographic bounding boxes from UTM and polar-stereo data.
Bug Fixes:
Enhancements: