Repository navigation
grass.temporal: Fix swapped rows and cols in map metadata - #7681
Merged
Merged
Conversation
The ctypes interface assigned the number of columns to the rows key and the number of rows to the cols key, for raster as well as 3D raster maps. The swapped values are stored in the temporal database when a map is registered and are reported by t.info, which therefore disagreed with r.info and r3.info. The number of cells was not affected, because it is the product of both. Maps registered before this fix keep the swapped values in the temporal database until they are registered again. Update the doctests which asserted the swapped values and add a test comparing the metadata read through the interface with the output of r.info and r3.info. The test was written with the help of Claude Code.
petrasovaa
added
bug
Merged
ninsbl
approved these changes
Jul 13, 2026
ninsbl
left a comment
ninsbl
left a comment
Member
There was a problem hiding this comment.
Good catch. Wow, I am surprised I never noticed. Then, number of rows and columns has not been that top of mind as extent and resolution is what I use more regularly. Anyway, the fix and test looks good to me.
Member
|
P.S.: Should this go into the errata, or is this not relevant enough, it is only reported metadata after all. |
github-actions
Bot
added
Python
petrasovaa
enabled auto-merge (squash)
July 13, 2026 14:31
echoix
pushed a commit
to wenzeslaus/grass
that referenced
this pull request
Jul 14, 2026
The ctypes interface assigned the number of columns to the rows key and the number of rows to the cols key, for raster as well as 3D raster maps. The swapped values are stored in the temporal database when a map is registered and are reported by t.info, which therefore disagreed with r.info and r3.info. The number of cells was not affected, because it is the product of both. Maps registered before this fix keep the swapped values in the temporal database until they are registered again. Update the doctests which asserted the swapped values and add a test comparing the metadata read through the interface with the output of r.info and r3.info. The test was written with the help of Claude Code.
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.
Bug
During writing tests for t.info, I found out that
t.inforeports the number of rows and columns of a registered raster or 3D raster map the other way round. It disagrees withr.infoandr3.infofor the same map:The swap propagates from the region struct into the temporal database at registration time and out through t.info. number_of_cells is not affected, since it is the product of both.
This likely dates back to 2013 (I didn't verify).
Impact on existing data
t.info reads rows and cols from the temporal database, where they are stored when a map is registered. Maps registered before this fix keep the swapped values until they are registered again. Only new registrations are correct.