[Feat] GRASS projection management

[metzm]

GRASS projection information originated as an enhanced PROJ version with additional datum transformation information and additional functionality added to the PROJ lib (e.g. all the PJ_*.c and pj_*.c files in GRASS 4.2).

As the PROJ lib developed, GRASS enhancements to the PROJ lib have been successively removed. What remains in GRASS is a mechanism to determine datum transformation parameters from any datum known by GRASS to WGS84. We had to increase the list of datums known by GRASS over the years, lately struggling to keep up with the list of generally known datums. Furtheron, GRASS uses a syntax derived from PROJ to store projection information.

More importantly, coordinate transformations involving datum transformations used WGS84 as pivot datum, i.e. any datum -> WGS84 -> any other datum. This has been changed with PROJ6+ where PROJ6+ provides methods to transform coordinates from one datum to another datum without going through WGS84. Moreover, datum transformation parameters also depend on the geographical area for which coordinates need to be transformed. PROJ6+ selects adequate transformation parameters not only depending on the source and target crs, but also on the geographical area.

Since PROJ6+ is now able to select appropriate coordinate and datum transformation parameters for a given source and traget crs and a given area, GRASS crs management including datum transformation parameters should rely on PROJ6+. IMHO, there is no need or gain by modifying the knowledge base and mechanisms to determine appropriate coordinate transformation parameters available in PROJ6+.

Right now we store only EPSG codes, other authorities such as ESRI, IGNF, OGC, PROJ and their corresponding codes are not recognized, but needed to define and store spatial reference ids (srid).

The proposed changes to GRASS are:

1. when a new location is created, store the srid if available (e.g. "EPSG:4326", "urn:ogc:def:crs:EPSG::4326") and WKT in addition to EPSG (there are other authorities than EPSG) and standard GRASS projection info

2. retrieving projection information for a given location will use these priorities

   1. srid consisting of authority name and code, e.g. "EPSG:4326", "urn:ogc:def:crs:EPSG::4326"
   2. EPSG code as before
   3. WKT, new
   4. GRASS projection information as before

3. transforming projection information from one format to another will no longer use GDAL OSR routines, but PROJ6+ routines

The implementation in GRASS would be done in several steps:

1. add routines to read and write WKT and srid
2. use the outlined priorities in g.proj
3. update all modules creating a new location
4. update the library routines doing coordinate transformation
5. update all modules doing coordinate transformations

[marisn]

Would it mean dropping proj < 6 support? As it would introduce significant (and beneficial!) changes to location definition, it would be good to get this into 8.0. Another reason why to call it 8.

[metzm]

Right now the plan is to preserve support for PROJ < 6 and implement these changes only if PROJ6+ is available. That implies a few #if PROJ_VERSION_MAJOR >=6, though.

Regarding code maintenance, it would be a big relief to drop support for GDAL < 3 and PROJ < 6 in GRASS 8. Right now, e.g. r.in.gdal and v.in.ogr are peppered with these #if's catering for different GDAL versions, making code maintenance difficult. But this is a different issue.

[wenzeslaus]

...it would be a big relief to drop support for GDAL < 3 and PROJ < 6 in GRASS 8.

Here is report from the CI about their versions in the tested systems:

System	PROJ	GDAL/OGR
Ubuntu 20.04	6.3.1	3.0.4
Ubuntu 18.04	4.9.3	2.2.3
CentOS 7	4.8.0	1.11.4

The Ubuntu 18.04 is without PPA, so it would make sense to me drop support for the plain Ubuntu 18.04 since the use case is installing latest GRASS GIS. (This means removing Ubuntu 18.04 from CI for the main branch. That's easy.)

The CentOS 7 image is using epel-release, but in combination with conda, so it may be reasonable to take all the dependencies from conda or re-conceptualize the test as a test for conda rather than CentOS 7.

This does not include the Docker images build from the main branch and releases, so I don't know how that may change. It might be advantageous to test the build of the Alpine and Debian Docker images in CI instead of CentOS 7.

Given how close we are to v8.0, we can leave it for v8.2 and say in the release announcement that the support for older GDAL and PROJ will be dropped in the next version.

[metzm]

The CentOS 7 image is using epel-release, but in combination with conda, so it may be reasonable to take all the dependencies from conda or re-conceptualize the test as a test for conda rather than CentOS 7.

This does not include the Docker images build from the main branch and releases, so I don't know how that may change. It might be advantageous to test the build of the Alpine and Debian Docker images in CI instead of CentOS 7.

+1 Anybody still using CentOS7 (or any other RHEL7 variant) would surely use newer GDAL + PROJ versions in combination with GRASS 8.

Given how close we are to v8.0, we can leave it for v8.2 and say in the release announcement that the support for older GDAL and PROJ will be dropped in the next version.

+1