lib: Change default zone value from -1 to 0#6431
Merged
wenzeslaus merged 2 commits intoOSGeo:mainfrom Sep 30, 2025
Merged
Conversation
The code for reading cell header (and computational region) used -1 as a default for zone (following example of the proj field). However, negative numbers are used to represent UTM south zones. On the other hand, 0 is used as a value for CRSs without zone (so everything else except UTM). So, this changes the default from -1 to 0. The code is reading internal GRASS data, and the writing code is setting the zone to 0, so -1 did not pop up anywhere based on the fact that zone is required by the code to be present (so -1 was either replaced or error was produced). This should be covered by g.region tests in OSGeo#6407, so let's merge that and update here.
petrasovaa
approved these changes
Sep 30, 2025
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.
The code for reading cell header (and computational region) used -1 as a default for zone (following example of the proj field). However, negative numbers are used to represent UTM south zones. On the other hand, 0 is used as a value for CRSs without zone (so everything else except UTM). So, this changes the default from -1 to 0. The code is reading internal GRASS data, and the writing code is setting the zone to 0, so -1 did not pop up anywhere based on the fact that zone is required by the code to be present (so -1 was either replaced or error was produced).
The internal stograte is a custom key-value pair text file which uses 0, but in JSON outputs (this PR) and in r.pack computation region CRS info which is implemented as a pass-through from the JSON (#6408 for original and this PR for pass-through),
nullis available as a value. In Python, the JSONnullvalue is translated to and from PythonNone.This should be covered by g.region tests in #6407, so let's merge that and update here.
Additional context
Comment in #6407 posted by @wenzeslaus in #6407 (comment)_:
Corresponding commit from the PR: 70e5c72
Commit meesage
The code for reading cell header (and computational region) used -1 as a default for zone (following example of the proj field). However, negative numbers are used to represent UTM south zones. On the other hand, 0 is used as a value for CRSs without zone (so everything else except UTM). So, this changes the default from -1 to 0. The code is reading internal GRASS data, and the writing code is setting the zone to 0, so -1 did not pop up anywhere based on the fact that zone is required by the code to be present (so -1 was either replaced or error was produced).
Core the context, the internal stograte is a custom key-value pair text file which uses 0. On the other hand, 'null' is available and used as a value in JSON outputs (#6407) and in r.pack computation region CRS JSON info which is implemented as a pass-through from the g.region JSON output (#6408 for original and #6407 for pass-through).
This does not have a specific test because in the overall integration only 0 is occuring (see above). The general functionality should be covered by g.region tests from #6407.