[PROJ] geoid model for GNTRANS2016 height

Javier Jimenez Shaw j1 at jimenezshaw.com
Fri May 2 04:13:13 PDT 2025


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20250502/648ee2cc/attachment.htm>


More information about the PROJ mailing list