Pin actionable failure modes for unsupported COG writer inputs (#2301) (#2307)

Author: brendancol

xrspatial/geotiff/_coords.py

@@ -33,6 +33,13 @@
 from ._errors import NonUniformCoordsError
 from ._geotags import _NO_GEOREF_KEY, RASTER_PIXEL_IS_POINT, GeoTransform
 
+# Tolerance for rotation/shear detection in affine transforms. ``b`` and
+# ``d`` terms below this magnitude are treated as float noise and pass
+# through as axis-aligned. Shared between ``transform_from_attr`` (6-tuple
+# attrs) and ``to_geotiff`` (rasterio ``Affine`` attrs) so the two gates
+# stay in lockstep on future tolerance tweaks (#2301).
+ROTATION_SHEAR_TOL = 1e-12
+
 # Canonical georef_status string values (mirrored in ``_attrs.py`` as
 # ``GEOREF_STATUS_*`` constants). Issue #2225 centralises the
 # transform/georef contract here; ``_attrs.py`` aliases these names so
@@ -330,8 +337,7 @@ def transform_from_attr(attr_val) -> 'GeoTransform | None':
         a, b, c, d, e, f = (float(x) for x in seq)
     except (TypeError, ValueError):
         return None
-    _ROT_TOL = 1e-12
-    if abs(b) > _ROT_TOL or abs(d) > _ROT_TOL:
+    if abs(b) > ROTATION_SHEAR_TOL or abs(d) > ROTATION_SHEAR_TOL:
         raise ValueError(
             f"attrs['transform'] has non-zero rotation/shear "
             f"(b={b!r}, d={d!r}); rotated or skewed affines are not "

xrspatial/geotiff/_writers/eager.py

@@ -24,7 +24,7 @@
 from .._attrs import (_EXPERIMENTAL_CODECS, _LEVEL_RANGES, _VALID_COMPRESSIONS, _extract_rich_tags,
                       _resolve_nodata_attr, _should_restore_nan_sentinel)
 from .._backends._gpu_helpers import _is_gpu_data
-from .._coords import _BAND_DIM_NAMES, _has_no_georef_marker
+from .._coords import ROTATION_SHEAR_TOL, _BAND_DIM_NAMES, _has_no_georef_marker
 from .._coords import require_transform_for_georeferenced as _require_transform_for_georeferenced
 from .._coords import resolve_georef as _resolve_georef
 from .._crs import _validate_crs_arg, _validate_crs_fallback, _wkt_to_epsg
@@ -357,6 +357,47 @@ def to_geotiff(data: xr.DataArray | np.ndarray,
         entry_point="to_geotiff",
     )
 
+    # Issue #2301: ``attrs['transform']`` carrying a rasterio
+    # ``Affine`` with non-zero rotation/shear (``b != 0`` or ``d != 0``)
+    # silently slipped past ``transform_from_attr`` because ``Affine``
+    # iterates as a 9-element augmented matrix and the 6-tuple gate
+    # there ran ``len(seq) != 6 -> return None``. Without the
+    # rejection the writer falls back to coord-derived or no-georef
+    # output and the rotation is lost on disk. Detect the Affine shape
+    # by duck-typing the (b, d) attrs and surface the same diagnostic
+    # the 6-tuple branch raises (#1987 PR 3 wording, kept verbatim so
+    # the existing match patterns still hit).
+    _attr_transform = _drop_rotation_attrs.get('transform')
+    if (_attr_transform is not None
+            and hasattr(_attr_transform, 'b')
+            and hasattr(_attr_transform, 'd')):
+        try:
+            _b = float(_attr_transform.b)
+            _d = float(_attr_transform.d)
+        except (TypeError, ValueError) as _exc:
+            # Fail-closed on a malformed ``.b`` / ``.d`` rather than
+            # zero-defaulting: an unconvertable value inside an attr
+            # claiming to be an affine transform is itself a writer
+            # input contract violation. Without the explicit raise the
+            # branch would bypass every downstream georef gate that
+            # would otherwise catch the bad value.
+            raise ValueError(
+                f"attrs['transform'] has unconvertable rotation/shear "
+                f"terms (b={_attr_transform.b!r}, "
+                f"d={_attr_transform.d!r}); expected numeric values on "
+                f"a rasterio Affine-like object."
+            ) from _exc
+        if abs(_b) > ROTATION_SHEAR_TOL or abs(_d) > ROTATION_SHEAR_TOL:
+            raise ValueError(
+                f"attrs['transform'] has non-zero rotation/shear "
+                f"(b={_b!r}, d={_d!r}); rotated or skewed affines are "
+                f"not supported by the GeoTIFF writers in this module "
+                f"because the on-disk GeoTIFF representation is "
+                f"axis-aligned and would be written at the wrong "
+                f"location. Reproject the raster to an axis-aligned "
+                f"grid before writing."
+            )
+
     # Issue #2075: reject zero-height / zero-width inputs before any
     # dispatch decision. Clip / window pipelines naturally produce empty
     # rasters and the writers used to accept them, produce a TIFF whose