[PROJ] geoid model for GNTRANS2016 height

[Even Rouault]

Javier,

The epsg_definingoperation table of EPSG captures (among other defining 
operations) the HeightTransformation association of a VerticalCRS of OGC 
Abstract Topic 2 (https://docs.ogc.org/as/18-005r4/18-005r4.html), and 
the GEOIDMODEL[] node in WKT.

IMHO, this concept of "defining operation" is a unnecessary modelling 
complication. If there was *one* single defining operation allowed, I 
could perhaps understand it, but several ones are allowed (e.g. NAVD88 
is "defined" by all the US geoid models! see 
https://epsg.org/crs_5703/NAVD88-height.html), and I bet that if you try 
those different ones, they don't lead to the same value of NAVD88 
height.. So, I believe this is effectively redundant with the coordinate 
operation table.

The PROJ EPSG db importer doesn't import that epsg_definingoperation 
table and solely relies on the epsg_coordoperation table to figure out 
which transformation are available.

It seems to be that for this GNTRANS2016 height, this is more a hole in 
the EPSG db to not have a corresponding entry in epsg_coordoperation, 
unless they have a good reason for not doing that. Before implementing 
complications on our side to process epsg_definingoperation, I'd suggest 
you contact IOGP to check.

Even

Le 02/05/2025 à 13:13, Javier Jimenez Shaw via PROJ a écrit :
> Hi
>
> I found this vertical system:
> https://epsg.org/crs_9927/GNTRANS2016-height.html
>
> That has a geoid model definition. But the transformation used is not 
> "... to GNTRANS2016 height" but to "... to DHDN2016 height". Why? I do 
> not know. Probably they are considered equivalent for Deutsche Bahn 
> (yes, the railway company).
>
> Looking at the table "epsg_definingoperation" from the EPSG database 
> there is [lines are from a generated db, not the original sql]
> INSERT INTO "main"."epsg_definingoperation" ("crs_code", "ct_code") 
> VALUES ('9927', '9925');
>
> There is a similar one for "Alicante height", that works normally
> INSERT INTO "main"."epsg_definingoperation" ("crs_code", "ct_code") 
> VALUES ('5782', '9410');
>
> And there is no entry for "DHDN2016 height" (7837) in that table. But 
> there are transformations defined. Yes, the German vertical system and 
> geoid model works.
>
> I do not know what does it exactly mean that "defining operation". I 
> was expecting something like "the orthometric height is *defined* as 
> the ellipsoidal height minus that geoid undulation"  (so that geoid 
> file is not a "model", but a "definition") as they do in the new 
> American NAPGD2022. "By definition". But I have not seen it before. 
> (In Alicante height I am very surprised, because the vertical system 
> is really old).
>
> Anyhow, I think there is a missing connection in the proj.db between 
> "GNTRANS2016 height" and the geoid model transformation defined in 
> EPSG. I have the impression we are not using epsg_definingoperation at 
> all.
>
> Does it make sense to process it? Is "GNTRANS2016 height" the only one 
> without the connection?
>
> Cheers,
> Javier.
>
>
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj

-- 
http://www.spatialys.com
My software is free, but my time generally not.