grass_proj: use OSRIsSame to compare CRSs

[metzm]

Use newer OSRIsSame() from the OGR SRS API replacing the old G_compare_projections() in GRASS from PROJ4 times.

Fixes #5867

@marisn If this PR is ok with you, I would adjust v.external, r.in.gdal, r.external accordingly.

[metzm]

Interesting: a test for v.in.ogr fails now because the test attempts to import data with a CRS different from the GRASS project, the difference is in the datum.

Apparently the CRS of the NC sample projects has been changed some time ago by adding a PROJ_EPSG file to PERMANENT. Unfortunately, this PROJ_EPSG file is mssing in nc_spm_full_v2alpha2 which is used in the pipelines to perform tests.
The test data have been created in a NC sample project that did contain a PROJ_EPSG file, and the new test in v.in.ogr now correctly reports that input CRS (generated with EPSG) and project CRS (no EPSG) differ.

So either add this PROJ_EPSG file to nc_spm_full_v2alpha2, changing the CRS of this GRASS sample project, or regenerate the testdata with nc_spm_full_v2alpha2.

See also list of different versions of the NAD83 datum: https://geodesy.noaa.gov/datums/horizontal/index.shtml

[petrasovaa]

So either add this PROJ_EPSG file to nc_spm_full_v2alpha2, changing the CRS of this GRASS sample project, or regenerate the testdata with nc_spm_full_v2alpha2.

Adding the file would be easiest, no? This dataset is used for testing only I believe.

[metzm]

So either add this PROJ_EPSG file to nc_spm_full_v2alpha2, changing the CRS of this GRASS sample project, or regenerate the testdata with nc_spm_full_v2alpha2.

Adding the file would be easiest, no? This dataset is used for testing only I believe.

Probably yes. How can I update this nc_spm_full_v2alpha2.tar.gz?

[petrasovaa]

Probably yes. How can I update this nc_spm_full_v2alpha2.tar.gz?

It is downloaded from here: https://grass.osgeo.org/sampledata/north_carolina/nc_spm_full_v2alpha2.tar.gz

So @neteler would have access and probably someone else.

[echoix]

If the test dataset changes, make sure to clear the cache in GitHub actions, as I don’t think there was a check to go get the checksum of the dataset on the download server to make the cache key.

Changing a dataset like that, while it could be considered an immutable file, is hard to understand. How would we compare later on if something else had changed when recreating the archive? The old one wouldn’t be available

[metzm]

Probably yes. How can I update this nc_spm_full_v2alpha2.tar.gz?

It is downloaded from here: https://grass.osgeo.org/sampledata/north_carolina/nc_spm_full_v2alpha2.tar.gz

I know and have done so for testing, but someone would need to upload a new version. Even better, create a new one like nc_spm_full_v2beta1.tar.gz and use this one in the github pipelines.

The change by adding the PROJ_EPSG file is non-trivial because it changes the CRS of the sample dataset and thus not only CRS comparisons, but also coordinate transformation operations.

[metzm]

Is EPSG:3358 indeed the correct CRS for the NC sample dataset? Probably only @hmitaso can tell. The question is about the datum

North American Datum 1983

or

NAD83 (High Accuracy Reference Network)

For a new version of the sample dataset, the files PERMANET/PROJ_SRID and PERMANET/PROJ_WKT should also be added. PERMANET/PROJ_EPSG is deprecated because there are more CRS authorities than just EPSG: authority names known to PROJ are EPSG, ESRI, IAU_2015, IGNF, NKG, NRCAN, OGC, PROJ.

[hmitaso]

yes, it is NAD83(HARN) EPSG 3358 (see grassbook p. 38 and presentation <https://www.grassbook.org/wp-content/uploads/presentations/MitOSGeoDataFOSS4G9.pdf>), This is the reference info. <https://spatialreference.org/ref/epsg/3358/> For some reason the EPSG is not included on the dataset website <https://grassbook.org/datasets/datasets-3rd-edition/> neither it is in HISTORY (although it mentions switching the order of l1 and l2 to fit the EPSG definition) <https://www.grassbook.org/wp-content/uploads/grasslocations/HISTORY.txt> I hope this clarifies it, Helena Helena Mitasova Professor, Department of Marine, Earth and Atmospheric Sciences Distinguished Faculty Fellow, Center for Geospatial Analytics North Carolina State University Raleigh, NC 27695-8208 ***@***.*** <http://geospatial.ncsu.edu/osgeorel/publications.html>

[metzm]

@nilason @neteler any suggestions for a title for this PR? Right now it starts with v.in.ogr: which initially triggered this PR, but it includes modifications to r.external, r.in.gdal, r.import, v.external and v.in.ogr because the code base is nearly identical, including comments to keep the affected part of the C modules r.external, r.in.gdal, v.external and v.in.ogr in sync. I tried various alternatives (see above), but none was accepted by the title check.

[nilason]

The possibilities (currently) are defined here:

https://github.com/OSGeo/grass/blob/main/utils/release.yml

Maybe something like grass_proj: …. (In the end, it is mainly important for automatically generate News for releases.)

[nilason]

Maybe not a question we necessarily need to decide here and now, but maybe it is time (version 8.5) to require GDAL 3+ (two years since #2995) and PROJ 8+. If this PR is to be backported, then that definitely needs to be decided after merge.

[metzm]

Maybe not a question we necessarily need to decide here and now, but maybe it is time (version 8.5) to require GDAL 3+ (two years since #2995) and PROJ 8+. If this PR is to be backported, then that definitely needs to be decided after merge.

If this PR is to be backported, PR #6593 needs to be backported first because this PR depends on it.

The last really substantial changes to PROJ regarding CRS handling have been introduced with GDAL 3.1 and PROJ 6.2 (according to the GDAL API documentation), after that mostly new functionality and bug fixes have been added. Bumping the GRASS requirements to at least GDAL 3.1 and PROJ 6.2 would be a big relief for all maintainers of the GRASS interface to GDAL and PROJ.

[neteler]

Bumping the GRASS requirements to at least GDAL 3.1 and PROJ 6.2 would be a big relief for all maintainers of the GRASS interface to GDAL and PROJ.

Yesterday, at the GRASS-PSC meeting we even discussed if GDAL < 2 and PROJ < 8 support might be removed from main to simplify code maintenance. Of course a separate issue.

[nilason]

Looks good to me, thanks!