<div dir="ltr"><div dir="ltr">Thanks Evan, I'm switching this email to the proj email list as suggested.</div><div dir="ltr"><br></div><div>In answer to Evan's question:</div><div>> Why ? I don't see a contradiction between those 3 statements, because as you </div>> mentioned, WGS84 is dynamic.<div><br></div><div>I believe that the problem is that WGS84 is being used in webmapping situations as if it were a static datum, locked to a fixed epoch, and in other cases it is treated as if it were a dynamic datum.</div><div><br></div><div>This has led to the situation we have in Australia where:</div><div><br></div><div>WGS94 -transform-> WGS2020 (leads to a coordinate shift of ~ 1.8 metres)</div><div>WGS94 -null transform-> WGS84 (which was correct in 1994) </div><div>WGS2020 -null transform-> WGS84 (which will be correct in 2020)</div><div><br></div><div>I can see that I will need to write this up more clearly, which I'm in the process of doing. I'll share when done (early next week).</div><div><br></div><div>Cheers, Cameron</div><div><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 21 Jun 2019 at 08:20, Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Cameron,<br>
<br>
This would be more a topic for <a href="mailto:proj@lists.osgeo.org" target="_blank">proj@lists.osgeo.org</a> .<br>
<br>
> <br>
> Our Australian spatial data users are about to face a systematic mismatch<br>
> challenge when trying to use multiple static datums (GDA2020, GDA94) with<br>
> the dynamic datum (WGS84). At the moment, it is government agencies<br>
> grappling with the problem, but it is about to become a mainstream issue.<br>
> <br>
> Australia now has static datums for the years 1994 and 2020 and uses WGS84<br>
> (a time-dependent datum!), for web-mapping and web-services.  We recognise:<br>
> 1. Transforming from GDA94 to GDA2020 reflects Australia’s tectonic<br>
> movement of ~ 1.8 metres to the North East.<br>
> 2. GDA94 was defined as ‘equal to WGS84’ in 1994.<br>
> 3. GDA2020  was defined as ‘equal to WGS84’ in 2020.<br>
> All three statements can’t be accurate.<br>
<br>
Why ? I don't see a contradiction between those 3 statements, because as you <br>
mentionned, WGS84 is dynamic.<br>
<br>
> I believe this is a problem the whole world needs to address,<br>
<br>
I'm not sure to have understood what the problem you're facing to is exactly. <br>
Is it when combining data sources from several of those 3 CRS ?<br>
<br>
There are transformation paths between GDA94 and GDA2020 in the EPSG dataset, <br>
with static Helmert-based or grid-based transformations.<br>
<br>
With PROJ 6:<br>
$ projinfo -s GDA94 -t GDA2020 --summary --spatial-test intersects<br>
Candidate operations found: 5<br>
EPSG:8048, GDA94 to GDA2020 (1), 0.01 m, Australia - GDA<br>
EPSG:8447, GDA94 to GDA2020 (2), 0.05 m, Australia - onshore, at least one <br>
grid missing<br>
EPSG:8446, GDA94 to GDA2020 (3), 0.05 m, Australia - onshore, at least one <br>
grid missing<br>
EPSG:8445, GDA94 to GDA2020 (5), 0.05 m, Cocos (Keeling) Islands - onshore, at <br>
least one grid missing<br>
EPSG:8444, GDA94 to GDA2020 (4), 0.05 m, Christmas Island - onshore, at least <br>
one grid missing<br>
<br>
Mixing with data referenced to WGS84 is going to be more problematic, because <br>
of its dynamic nature indeed. So typically you will need to know if <br>
coordinates are expressed to one of the particular realizations of WGS84:<br>
CRS EPSG:7816: WGS 84 (Transit)<br>
CRS EPSG:7657: WGS 84 (G730)<br>
CRS EPSG:7659: WGS 84 (G873)<br>
CRS EPSG:7661: WGS 84 (G1150)<br>
CRS EPSG:7663: WGS 84 (G1674)<br>
CRS EPSG:7665: WGS 84 (G1762)<br>
<br>
The EPSG datset contains coordinate operations between those WGS 84 or <br>
equivalent ITRF realizations, and GDA94 or GDA2020<br>
<br>
To/from GDA2020:<br>
- EPSG:8049: "ITRF2014 to GDA2020 (1)'" (Time-dependent Coordinate Frame <br>
rotation)<br>
- EPSG:8448: "GDA2020 to WGS 84 (G1762)" (Time-dependent Coordinate Frame <br>
rotation)<br>
<br>
To/from GDA94:<br>
- EPSG:6276: "ITRF2008 to GDA94 (1)" (Time-dependent Coordinate Frame <br>
rotation)<br>
- EPSG:6277: "ITRF2005 to GDA94 (1)" (Time-dependent Coordinate Frame <br>
rotation)<br>
- EPSG:6278: "ITRF2000 to GDA94 (2)" (Time-dependent Coordinate Frame <br>
rotation)<br>
- EPSG:6279: "ITRF97 to GDA94 (2)" (Time-dependent Coordinate Frame rotation)<br>
- EPSG:6280: "ITRF96 to GDA94 (2)" (Time-dependent Coordinate Frame rotation)<br>
- EPSG:6313: "ITRF96 to GDA94 (1)" (Time-dependent Coordinate Frame rotation)<br>
- EPSG:6314: "ITRF97 to GDA94 (1)" (Time-dependent Coordinate Frame rotation)<br>
- EPSG:6315: "ITRF2000 to GDA94 (1)" (Time-dependent Coordinate Frame <br>
rotation)<br>
- EPSG:6392: "ITRF97 to GDA94 (1)" (Time-dependent Coordinate Frame rotation)<br>
<br>
So it seems to me that the needed operations are there. GDAL 3 and PROJ 6 <br>
should be able to use them. What is probably more difficult is to figure out <br>
the WGS84 / ITRF realization and the epoch in which your coordinates are <br>
expressed.<br>
<br>
Even<br>
<br>
-- <br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_-7628660361869709459gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div><span style="font-size:12.8px">Cameron Shorter</span><br></div><div>Technology Demystifier</div><div>Open Technologies and Geospatial Consultant</div><div><br></div><div>M +61 (0) 419 142 254</div><div><br></div></div><div><br><br></div></div></div></div></div></div></div></div></div></div></div>