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
