<div dir="ltr"><div>Thanks Even</div><div><br></div><div>I already asked IOGP.</div><div><br></div><div>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:</div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace">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<br>from epsg_definingoperation AS edo<br>inner join epsg_coordinatereferencesystem AS ecrs<br>on edo.crs_code = ecrs.coord_ref_sys_code<br>left OUTER JOIN epsg_coordoperation AS eco<br>on edo.ct_code = eco.coord_op_code<br>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 || '%'</span><br><br><span></span><table border="1" cellspacing="0" cellpadding="2"><tbody><tr><th>crs_code</th><th>ct_code</th><th>coord_ref_sys_name</th><th>coord_op_code</th><th>coord_op_name</th><th>source_crs_code</th><th>target_crs_code</th><th>coord_op_accuracy</th></tr><tr><td style="font-family:"DejaVu Sans";font-size:10pt;font-style:normal;font-weight:normal;background-color:rgb(255,255,255);color:rgb(0,0,0);text-align:right">9927</td><td style="font-family:"DejaVu Sans";font-size:10pt;font-style:normal;font-weight:normal;background-color:rgb(255,255,255);color:rgb(0,0,0);text-align:right">9925</td><td style="font-family:"DejaVu Sans";font-size:10pt;font-style:normal;font-weight:normal;background-color:rgb(255,255,255);color:rgb(0,0,0);text-align:left">GNTRANS2016 height</td><td style="font-family:"DejaVu Sans";font-size:10pt;font-style:normal;font-weight:normal;background-color:rgb(255,255,255);color:rgb(0,0,0);text-align:right">9925</td><td style="font-family:"DejaVu Sans";font-size:10pt;font-style:normal;font-weight:normal;background-color:rgb(255,255,255);color:rgb(0,0,0);text-align:left">ETRS89 to DHHN2016 height (1)</td><td style="font-family:"DejaVu Sans";font-size:10pt;font-style:normal;font-weight:normal;background-color:rgb(255,255,255);color:rgb(0,0,0);text-align:right">4937</td><td style="font-family:"DejaVu Sans";font-size:10pt;font-style:normal;font-weight:normal;background-color:rgb(255,255,255);color:rgb(0,0,0);text-align:right">7837</td><td style="font-family:"DejaVu Sans";font-size:10pt;font-style:normal;font-weight:normal;background-color:rgb(255,255,255);color:rgb(0,0,0);text-align:right">0.1</td></tr></tbody></table><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, 2 May 2025 at 13:33, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Javier,<br>
<br>
The epsg_definingoperation table of EPSG captures (among other defining <br>
operations) the HeightTransformation association of a VerticalCRS of OGC <br>
Abstract Topic 2 (<a href="https://docs.ogc.org/as/18-005r4/18-005r4.html" rel="noreferrer" target="_blank">https://docs.ogc.org/as/18-005r4/18-005r4.html</a>), and <br>
the GEOIDMODEL[] node in WKT.<br>
<br>
IMHO, this concept of "defining operation" is a unnecessary modelling <br>
complication. If there was *one* single defining operation allowed, I <br>
could perhaps understand it, but several ones are allowed (e.g. NAVD88 <br>
is "defined" by all the US geoid models! see <br>
<a href="https://epsg.org/crs_5703/NAVD88-height.html" rel="noreferrer" target="_blank">https://epsg.org/crs_5703/NAVD88-height.html</a>), and I bet that if you try <br>
those different ones, they don't lead to the same value of NAVD88 <br>
height.. So, I believe this is effectively redundant with the coordinate <br>
operation table.<br>
<br>
The PROJ EPSG db importer doesn't import that epsg_definingoperation <br>
table and solely relies on the epsg_coordoperation table to figure out <br>
which transformation are available.<br>
<br>
It seems to be that for this GNTRANS2016 height, this is more a hole in <br>
the EPSG db to not have a corresponding entry in epsg_coordoperation, <br>
unless they have a good reason for not doing that. Before implementing <br>
complications on our side to process epsg_definingoperation, I'd suggest <br>
you contact IOGP to check.<br>
<br>
Even<br>
<br>
Le 02/05/2025 à 13:13, Javier Jimenez Shaw via PROJ a écrit :<br>
> Hi<br>
><br>
> I found this vertical system:<br>
> <a href="https://epsg.org/crs_9927/GNTRANS2016-height.html" rel="noreferrer" target="_blank">https://epsg.org/crs_9927/GNTRANS2016-height.html</a><br>
><br>
> That has a geoid model definition. But the transformation used is not <br>
> "... to GNTRANS2016 height" but to "... to DHDN2016 height". Why? I do <br>
> not know. Probably they are considered equivalent for Deutsche Bahn <br>
> (yes, the railway company).<br>
><br>
> Looking at the table "epsg_definingoperation" from the EPSG database <br>
> there is [lines are from a generated db, not the original sql]<br>
> INSERT INTO "main"."epsg_definingoperation" ("crs_code", "ct_code") <br>
> VALUES ('9927', '9925');<br>
><br>
> There is a similar one for "Alicante height", that works normally<br>
> INSERT INTO "main"."epsg_definingoperation" ("crs_code", "ct_code") <br>
> VALUES ('5782', '9410');<br>
><br>
> And there is no entry for "DHDN2016 height" (7837) in that table. But <br>
> there are transformations defined. Yes, the German vertical system and <br>
> geoid model works.<br>
><br>
> I do not know what does it exactly mean that "defining operation". I <br>
> was expecting something like "the orthometric height is *defined* as <br>
> the ellipsoidal height minus that geoid undulation"  (so that geoid <br>
> file is not a "model", but a "definition") as they do in the new <br>
> American NAPGD2022. "By definition". But I have not seen it before. <br>
> (In Alicante height I am very surprised, because the vertical system <br>
> is really old).<br>
><br>
> Anyhow, I think there is a missing connection in the proj.db between <br>
> "GNTRANS2016 height" and the geoid model transformation defined in <br>
> EPSG. I have the impression we are not using epsg_definingoperation at <br>
> all.<br>
><br>
> Does it make sense to process it? Is "GNTRANS2016 height" the only one <br>
> without the connection?<br>
><br>
> Cheers,<br>
> Javier.<br>
><br>
><br>
><br>
> _______________________________________________<br>
> PROJ mailing list<br>
> <a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
<br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
</blockquote></div>