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.roua...@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@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
