You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CRS extraction in xrspatial/geotiff/_geotags.py accepts contradictory GeoKey combinations without complaint. The block at line 853 reads ProjectedCSTypeGeoKey first, falls back to GeographicTypeGeoKey, and never checks either against ModelTypeGeoKey.
Existing read-side validation in xrspatial/geotiff/_validation.py (e.g. _check_read_unparseable_crs at line 1025) only checks that a CRS string is parseable. Nothing audits the structural consistency of the GeoKey set itself.
is internally contradictory. 4326 is a geographic CRS, but it shows up under the projected key while ModelTypeGeoKey says the model is geographic. open_geotiff() accepts this without warning and returns:
The reader has fabricated trustworthy-looking spatial metadata from contradictory inputs. A malformed or hostile file can inject inconsistent CRS metadata that downstream functions then treat as authoritative.
Expected behavior
Reads should reject incompatible ModelTypeGeoKey / type-key combinations before constructing attrs:
ModelTypeGeoKey = projected with only GeographicTypeGeoKey set: reject.
ModelTypeGeoKey = geographic with ProjectedCSTypeGeoKey set: reject.
Both ProjectedCSTypeGeoKey and GeographicTypeGeoKey set to different EPSG codes: reject.
The error should be a new GeoTIFFAmbiguousMetadataError subclass, matching the existing _errors.py family. An opt-out kwarg like allow_inconsistent_geokeys=True is appropriate so callers with known-quirky historical files can keep the legacy behaviour.
Additional context
Silent fallback site: xrspatial/geotiff/_geotags.py:853 (the if/elif over the two type keys).
Validation registry to extend: xrspatial/geotiff/_validation.py (register_read_metadata_check).
Error hierarchy to extend: xrspatial/geotiff/_errors.py (GeoTIFFAmbiguousMetadataError).
Describe the bug
CRS extraction in
xrspatial/geotiff/_geotags.pyaccepts contradictory GeoKey combinations without complaint. The block at line 853 readsProjectedCSTypeGeoKeyfirst, falls back toGeographicTypeGeoKey, and never checks either againstModelTypeGeoKey.Existing read-side validation in
xrspatial/geotiff/_validation.py(e.g._check_read_unparseable_crsat line 1025) only checks that a CRS string is parseable. Nothing audits the structural consistency of the GeoKey set itself.A TIFF declaring:
is internally contradictory. 4326 is a geographic CRS, but it shows up under the projected key while
ModelTypeGeoKeysays the model is geographic.open_geotiff()accepts this without warning and returns:The reader has fabricated trustworthy-looking spatial metadata from contradictory inputs. A malformed or hostile file can inject inconsistent CRS metadata that downstream functions then treat as authoritative.
Expected behavior
Reads should reject incompatible
ModelTypeGeoKey/ type-key combinations before constructingattrs:ModelTypeGeoKey = projectedwith onlyGeographicTypeGeoKeyset: reject.ModelTypeGeoKey = geographicwithProjectedCSTypeGeoKeyset: reject.ProjectedCSTypeGeoKeyandGeographicTypeGeoKeyset to different EPSG codes: reject.The error should be a new
GeoTIFFAmbiguousMetadataErrorsubclass, matching the existing_errors.pyfamily. An opt-out kwarg likeallow_inconsistent_geokeys=Trueis appropriate so callers with known-quirky historical files can keep the legacy behaviour.Additional context
xrspatial/geotiff/_geotags.py:853(theif/elifover the two type keys).xrspatial/geotiff/_validation.py(register_read_metadata_check).xrspatial/geotiff/_errors.py(GeoTIFFAmbiguousMetadataError).