[PROJ] grid shift with GDA2020

[Greg Troxel]

Pierre Chaponniere <pierrechapo at gmail.com> writes:

> Initially, data is in WGS84 (EPSG 4326), we use PROJ API to transform
> coordinates from WGS84 to a user selected transformation, in my case EPSG
> 7854
> My problem is that GDA2020 is expressed from GDA94 using the above
> mentioned transformation files.
> I'll therefore need to 'jump' from WGS84 to GDA94 and from GDA94 to GDA2020
> in one step, most probably using a pipeline - not sure how though...and if
> possible...a sort of two-transform in one go.

In addition to what Even said, note that WGS84 is an ensemble with a
large number of members.  In particular it contains WGS84(TRANSIT), the
original, and modern members such as WGS84(G2159).  There is a
significant, 2m very ish, shift, between the original member and the
modern members.  Labeling data with an ensemble means that the data is
in some frame that is an ensemble member but you don't know which one.
This is almost certainly not actually the case.  So you may want to look
into the data and understand what frame it actually is in.  Being
natively in WGS84 means it is is from non-differential GPS, and the date
of acquisition will lead you to the correct frame.  If it was natively
in something else and transformed, you might seek to back out that
transform and start from the native frame.

Assuming modern-ish WGS84, it seems that the transform to GDA2020 is
best approached via ITRF2014.  7854 contains:
  Approximation at the 3m level assuming WGS 84 is equivalent to
  ITRF2014 within the accuracy of the transformation. See GDA2020 to WGS
  84 (G1762) (1) (code 8448) for a better approximation and ITRF2014 to
  GDA2020 (1) (code 8049) for actual relationship.

However, none of that explains 80m.

Also, if you begin to care about a meter, you will need to process your
data with epoch labels.  Around me, people that care about things at the
meter level make and store measurements in the national crust-~fixed
frame.  But, if your data is truly WGS84, you have no hope of a meter,
unless you've done PPP with the broadcast orbits or something like that,
which would be highly unusual.
-------------- 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/20220630/dbef17d3/attachment.sig>