Reject 0D/1D DataArray in to_geotiff with the clear "Expected 2D or 3D" ValueError#3604
Merged
brendancol merged 3 commits intoJul 2, 2026
Conversation
A 0D/1D DataArray reached coords_to_transform (which reads dims[-2]) before the ndim check and raised an opaque IndexError from _coords.py, while a numpy array of the same rank and a 4D DataArray already got the clear 'Expected 2D or 3D array, got ND' ValueError. Hoist the check ahead of backend dispatch and georef resolution so the eager TIFF, .vrt, and GPU write paths all reject the same shapes identically.
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
1 participant
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.
Moves the "Expected 2D or 3D array" rank check in to_geotiff up front, ahead of backend dispatch and georef resolution. A 0D or 1D DataArray used to reach coords_to_transform (which reads dims[-2]) before the check and die with
IndexError: tuple index out of rangefrom _coords.py. A numpy array of the same rank, and a 4D DataArray, already got the clear ValueError; the guard now covers the DataArray case too.The eager TIFF, .vrt, and GPU write paths all resolved georef before the check, so all three showed the bug. The guard sits before dispatch, so one check fixes every path. It reads ndim via getattr(data, "ndim", None), so numpy, cupy, dask, and DataArray inputs are covered, and a None input still falls through to the existing message.
Changes:
Checked: the new tests fail with IndexError before the change and pass after; the existing numpy 0D/1D/4D tests still pass unchanged; wider write-path suites are green (685 passed).
Found by the error-handling sweep.