[Feat] v.import should use best transformation option reproted by proj

[marisn]

Data transformation from EPSG:3059 to EPSG:10306 should be done with a hgridshift file, but GRASS defaults to noop transform.

To reproduce

grass -c epsg:10306 foo/bar/baz
v.import --verbose input=tp_92_20_92.gpkg output=tp_92
Using OGR driver 'GPKG/GeoPackage'
Coordinate reference system of input dataset and current project appear to match

Expected behavior

Data set is reprojected and GRASS uses best coordinate operation provided by proj.

System description

version=8.5.0dev date=2025 revision=ad6e958c27 build_date=2025-06-09 build_platform=x86_64-pc-linux-gnu build_off_t_size=8 libgis_revision=7cd2631711 libgis_date=2025-06-04T15:14:43+00:00 proj=9.6.0 * gdal=3.10.3 geos=3.13.1 sqlite=3.46.1

• note – you'll need proj 9.6.2 to have hgridshift out-of-box.

Additional context

projinfo -s epsg:3059 -t epsg:10306 -o proj
Candidate operations found: 2
-------------------------------------
Operation No. 1:

unknown id, Inverse of Latvian Transverse Mercator + LKS-92 to LKS-2020 (1) + Latvian Transverse Mercator, 0.02 m, Latvia - onshore and offshore.

PROJ string:
+proj=pipeline
  +step +proj=axisswap +order=2,1
  +step +inv +proj=tmerc +lat_0=0 +lon_0=24 +k=0.9996 +x_0=500000 +y_0=-6000000
        +ellps=GRS80
  +step +proj=hgridshift +grids=lv_lgia_lks92to2020.tif
  +step +proj=tmerc +lat_0=0 +lon_0=24 +k=0.9996 +x_0=500000 +y_0=-6000000
        +ellps=GRS80
  +step +proj=axisswap +order=2,1

-------------------------------------
Operation No. 2:

unknown id, Inverse of Latvian Transverse Mercator + Ballpark geographic offset from LKS-92 to LKS-2020 + Latvian Transverse Mercator, unknown accuracy, Latvia - onshore and offshore., has ballpark transformation

PROJ string:
+proj=noop

[marisn]

A file for testing: tp_92_20_92.zip

[metzm]

Do you have the grid files installed locally on your system?

From https://proj.org/en/stable/resource_files.html

When networking capabilities are enabled, either by API with the proj_context_set_enable_network() function or when the PROJ_NETWORK environment variable is set to ON, PROJ will attempt to use remote grids stored on CDN (Content Delivery Network) storage.

That means, if grid files are not installed locally and PROJ networking is not enabled, PROJ will use a transformation method without grid files because these are not available.

[marisn]

Do you have the grid files installed locally on your system?

Yes, of course. I was testing transformation issues in various other software (QGIS, MapServer, cs2cs etc.) where it worked fine. IIRC the issue is how GRASS determines if a transformation is required – if proj strings are compared, then EPSG:3059 to EPSG:10306 is a noop, but if proj itself is consulted, it will show a hgridshift option.

[metzm]

I see, the problem is the rather old G_compare_projections() used by r.in.gdal, r.external, v.in.ogr, v.external.

There are two possible solutions:

• optionally enforce reprojection with a new flag in r.import and v.import to always create a temp location with the SRS of the input data, then reproject. In this case G_compare_projections() would not be used, instead the PROJ mechanism would be used.
• replace G_compare_projections() with OSRIsSame from the OGR SRS API in the hope that this function is better at finding differences between SRSs

[marisn]

• replace G_compare_projections() with OSRIsSame from the OGR SRS API in the hope that this function is better at finding differences between SRSs

G_compare_projections should be deprecated as it doesn't cut with new approaches of SRS handling.

[metzm]

Wow:

With the new PR #6579 , github pipeline tests will fail if test data have been generated with nc_basic_spm_grass7 or nc_spm_08_grass7 which have an EPSG code in PERMANENT/PROJ_EPSG because github pipeline tests use nc_spm_full_v2alpha2 which does not have a PERMANENT/PROJ_EPSG file. Consequently, data import fails because the datums differ.

data:

    BASEGEOGCRS["NAD83(HARN)",
        DATUM["NAD83 (High Accuracy Reference Network)",
            ELLIPSOID["GRS 1980",6378137,298.257222101,
                LENGTHUNIT["metre",1]]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["degree",0.0174532925199433]],
        ID["EPSG",4152]],

nc_spm_full_v2alpha2

    BASEGEOGCRS["grs80",
        DATUM["North American Datum 1983",
            ELLIPSOID["Geodetic_Reference_System_1980",6378137,298.257222101,
                LENGTHUNIT["metre",1]],
            ID["EPSG",6269]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8901]]],

[nilason]

Wow:

With the new PR #6579 , github pipeline tests will fail if test data have been generated with nc_basic_spm_grass7 or nc_spm_08_grass7 which have an EPSG code in PERMANENT/PROJ_EPSG because github pipeline tests use nc_spm_full_v2alpha2 which does not have a PERMANENT/PROJ_EPSG file. Consequently, data import fails because the datums differ.

Nice debugging effort!