Grid alternative for gllmsl_2022.tif is not picked up

[kbevers]

When inspecting the transformation from GLLMSL to GVR2016 (EPSG:10566) PROJ tries to use the grid file that is registered with the EPSG (gllmsl_2022.tif) and not the PROJ-data alternative (dk_sdfi_gllmsl.2022.tif) that is available through the CDN. This results in errors both when creating the PROJ string and when trying to lookup the grid on cdn.proj.org. I suspect the latter causes the first problem.

$ cct --version                                                                                                                                      
cct: Rel. 9.4.1, June 1st, 2024

$ projinfo EPSG:10566 -k operation                                                                                                                    
PROJ string:
Error when exporting to PROJ string: Unimplemented GLLMSL(2022) height to GVR2016 height (1)

WKT2:2019 string:
COORDINATEOPERATION["GLLMSL(2022) height to GVR2016 height (1)",
    VERSION["SDFI-Grl 2022"],
    SOURCECRS[
        VERTCRS["GLLMSL(2022) height",
            VDATUM["Greenland Local Mean Sea Level (2022)"],
            CS[vertical,1],
                AXIS["gravity-related height (H)",up,
                    LENGTHUNIT["metre",1]],
            ID["EPSG",10565]]],
    TARGETCRS[
        VERTCRS["GVR2016 height",
            VDATUM["Greenland Vertical Reference 2016"],
            CS[vertical,1],
                AXIS["gravity-related height (H)",up,
                    LENGTHUNIT["metre",1]],
            ID["EPSG",8267]]],
    METHOD["Vertical Offset by Grid Interpolation (gtg)",
        ID["EPSG",1129]],
    PARAMETERFILE["Vertical offset file","gllmsl_2022.tif"],
    INTERPOLATIONCRS[
        GEOGCRS["GR96",
            DATUM["Greenland 1996",
                ELLIPSOID["GRS 1980",6378137,298.257222101,
                    LENGTHUNIT["metre",1]]],
            PRIMEM["Greenwich",0,
                ANGLEUNIT["degree",0.0174532925199433]],
            CS[ellipsoidal,2],
                AXIS["geodetic latitude (Lat)",north,
                    ORDER[1],
                    ANGLEUNIT["degree",0.0174532925199433]],
                AXIS["geodetic longitude (Lon)",east,
                    ORDER[2],
                    ANGLEUNIT["degree",0.0174532925199433]]]],
    OPERATIONACCURACY[0.02],
    USAGE[
        SCOPE["Change of height to a different vertical reference surface."],
        AREA["Greenland - onshore."],
        BBOX[59.74,-73.29,83.67,-11.81]],
    ID["EPSG",10566],
    REMARK["File format is GeoTIFF grid (.gtg) which is algorithmically equivalent to  the GTX format (see https://proj.org/en/9.3/specifications/geodetictiffgrids.html)."]]
Cannot open https://cdn.proj.org/gllmsl_2022.tif: HTTP error 404: <?xml version="1.0" encoding="UTF-8"?>
<Error><Code>NoSuchKey</Code><Message>The specified key does not exist.</Message><Key>gllmsl_2022.tif</Key><RequestId>3QAS2MX42MJN4HPB</RequestId><HostId>dSLj/ryiysm6oFfYXGKxZfwlpjekxUMvDIuZU4ULunsrxjec9IJcTo/ArrW/ePI2SvIsCURxB30=</HostId></Error>

Grid gllmsl_2022.tif needed but not found on the system.

dk_sdfi_gllmsl_2022.tif is available to download:

$ projsync --file dk_sdfi_gllmsl_2022.tif                                                                                                             
Downloading from https://cdn.proj.org into /Users/kevers/Library/Application Support/proj
Total to download: 129191 bytes
Downloading https://cdn.proj.org/dk_sdfi_gllmsl_2022.tif... (1 / 1)

... and having secured the file doesn't resolve the issue above (same error as above but without the WKT):

$ projinfo EPSG:10566 -k operation -o PROJ                                                                                                            
PROJ string:
Error when exporting to PROJ string: Unimplemented GLLMSL(2022) height to GVR2016 height (1)
Cannot open https://cdn.proj.org/gllmsl_2022.tif: HTTP error 404: <?xml version="1.0" encoding="UTF-8"?>
<Error><Code>NoSuchKey</Code><Message>The specified key does not exist.</Message><Key>gllmsl_2022.tif</Key><RequestId>93P1DG3AP6S0GQQT</RequestId><HostId>Y9wskE+4WGHimPjgP3evw3CRqrMgFo3rP4YZ6D0aPFpaNA7qT9jKUVIgdCWjzTFonW+xuTXqJRk=</HostId></Error>

Grid gllmsl_2022.tif needed but not found on the system.

[jjimenezshaw]

Don't you need the environment variable PROJ_NETWORK=ON ?
Otherwise it is not trying to access the network.

[kbevers]

If that was the case I would expect everything to work once the grid was projsync'ed. Also, it is quite clearly trying to access the networks since the error message is that it can't find the grid on the CDN.
But for good measure, no it doesn't help flipping the network switch to on:

$ PROJ_NETWORK=ON projinfo EPSG:10566 -k operation -o PROJ                                                                                            [9:57:53]
PROJ string:
Error when exporting to PROJ string: Unimplemented GLLMSL(2022) height to GVR2016 height (1)
Cannot open https://cdn.proj.org/gllmsl_2022.tif: HTTP error 404: <?xml version="1.0" encoding="UTF-8"?>
<Error><Code>NoSuchKey</Code><Message>The specified key does not exist.</Message><Key>gllmsl_2022.tif</Key><RequestId>ME7SSNS4GGWF9NV8</RequestId><HostId>52jiio9vO8qRFngOSpFymClNN0xPo0jSTeQ+0JGslZJrFD0rgPlmuGz0Sj7vAvq+OK1fMx3HsN4=</HostId></Error>

Grid gllmsl_2022.tif needed but not found on the system.

I think something is happening in the way grid-alternatives are used. The transformation is from one vertical CRS to another so the code probably takes a different path than for the more common case of geoid model transformation.

[jjimenezshaw]

Ok. I think I know the reason. The method code 1129 is new, and it is not considered in the c++ code.
I will do a PR.

Is this output enough?

projinfo EPSG:10566 -k operation -o proj -q
+proj=vgridshift +grids=dk_sdfi_gllmsl_2022.tif +multiplier=1

[kbevers]

+proj=vgridshift +grids=dk_sdfi_gllmsl_2022.tif +multiplier=1

This is what I expect, yes. Looks good!