<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Javier,</p>
<p>this is complicated... Assuming that PROJ is going to get
consistent results for all those variations of complex
transformations is a pipe dream</p>
<p>The use of NADCON5 for the EPSG:4979 to EPSG:6318+5703 is
actually a bit dubious, but not totally unexpected given what
there is in the DB and the logic of PROJ. When looking at all
transformations returned by projinfo, there is "Inverse of
NAD83(2011) to WGS 84 (1) + NAD83(2011) to NAVD88 height (3)"
which uses Geoid 2018 and a no-op transformation between
NAD23(2011) and WGS 84, whose total accuracy (remainder the way we
synthetize total accuracy from individual transformations is quite
naive, by adding individual accuracies) is 2.015 m. What is
selected given the point you transform is Inverse of NAD83(HARN)
to WGS 84 (3) + NAD83(HARN) to NAVD88 height (6) + NAD83(HARN) to
NAD83(2011) (NADCON5, CONUS) using Geoid 1999, a Helmert
transformation to go from WGS 84 to NAD83 (HARN) and the
NAD83(HARN) to NAD83(2011) concatenated operation chaining 3
NADCON5 grids, whose total accuracy is 1.14 m, hence its selection</p>
<p>For EPSG:4326+5773 to EPSG:6319, what is selected is "Inverse of
WGS 84 to EGM96 height (1) + Inverse of NAD83(2011) to WGS 84 (1)"
which uses the EGM96 grid + the no-op tranfomration between
NAD23(2011) and WGS 84. Why no NADCON5 grids here ? Because when
transforming between a compound CRS and a geographic 3D CRS, PROJ
looks for all transformations involving the vertical CRS (here
EGM96 height), and tries to find a relationsihp between the
geographic CRS/datum of the vertical transformation and the
geographic CRS/datum of the source and target transformations.
Here the EGM96 transformation uses WGS84 as the interpolation CRS,
which matches the source CRS, and there is a known transformation
between that interpolation CRS and the target CRS.</p>
<p>If one applies that logic to the first situation EPSG:4979 to
EPSG:6318+5703, things are much more complicated because EPSG:5703
NAVD88 height has transformations using different geoids and
NAD83(xxx) variants as interpolation CRS, hence the wild list of
transformations PROJ has to explore and synthetize.</p>
<p>EPSG:4979 to EPSG:6319 uses the direct "Inverse of NAD83(2011) to
WGS 84 (1)" transformation. When there is a direct transformation,
PROJ doesn't try, at least by default, to find more convoluted
transformation paths.</p>
<p>EPSG:4326+5773 to EPSG:6318+5703 uses "Inverse of WGS 84 to EGM96
height (1) + Inverse of NAD83(2011) to WGS 84 (1) + NAD83(2011) to
NAVD88 height (3)", that is EGM96 grid + no-op
WGS84<-->NAD83(2011) + Geoid2018. Very reasonable. Compound
to Compound is one of the most complicated case, with different
heuristics applied. Here I suspect what triggers is the "use the
geographic 3D CRS of the source CRS as a candidate intermediate
for the first step" and "use the geographic 3D CRS of the target
CRS as a candidate intermediate for the last step", and so this
goes through the EPSG:4326+5773 -> EPSG:4979 and
EPSG:6319->EPSG:6318+5703, and connect EPSG:4979 and EPSG:6319</p>
<p>What is certainly true is that in some of those inferences code
paths, PROJ takes sometimes shortcuts as soon as it has managed to
obtained reasonable transformation steps (ie no ballpark) from the
first heuristics it tries, otherwise in the most complicated
cases, the combinatorics explodes.<br>
</p>
<p>Even<br>
</p>
<div class="moz-cite-prefix">Le 17/05/2023 à 15:53, Javier Jimenez
Shaw a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CADRrdKvEcaMbu8jZmZeDST=ONwOMxk-fZShERVviT7RfT8HSOQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Hi devs,</div>
<div><br>
</div>
<div>I was going to get an order of magnitude of NADCON5
transformations added in PROJ 9.2.0 (+ PROJ-data), and I found
that they are not always applied.</div>
<div>As they are datum transformations, I would assume that they
are independent of the vertical system, but maybe I am wrong.</div>
<div><br>
</div>
<div>Going from WGS84(3D) to NAD83(2011) + NAVD88 height
produces different horizontal values than the input (what I
expected)<br>
</div>
<div><br>
</div>
<div><span style="font-family:monospace">$ echo 40 -100 0 |
PROJ_NETWORK=ON ./cs2cs EPSG:4979 EPSG:6318+5703 -d 8<br>
39.99999330 -99.99999115 25.47826194</span></div>
<div><br>
</div>
<div>However any other combination using 2D+vert or 3D is not
changing the horizontal coordinates.<br>
</div>
<div><br>
</div>
<div><span style="font-family:monospace">$ echo 40 -100 0 |
PROJ_NETWORK=ON ./cs2cs EPSG:4326+5773 EPSG:6319 -d 8<br>
40.00000000 -100.00000000 -25.05249596<br>
$ echo 40 -100 0 | PROJ_NETWORK=ON ./cs2cs EPSG:4979
EPSG:6319 -d 8<br>
40.00000000 -100.00000000 0.00000000<br>
$ echo 40 -100 0 | PROJ_NETWORK=ON ./cs2cs EPSG:4326+5773
EPSG:6318+5703 -d 8<br>
40.00000000 -100.00000000 -0.49709511</span></div>
<div><br>
</div>
<div>Enabling the debug messages, the first case is clearly
looking for the nadcon5 grids. The other 3 are not.<br>
</div>
<div><br>
</div>
<div>Is that expected?</div>
<div><br>
</div>
<div>Thanks.<br>
</div>
<div><br>
</div>
<div>
<div dir="ltr" data-smartmail="gmail_signature">
<div dir="ltr">
<div>.___ ._ ..._ .. . ._. .___ .. __ . _. . __.. ...
.... ._ .__</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
PROJ mailing list
<a class="moz-txt-link-abbreviated" href="mailto:PROJ@lists.osgeo.org">PROJ@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/proj">https://lists.osgeo.org/mailman/listinfo/proj</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>