[PROJ] geoid model for GNTRANS2016 height

[Javier Jimenez Shaw]

Thanks Even

I already asked IOGP.

I made a query to their db (maybe a bit older version, not the last) and
got that this is the only case not covered properly:

select edo.*, ecrs.coord_ref_sys_name, eco.coord_op_code,
eco.coord_op_name, eco.source_crs_code, eco.target_crs_code,
coord_op_accuracy
from epsg_definingoperation AS edo
inner join epsg_coordinatereferencesystem AS ecrs
on edo.crs_code = ecrs.coord_ref_sys_code
left OUTER JOIN epsg_coordoperation AS eco
on edo.ct_code = eco.coord_op_code
where edo.crs_code not in (eco.target_crs_code, eco.source_crs_code) AND
eco.coord_op_name NOT like '%' || ecrs.coord_ref_sys_name || '%'

crs_codect_codecoord_ref_sys_namecoord_op_codecoord_op_namesource_crs_code
target_crs_codecoord_op_accuracy
9927 9925 GNTRANS2016 height 9925 ETRS89 to DHHN2016 height (1) 4937 7837
0.1

On Fri, 2 May 2025 at 13:33, Even Rouault <even.rouault at spatialys.com>
wrote:

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