Summary

_coords_to_transform used x[1] - x[0] and y[1] - y[0] as the affine pixel sizes without checking that the rest of the spacing matched. GeoTIFF only supports an affine transform, so non-uniform coords can't be expressed faithfully. The writer silently used the first-step spacing and produced a wrong transform.

Repro

import numpy as np, xarray as xr
from xrspatial.geotiff import to_geotiff, open_geotiff

# x is non-uniform: steps are 1, 1, 1, 2
x = np.array([0.0, 1.0, 2.0, 3.0, 5.0])
y = np.linspace(0.0, 4.0, 5)
da = xr.DataArray(np.zeros((5, 5), np.uint8), dims=['y', 'x'], coords={'y': y, 'x': x})
to_geotiff(da, '/tmp/bad.tif')  # silently writes pixel_width=1.0
rt = open_geotiff('/tmp/bad.tif')
# rt.x.values[4] is 4.0, but the source had 5.0: silent data loss

Fix

Validate np.diff(x) and np.diff(y) against the median step with a 1e-6 relative tolerance in _coords_to_transform. Raise ValueError naming the offending dim and the worst residual. Median (not mean) keeps a single bad sample from shifting the reference step.

Tolerance rationale

1e-6 relative is forgiving for float artifacts in otherwise-uniform coords (e.g. np.linspace round-trip jitter is well below 1e-12) but strict enough to catch real non-uniform data. The tolerance is in the error message so the next maintainer can see why their array failed.

Tests

New xrspatial/geotiff/tests/test_coord_regularity_1720.py:

• Uniform coords write successfully (no regression).
• Non-uniform x raises ValueError, message names x.
• Non-uniform y raises ValueError, message names y.
• Float jitter at 1e-7 scale within tolerance writes successfully.
• Jitter at 1e-5 scale above tolerance raises.
• Two-sample coords pass trivially.
• Constant coords raise (step == 0 branch).

Also fixed test_pixel_is_point_round_trip, whose hand-typed coords had ~3.6e-3 relative deviation between steps. That is exactly the silent-wrong-transform case the new check catches. Switched to np.linspace.

Closes #1720