Plans to support Geodetic data Grid eXchange Format (GGXF)

[gmoney1729]

Are there plans to support the newer OGC standard GGXF for geoid models? NGS recently published one in this format under their NAPGD2022 geopotential datum release.

Thanks.

[rouault]

Are there plans to support the newer OGC standard GGXF for geoid models?

Is there funding for that?

In the mean time they still do produce under their good old .b format which is handled by GDAL and could be used to produced a GeoTIFF file:

$ gdalinfo /vsicurl/https://alpha.ngs.noaa.gov/NAPGD2022/data/geoid2022/SGEOID2022.NA.N.v1.a.b
Driver: NOAA_B/NOAA GEOCON/NADCON5 .b format
Files: /vsicurl/https://alpha.ngs.noaa.gov/NAPGD2022/data/geoid2022/SGEOID2022.NA.N.v1.a.b
Size is 10801, 5401
Coordinate System is:
GEOGCRS["Unspecified geographic CRS",
    DATUM["Unspecified datum based on GRS80 ellipsoid",
        ELLIPSOID["GRS 1980",6378137,298.257222101,
            LENGTHUNIT["metre",1,
                ID["EPSG",9001]]]],
    PRIMEM["Greenwich",0,
        ANGLEUNIT["degree",0.0174532925199433],
        ID["EPSG",8901]],
    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]]]
Data axis to CRS axis mapping: 2,1
Origin = (169.991666666666674,90.008333333333340)
Pixel Size = (0.016666666666667,-0.016666666666667)
Corner Coordinates:
Upper Left  ( 169.9916667,  90.0083333) (169d59'30.00"E, 90d 0'30.00"N)
Lower Left  ( 169.9916667,  -0.0083333) (169d59'30.00"E,  0d 0'30.00"S)
Upper Right (     350.008,      90.008) (350d 0'30.00"E, 90d 0'30.00"N)
Lower Right (     350.008,      -0.008) (350d 0'30.00"E,  0d 0'30.00"S)
Center      (     260.000,      45.000) (260d 0' 0.00"E, 45d 0' 0.00"N)
Band 1 Block=10801x1 Type=Float32, ColorInterp=Undefined

[gmoney1729]

Not that I'm aware of at the moment but will keep my eyes peeled. I noticed that I could read the .b and .bin files for the 3 regional geoids except the NA geoid in .bin format where gdal throws an error 4. Not an issue, just an observation. Thanks.

[rouault]

keeping open, as this will (unfortunately) be something someone will have to address at some point

[busstoptaktik]

But note that the X in GGXF is for "eXchange". GGXF is by definition NOT for use in actual systems, but for exchange between system specific formats. Hence, PROJ should never directly support the use of the GGXF format, but might consider supporting the functional model behind it

[rouault]

but might consider supporting the functional model behind it

To clarify what I in mind: If/when we will "support" it, we'll convert to our internal format (GeoTIFF). So a set of scripts that would live in https://github.com/OSGeo/PROJ-data/tree/master/grid_tools

Regarding GEOID2022 specificity, the work is not just handling the format, but potentially extending our proj=gridshift operation to support the time-based velocity component that is added on top of the static geoid.

[jjimenezshaw]

But note that the X in GGXF is for "eXchange". GGXF is by definition NOT for use in actual systems, but for exchange between system specific formats. Hence, PROJ should never directly support the use of the GGXF format, but might consider supporting the functional model behind it

How is then NGS publishing GEOID2022.v1.a.ggxf?
Should GDAL read GGXF files and convert to GTG?

edit: this message had a race condition with @rouault ;)

[rouault]

Should GDAL read GGXF files and convert to GTG?

GDAL can somehow read them using its netCDF driver. What is missing is the georeferencing, since bright minds in the CRS SWG have decided, for good reasons I don't want to understand, and against my recommendation, not to use the netCDF CF conventions for georeferencing. At the end of the day, a GDAL driver is probably not needed. Some custom python script using h5py or the GDAL Python API will probably do the job.