[PROJ] Different transformation results between PROJ 9.0.0 and PROJ 9.0.1

[Greg Troxel]

Alexander Nehrbass via PROJ <proj at lists.osgeo.org> writes:

> I’m observing a significant difference between PROJ 9.0.0 and PROJ
> 9.0.1/master[c482ea8] when doing some coordinate transformations:
>
> $ echo 41.0 -122.0 0.0 | PROJ_NETWORK=ON ./cs2cs EPSG:4326+5773
> EPSG:2225+5703 -d 8
>
> 6561666.44282083    2247576.19215388 0.21377754 (in PROJ 9.0.0)
> 6561670.17486934    2247574.26932194 0.70338464 (PROJ 9.0.1/master)

I can't speak to why it's different, but you are on thin ice for
accuracy, or maybe you've fallen through already.

EPSG 4326 is the WGS84 ensemble, and 5773 is EGM96 height.

EPSG 2225 is a California State Plane that is in ftUS and "NAD83".
5703 is NAVD88 height.

So I would ask:

  When you want "WGS84" coordinates, are you ok with WGS84(TRANSIT)
  results?  Or do you want WGS84(G2159)?  What epoch do you want?

  Your input data is labeled NAD83.  Is it NAD83(1986)?  Or is it, as
  I'd guess, NAD83(2011) 2010.0?  (EPSG:6319 without the UTM/LCC transform.)

I would expect proj to give you a null transform from NAD83 to WGS84,
because they are both ensembles and NAD83(1986) is equal to
WGS84(TRANSIT).  But modern NAD83 and modern WGS84 are decidedly not
equal.

I'm in MA, and when I want to convert 6319 coordinates (e.g. obtained
from RTK with the MassDOT network) to "WGS84" for use in OpenStreetMap,
I transform to ITRF2014 as a proxy for recent WGS84.  Doing the analog
of what you are doing leads to an incorrect null transform and 1m of
horizontal error.

> 3. Related bonus question: I was under the impression that passing the
> -bbox option to projinfo would result in projinfo returning exactly
> one transformation. However, this seems in correct. Was I under the
> wrong impression? E.g.:

I don't think that's true.  I think bbox is going to enable selecting
transforms with non-global validity, such as grids that cover where you
are but not everywhere else.  But someone else will surely give you a
sharper answer on this point.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20220804/cd5ac7ce/attachment.sig>