[PROJ] Unexpected no NADCON5 transformations

Wed May 17 10:14:44 PDT 2023

Thanks Even for the detailed explanation. This is a labyrinth of
transformations.

Looks like the main culprit this time is "NAD83(2011) to WGS 84 (1), 2.0
m", that being a "not very accurate" transformation, is used in some cases
directly. If the "--accuracy" option is set to 1.9, then it tries the other
ones! (but of course, this is something very specific to this case)

The problem is that many data providers "use" WGS84 (as you know, I am not
a fan of it). In some cases with a vertical CRS, sometimes without. NMEA
messages directly include a geoid height in the elevation (I do not know
which model they use, really). So if the firmware wants to use ellipsoidal
heights, has to explicitly do the maths (if I am wrong here, I will
appreciate an explanation). That makes us "assume" that some devices
provide coordinates in EPSG:4979, and some in EPSG:4326+5773.

Cheers,
Javier

On Wed, 17 May 2023 at 18:02, Even Rouault <even.rouault at spatialys.com>
wrote:

> 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 listPROJ at lists.osgeo.orghttps://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/a1a7fa96/attachment.htm>