BUG: Use @ instead of * for Affine multiplication (#937) - #941
Closed
VolodymyrLinuxovich wants to merge 1 commit into
Closed
VolodymyrLinuxovich wants to merge 1 commit into
VolodymyrLinuxovich wants to merge 1 commit into
Conversation
affine 3.0.1 emits a PendingDeprecationWarning when * is used for matrix multiplication. The @ operator requires affine>=3.0, so declare affine (already imported directly) as an explicit dependency.
Author
|
Closing as a duplicate of #939, which already does this with the requested pins. |
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
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.
rioxarray.open_rasteriostarting to emit warning from affine #937docs/history.rstfor all changes anddocs/rioxarray.rstfor new APIProblem
affine 3.0.1 (2026-08-28) emits
PendingDeprecationWarning: Use @ matmul instead of * mul operator for matrix multiplicationwhenever*is used, both for composing transforms and for applying a transform to coordinates.open_rasteriotriggers it throughaffine_to_coords, andrio.transform(recalc=True)triggers it throughXRasterBase.transform.Change
rioxarray/_spatial_utils.pyandrioxarray/rioxarray.py: replace the 5Affine*multiplications with@. Running the test suite with that warning turned into an error finds no other call sites in rioxarray.pyproject.toml: addaffine>=3.0.@was added in affine 3.0, and rasterio 1.4.3 still accepts affine 2.x. rioxarray already importsaffinedirectly in several modules, so this also declares a dependency it was relying on implicitly. If you'd rather keep supporting affine 2.x, I can switch to a version-agnostic approach.affine_to_coordswraps its return values innumpy.asarray(a no-op at runtime). This is needed because mypy picks afloatreturn type from affine's__matmul__overloads, which would otherwise add two newdict-itemerrors.Some warnings remain from inside rasterio itself (
rasterio.windows,rasterio.transform,rasterio.merge). Those need a fix in rasterio.Tests
test_open_rasterio__no_affine_mul_warning, parametrized for rectilinear and rotated transforms so it covers bothaffine_to_coordsbranches. It opens the file from the issue with that warning turned into an error and callsrio.transform(recalc=True). It fails onmasterand passes with this PR.pre-commitpasses.pylintrates the changed modules 10.00/10.mypy rioxarray/shows the same 3 pre-existingoperatorerrors in_spatial_utils.pyasmaster, because affine's type hints don't cover NumPy arrays.masterin this environment because the wheel's GDAL has no netCDF/HDF drivers. Warnings drop from 2787 to 672.