The original 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.

This adds pytest-based tests covering XY, LL, UTM N, UTM S, and other CRS cases.

The key names, the structure, and the values are simply taken from the current output with format='shell', i.e., keys are at the top-level, called 'projection' and 'zone', and values are integers. This means that there is no obvious way how to interpret that information, but the information can be directly used to compare with another computational region even when accessed in a different way (like directly looking into the DEFAULT_WIND file).

Before

{
    "north": 1,
    "south": 0,
    "west": 0,
    "east": 1,
    "nsres": 1,
    "ewres": 1,
    "rows": 1,
    "cols": 1,
    "cells": 1
}

After

{
    "projection": 99,
    "zone": 0,
    "north": 1,
    "south": 0,
    "west": 0,
    "east": 1,
    "nsres": 1,
    "ewres": 1,
    "rows": 1,
    "cols": 1,
    "cells": 1
}

Alternatives

At some places, we call it projection code:

{
    "projection_code": 99,
    "zone": 0,
    "north": 1,
    "south": 0,
    "west": 0,
    "east": 1,
    "nsres": 1,
    "ewres": 1,
    "rows": 1,
    "cols": 1,
    "cells": 1
}

Call it crs (crs or crs_code), not projection:

{
    "crs_code": 99,
    "zone": 0,
    "north": 1,
    "south": 0,
    "west": 0,
    "east": 1,
    "nsres": 1,
    "ewres": 1,
    "rows": 1,
    "cols": 1,
    "cells": 1
}

We could nest it to emphasize the auxiliary nature in relation to the computational region (and use code or type_code inside):

{
    "crs" : {
        "code": 99,
        "zone": 0,
    }
    "north": 1,
    "south": 0,
    "west": 0,
    "east": 1,
    "nsres": 1,
    "ewres": 1,
    "rows": 1,
    "cols": 1,
    "cells": 1
}

Include a string representation as well ("xy", "ll", "utm", "other"):

{
    "crs" : {
        "type_code": 99,
        "type": "other"
        "zone": 0,
    }
    "north": 1,
    "south": 0,
    "west": 0,
    "east": 1,
    "nsres": 1,
    "ewres": 1,
    "rows": 1,
    "cols": 1,
    "cells": 1
}

Use null for zone when not applicable (it is only set for UTM):

{
    "crs" : {
        "type_code": 99,
        "type": "other"
        "zone": null,
    }
    "north": 1,
    "south": 0,
    "west": 0,
    "east": 1,
    "nsres": 1,
    "ewres": 1,
    "rows": 1,
    "cols": 1,
    "cells": 1
}

All the suggestions combined except the nesting (using prefix crs_) and with the CRS info at the end, not at the top:

{
    "north": 1,
    "south": 0,
    "west": 0,
    "east": 1,
    "nsres": 1,
    "ewres": 1,
    "rows": 1,
    "cols": 1,
    "cells": 1
    "crs_type": "other"
    "crs_type_code": 99,
    "crs_zone": null,
}

I like the last one the most. Do you have a favorite?

Going even further

We could also try to remove it from the region completely, but that's whole another issue, much more involved than this PR. There could be also a separate file which would contain this info (e.g., PROJ_TYPE) which would keep the logic, but move it to a different file (and similar thing would have to happen on the C API level).

Commit message

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.