Fix windowed read coords of non-georef TIFFs (#1710)#1722
Merged
brendancol merged 3 commits intoMay 12, 2026
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
Fixes inconsistent y/x coordinate generation for non-georeferenced TIFFs (no GeoTIFF transform tags) between full reads and window= reads, aligning all read backends (numpy, dask, cupy, dask+cupy) on integer pixel-index coordinates and preventing emission of a fabricated identity transform attribute.
Changes:
- Thread
has_georefthrough eager, dask, and GPU windowed coordinate computation so non-georef windowed reads produce integer pixel coords (matching full reads). - Suppress
attrs['transform']emission whenhas_georef=Falseto avoid leaking a fake identity transform into downstream workflows. - Add a comprehensive regression test suite covering eager, dask, GPU, and backend-parity behavior, plus protections for georeferenced files.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
xrspatial/geotiff/__init__.py |
Aligns windowed coord generation with full-read behavior for non-georef files; gates transform attr emission on has_georef. |
xrspatial/geotiff/tests/test_no_georef_windowed_coords_1710.py |
Adds regression coverage across CPU/dask/GPU backends and georef/non-georef cases. |
.claude/sweep-metadata-state.csv |
Updates sweep metadata state entry to reflect issue #1710. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+439
to
+441
| # Skip the transform attr for files that lack any GeoTIFF tags. The | ||
| # default unit ``GeoTransform`` is a struct placeholder, not real | ||
| # georef -- emitting it leaks an identity transform into attrs and |
…oords (xarray-contrib#1710) A TIFF with no GeoTIFF tags used to get different `y`/`x` coords depending on whether `window=` was passed. Full reads took the `has_georef=False` shortcut in `_geo_to_coords` and returned integer pixel coords with `int64` dtype. Windowed reads skipped that shortcut and synthesised float64 coords like `[-0.5, -1.5, ...]` from the default unit `GeoTransform`, because the `PixelIsArea` half-pixel shift was applied to a transform that was never real. This patch threads `has_georef` through all three windowed-read paths (`open_geotiff` eager, `read_geotiff_dask`, `_gpu_apply_window_band`) and through `_populate_attrs_from_geo_info`. Non-georef files now get integer pixel coords on both full and windowed reads, and do not emit a fabricated `attrs['transform']` identity tuple. Georef files are unaffected: they still get float64 coords with the half-pixel shift and a real transform attr. Adds regression coverage in `xrspatial/geotiff/tests/test_no_georef_windowed_coords_1710.py` covering numpy, dask+numpy, cupy, and dask+cupy backends. Closes xarray-contrib#1710.
brendancol
force-pushed
the
deep-sweep-metadata-geotiff-2026-05-12-a6e1eda6
branch
from
576bf5a to
fe9c750
Compare
Clarify that the gate is "no transform tags present" (ModelTransformation/ModelPixelScale/ModelTiepoint/GeoKeys), not "files lack any GeoTIFF tags".
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.
Summary
Fixes #1710. Non-georef TIFFs (files with no GeoTIFF tags) got inconsistent
y/xcoords between full reads and windowed reads.Before the fix:
The split was identical across every backend (numpy, dask+numpy, cupy, dask+cupy), so this was a windowed-vs-full inconsistency, not a backend parity bug. The root cause: windowed-read paths synthesised coords from the default unit
GeoTransformand applied thePixelIsAreahalf-pixel shift to a transform that was never real. The full-read path already had ahas_georef=Falseshortcut in_geo_to_coordsthat emitted integer pixel coords.The fix threads
has_georefthrough:open_geotiffeager windowed branch (~line 695)read_geotiff_daskwindowed coord computation (~line 1855)_gpu_apply_window_band(~line 2290), used by both pure CuPy and Dask+CuPy reads_populate_attrs_from_geo_info(~line 438), which suppresses the fabricatedattrs['transform']for files with no GeoTIFF tagsAfter the fix, all four backends agree: integer pixel coords for non-georef files, regardless of full or windowed read. Georef files keep their float64 coords and real transform attr.
Test plan
xrspatial/geotiff/tests/test_no_georef_windowed_coords_1710.pyadds 15 tests across numpy, dask+numpy, cupy, dask+cupy backends, plus 2 regression-protection tests for the georef casetest_kwarg_behaviour_2026_05_12_v2.pyandtest_features.py::TestPalettethat also fail on main)to_geotiff(da_in)->open_geotiff(...)-> compare attrs/coords across all four backendsFound via the metadata propagation sweep, 2026-05-12.