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@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/proj
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
PROJ mailing list
PROJ@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/proj
