Fix geotiff export geotransform values for numpy >= 2.4#7140
Fix geotiff export geotransform values for numpy >= 2.4#7140PraneelBhatia wants to merge 2 commits into
Conversation
|
|
GDAL's SetGeoTransform requires plain numbers, and numpy >= 2.4 no longer implicitly converts the 1-element arrays which np.diff produces for the x/y step values, causing export_geotiff to fail with "TypeError: not a number". Take scalar ".item()" values for all four geotransform inputs instead. Closes SciTools#7133
PraneelBhatia
force-pushed
the
fix-7133-geotiff-numpy24
branch
from
8a9e3ab to
0bb3f5d
Compare
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Fixes iris.experimental.raster.export_geotiff failing under newer NumPy by ensuring GDAL geotransform parameters are passed as Python scalars rather than NumPy 1-element arrays.
Changes:
- Convert
np.diff(...),np.min(...), andnp.max(...)results to Python scalars via.item()before calling GDAL. - Add a unit test asserting
_gdal_write_arrayreceives Python scalar geotransform values. - Document the bugfix in the latest “What’s New”.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| lib/iris/experimental/raster.py | Casts geotransform components to Python scalars to avoid TypeError with newer NumPy. |
| lib/iris/tests/unit/experimental/raster/test_export_geotiff.py | Adds regression test validating scalar arguments passed into GDAL writer. |
| docs/src/whatsnew/latest.rst | Notes the fix and references the related issue/user link. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| cube.add_dim_coord(coord, 1) | ||
| return cube | ||
|
|
||
| def test_(self, tmp_path): |
| x_min, x_step, y_max, y_step = write_array.call_args.args[:4] | ||
| assert (x_min, x_step, y_max, y_step) == (-12.5, 5.0, 55.0, -10.0) | ||
| for value in (x_min, x_step, y_max, y_step): | ||
| assert isinstance(value, float) |
There was a problem hiding this comment.
Done in b88badd — accepts (int, float) and asserts not isinstance(value, np.generic). This is also a stronger check where it matters: np.float64 is a subclass of float, so the previous assertion wouldn't have caught a NumPy scalar leaking through.
🚀 Pull Request
Description
Closes #7133
iris.experimental.raster.export_geotifffails withTypeError: not a numberfrom GDAL'sSetGeoTransformunder numpy >= 2.4: the x/y step values were the 1-element arrays produced bynp.diff(coord.bounds[0]), and numpy >= 2.4 removed the implicit 1-element-array-to-scalar conversion which previously made this work.This PR coerces all four geotransform inputs (
x_min,x_step,y_max,y_step) to plain Python floats via.item(), as suggested in the issue —.item()is safe on scalars and size-1 arrays, and would raise on anything longer.Also:
test_scalar_transform_values) which asserts the values passed to_gdal_write_arrayare Python floats, so the regression is guarded even on numpy < 2.4 installs (the geotiff tests need GDAL, which is not in the CI environment).Tested locally with python 3.13 / numpy 2.4.6 / GDAL 3.13.0: the issue's reproduction snippet now succeeds (
GetGeoTransform() == (-0.5, 1.0, 0.0, 4.5, 0.0, -1.0)), andpytest lib/iris/tests/unit/experimental/raster/test_export_geotiff.pygoes from 17 failed / 1 passed onmainto 19 passed. The new test fails without the fix.Consult Iris pull request check list
Add any of the below labels to trigger actions on this PR: