Fix Affine matrix multiplication warnings

[be-student]

Summary

Fixes Affine 3's PendingDeprecationWarning for rioxarray's own matrix multiplications by using @ for pixel-center, coordinate-array, and recalculated transforms. Following review, the coordinate-conversion function keeps its original structure; the only runtime operation changes there are * to @. A typing-only cast() accounts for Affine's overloads not covering NumPy coordinate arrays.

The maintainer-requested dependency floors are explicit: rasterio>=1.5.1 and affine>=3. Transform comparisons in the affected integration tests compare coefficient tuples, and the focused unit test exercises pixel-center coordinates.

Validation

• On macOS/Python 3.14.3 at head cd7a8e44c75dbe8bf73633e1d64f21e06f490469, mypy reports no issues in 19 source files, pylint reports 10.00/10, the focused spatial tests pass (2 passed), and git diff --check passes.
• The complete local uv test environment reported 489 passed, 52 failed, 20 skipped, 1 xfailed, and 3 xpassed. This is not presented as a passing suite: the environment lacks HDF support and also reproduces existing integration failures described in earlier validation.
• On the prior scoped head, AppVeyor build 54784318 reported 554 passed, 4 skipped, 2 xfailed and 5 xpassed, then exited -1073741819 after sys.excepthook errors during interpreter shutdown. No unrelated shutdown or CI-masking change was added.
• On the current head, GitHub Actions linting, release build, all Docker jobs, all Ubuntu jobs, and latest-dependency testing pass. Windows/Python 3.14 again completed 554 tests successfully, then produced the known post-pytest sys.excepthook errors and segmentation fault; fail-fast cancelled the remaining macOS and Windows jobs.
• The latest AppVeyor build 54790615, on this same PR head, ran Windows/Python 3.12.14: 554 passed, 4 skipped, 2 xfailed, and 5 xpassed. After the successful pytest summary it emitted sys.excepthook errors and exited with Windows access violation -1073741819. The job remains failed; a successful test summary is not a successful CI run. Its log is now accessible. Whether this shutdown crash also occurs on current upstream has not been established, so no unrelated shutdown or CI-masking change is included.
• Reopening triggered fresh Tests and Release runs; both require maintainer approval (action_required). The reported green/failing job results above are from the earlier approved runs, not newly completed runs.

Issue linkage

Closes #937.

AI assistance disclosure

OpenAI Codex assisted with implementation, test execution, baseline comparison, and this description. No manual-testing or human-review claim is made.

• Closes rioxarray.open_rasterio starting to emit warning from affine #937
• Tests added
• Fully documented, including docs/history.rst

[snowman2]

With this change, will need to pin rasterio>=1.5.1 and affine>=3.

[snowman2]

I suggest focusing only on affine matrix multiplication. If more than that is added, it could cause the PR merge to be delayed or blocked.

[be-student]

Thanks for the guidance. I narrowed the branch back to the affine matrix multiplication change and the requested rasterio>=1.5.1 / affine>=3 dependency floors. The unrelated shutdown handling and AppVeyor exit-code wrapper have been removed, and AppVeyor runs pytest directly again.

At head 127d5af29d000608a9575a62bd4de4d3651459de, the focused unit tests pass (2 passed), the affected transform integration tests pass (30 passed), and git diff --check passes. The fresh AppVeyor build is now running.

[be-student]

AppVeyor build 54750988 completed the full Windows suite on the narrowed head: 554 passed, 4 skipped, 2 xfailed, and 5 xpassed. After pytest printed the successful summary, the interpreter emitted empty sys.excepthook messages and exited with Windows access violation -1073741819 (0xC0000005). No test failed, including the affine coverage.

I am keeping the branch affine-only as requested and am not reintroducing shutdown hooks or a CI wrapper that accepts the native crash. The complete hosted log is available in AppVeyor build 54750988.

[be-student]

The GitHub Actions Windows/Python 3.14 job shows the same post-test native failure as AppVeyor. Its log reports 554 passed, 4 skipped, 2 xfailed, and 5 xpassed, then sys.excepthook errors and a segmentation fault (exit 139) after pytest printed the successful summary: failed Windows job.

The affine tests themselves pass, and I am keeping the branch scoped to affine matrix multiplication as requested. I cannot establish from this PR run alone whether the interpreter-shutdown crash also occurs on current main, so I have not altered unrelated runtime or CI teardown code.

[be-student]

Thanks for the scope correction. I removed the manual coordinate arithmetic in 1f895d02; affine_to_coords now retains its original structure with only *-to-@ substitutions. The affected local selection had 76 passes and three clip_box__auto_expand failures; those same three fail on the previous PR head and on upstream master with the same local dependency environment. I updated the PR description to distinguish that baseline evidence and the older Windows CI failures from new-head validation.

[be-student]

The new scoped head 1f895d02 completed the AppVeyor test suite in build 54784318: 554 passed, 4 skipped, 2 xfailed and 5 xpassed. It then produced sys.excepthook errors and exited with Windows access violation -1073741819, as the previous head did. I have updated the PR description with this new-head result and am leaving shutdown behavior and CI exit handling outside the affine-only change you requested.

[be-student]

Thank you for the reviews and guidance. I am closing this PR to wind down my pending contribution queue. The patch and test results remain available here; please feel free to use or adapt them whenever useful.

[snowman2]

Thanks for your contribution.

Trimming contribution queues is a new concept to me. It is important to be aware that maintainers have many responsibilities and priorities outside of the projects that you contribute to. Due to this, the timeline for merging PRs may be a while.

This was added to the milestone for the project and was planned to be merged when maintainers have time.