Skip to content

Comments

lib: Change default zone value from -1 to 0#6431

Merged
wenzeslaus merged 2 commits intoOSGeo:mainfrom
wenzeslaus:fix-zone-default
Sep 30, 2025
Merged

lib: Change default zone value from -1 to 0#6431
wenzeslaus merged 2 commits intoOSGeo:mainfrom
wenzeslaus:fix-zone-default

Conversation

@wenzeslaus
Copy link
Member

@wenzeslaus wenzeslaus commented Sep 30, 2025

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), null is available as a value. In Python, the JSON null value is translated to and from Python None.

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)_:

I limited the condition to zone==0 && crs!=utm just to be on the safe side since all the other code is agnostic towards the CRS when handling zone. Practically, it seems only UTM now and zone=null makes more sense than the zone=0. While checking how it is used, I also discovered that default somewhere in the library is set to -1 which is wrong since negative numbers are used for south zones, but I will change that in a separate PR.

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.

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.
@github-actions github-actions bot added C Related code is in C libraries labels Sep 30, 2025
@wenzeslaus wenzeslaus enabled auto-merge (squash) September 30, 2025 18:30
@wenzeslaus wenzeslaus changed the title lib: Change default zone value to 0 lib: Change default zone value from -1 to 0 Sep 30, 2025
@wenzeslaus wenzeslaus merged commit 34e1660 into OSGeo:main Sep 30, 2025
29 checks passed
@wenzeslaus wenzeslaus deleted the fix-zone-default branch September 30, 2025 19:44
@github-actions github-actions bot added this to the 8.5.0 milestone Sep 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

C Related code is in C libraries

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants