[GRASS-git] [OSGeo/grass] d28238: g.region: Output CRS info in JSON (#6407)

[Vaclav Petras]

  Branch: refs/heads/main
  Home:   https://github.com/OSGeo/grass
  Commit: d28238d4b0009d9f4b449a7aca3d394efaee142a
      https://github.com/OSGeo/grass/commit/d28238d4b0009d9f4b449a7aca3d394efaee142a
  Author: Vaclav Petras <wenzeslaus at gmail.com>
  Date:   2025-09-30 (Tue, 30 Sep 2025)

  Changed paths:
    M general/g.region/printwindow.c
    A general/g.region/tests/g_region_crs_test.py
    M general/g.region/testsuite/test_g_region.py
    M lib/external/parson/gjson.c
    M lib/external/parson/gjson.h
    M scripts/r.pack/r.pack.py
    M scripts/r.pack/tests/r_pack_test.py

  Log Message:
  -----------
  g.region: Output CRS info in JSON (#6407)

The original pre-JSON g.region output contains basic info about the current CRS (aka projection). While this is only basic, providing only distinction between XY, LL, and other (and UTM+zone to certain extent), it is used in the code base and expected to be correct, for example g.proj is using it before checking anything else. Although it is separate from the stored PROJ files, it serves as the primary way of checking what kind of CRS is one dealing with. While this is unrelated to computational region, and in fact, it cannot be modified by g.region (it is ready-only for g.region), you could say it encourages a correct interpretation of the computational region information provided by g.region. A criticism of that here is that while you see XY vs LL vs others, you don't see units which are also important context for computational region values, but nevertheless the basic CRS type check is the current usage.

Instead of  simply taking the key names, the structure, and the values from the current output with format='shell' (i.e., keys are at the top-level, called 'projection' and 'zone', and values are always integers), this introduces a new key 'crs' with nested values and the key is placed at the end of the output, not at the beginning. This helps to interpret that information as CRS and makes it an sort of an additional info instead of the first thing user reads when examining the raw JSON output.

A new string value 'type' is added to complete the type code integer (original 'projection') which is ideal for writing readable checks of LL and YX in the code. The integer code is still good for direct comparison with another computational region even when accessed in a different way (like directly looking into the DEFAULT_WIND file).

A new 'name' value is also added. It appears in some of the outputs and it is stored in PROJ_INFO. There is couple different places in the library determining what this value can be and it is generally meant to be human-readable, so it is distinct from 'type' (although it is fairly deterministic for XY and LL and the library tries hard to always supply some value).

The zone works differently in the way that it may be set None, specifically original zone=0 for non-UTM is now considered as unset, so JSON represents that as null. The clarity of this is highlighted in tests where comparison with none needs no comment, but the comparison with zero would call for a comment about the value not being the ideal representation.

All JSON code now newly uses JSON wrapper functions, so a missing JSON wrapper for dotset_null was added.

This adds pytest-based tests covering XY, LL, UTM N, UTM S, and 'other' CRS cases. The test is focused on CRS, so reflect that in the name. Another pytest can be its own file separated from the CRS topic.



To unsubscribe from these emails, change your notification settings at https://github.com/OSGeo/grass/settings/notifications