[PROJ] WGS84 to GDA94 and GDA2020

[Greg Troxel]

Even Rouault via PROJ <proj at lists.osgeo.org> writes:

> Basically GDA94 ~= WGS84 at epoch 1994.0 and GDA2020 ~= WGS84 at epoch
> 2020.0
>
> So when you ask to transform between GDA94 and WGS84 a null datum
> transformation is a perfectly valid answer since they matched in
> 1994.0. As well as a null one between GDA2020 and WGS84 since they
> matched in 2020.0
>
> There are also alternate transformations available in the EPSG dataset
> where they consider that when transforming between GDA94 and WGS84,
> then the user could mean they assume this WGS84 to be a recent one, so
> you actually want to use the transformation between GDA94 and GDA2020

I know regular list users know this, but for Nigel:

  WGS84 is an ensemble, and contains WGS84(TRANSIT) which is a
  low-accuracy datum.  There is about a 2m shift between that and recent
  members.  Therefore you cannot expect better than 2m for anything
  involving data that is in "WGS84" (unqualified).

  People label data as WGS84 when really it is in some recent ensemble
  member.  Recent ensemble memers are high-accuracy datums which are
  essentially equivalent to recent ITRF.  The fix is to stop doing this.

  There is no way to get high-accuracy coordinates in WGS84, unless you
  are the US DoD.  But that's ok, because anybody who wants
  high-accuracy coordinates will use ITRF or a national/regional
  plate-fixed datum.

  WGS84 members, like ITRF realizations, are a dynamic datum.  If you
  care about 2m (both the ground motion in AU at 7cm/y over 30 years,
  ish, and the spread among WGS84 members), then you cannot use WGS84
  coordinates without an epoch.

  If you don't care about 2-4m, then I supsect you don't have a problem.


Even in the US, which is moving more slowly than AU, I have been using
NAD83(2011) epoch 2010.0 for all my RTK data.    I would suggest that
you banish WGS84 from your data world.