[PROJ] Unexpected no NADCON5 transformations

[Even Rouault]

Hi Javier,

this is complicated... Assuming that PROJ is going to get consistent 
results for all those variations of complex transformations is a pipe dream

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

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.

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.

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.

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

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.

Even

Le 17/05/2023 à 15:53, Javier Jimenez Shaw a écrit :
> Hi devs,
>
> 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.
> As they are datum transformations, I would assume that they are 
> independent of the vertical system, but maybe I am wrong.
>
> Going from WGS84(3D) to NAD83(2011) + NAVD88 height produces different 
> horizontal values than the input (what I expected)
>
> $ echo 40 -100 0 | PROJ_NETWORK=ON ./cs2cs EPSG:4979 EPSG:6318+5703 -d 8
> 39.99999330 -99.99999115 25.47826194
>
> However any other combination using 2D+vert or 3D is not changing the 
> horizontal coordinates.
>
> $ echo 40 -100 0 | PROJ_NETWORK=ON ./cs2cs EPSG:4326+5773 EPSG:6319 -d 8
> 40.00000000 -100.00000000 -25.05249596
> $ echo 40 -100 0 | PROJ_NETWORK=ON ./cs2cs EPSG:4979 EPSG:6319 -d 8
> 40.00000000 -100.00000000 0.00000000
> $ echo 40 -100 0 | PROJ_NETWORK=ON ./cs2cs EPSG:4326+5773 
> EPSG:6318+5703 -d 8
> 40.00000000 -100.00000000 -0.49709511
>
> Enabling the debug messages, the first case is clearly looking for the 
> nadcon5 grids. The other 3 are not.
>
> Is that expected?
>
> Thanks.
>
> .___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
>
> _______________________________________________
> 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/20230517/0aa8acc5/attachment.htm>