Even Rouault via PROJ <proj@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. _______________________________________________ PROJ mailing list PROJ@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/proj
