[gdal-dev] Static/Dynamic datum problems

[Even Rouault]

Cameron,

This would be more a topic for proj at lists.osgeo.org .

> 
> Our Australian spatial data users are about to face a systematic mismatch
> challenge when trying to use multiple static datums (GDA2020, GDA94) with
> the dynamic datum (WGS84). At the moment, it is government agencies
> grappling with the problem, but it is about to become a mainstream issue.
> 
> Australia now has static datums for the years 1994 and 2020 and uses WGS84
> (a time-dependent datum!), for web-mapping and web-services.  We recognise:
> 1. Transforming from GDA94 to GDA2020 reflects Australia’s tectonic
> movement of ~ 1.8 metres to the North East.
> 2. GDA94 was defined as ‘equal to WGS84’ in 1994.
> 3. GDA2020  was defined as ‘equal to WGS84’ in 2020.
> All three statements can’t be accurate.

Why ? I don't see a contradiction between those 3 statements, because as you 
mentionned, WGS84 is dynamic.

> I believe this is a problem the whole world needs to address,

I'm not sure to have understood what the problem you're facing to is exactly. 
Is it when combining data sources from several of those 3 CRS ?

There are transformation paths between GDA94 and GDA2020 in the EPSG dataset, 
with static Helmert-based or grid-based transformations.

With PROJ 6:
$ projinfo -s GDA94 -t GDA2020 --summary --spatial-test intersects
Candidate operations found: 5
EPSG:8048, GDA94 to GDA2020 (1), 0.01 m, Australia - GDA
EPSG:8447, GDA94 to GDA2020 (2), 0.05 m, Australia - onshore, at least one 
grid missing
EPSG:8446, GDA94 to GDA2020 (3), 0.05 m, Australia - onshore, at least one 
grid missing
EPSG:8445, GDA94 to GDA2020 (5), 0.05 m, Cocos (Keeling) Islands - onshore, at 
least one grid missing
EPSG:8444, GDA94 to GDA2020 (4), 0.05 m, Christmas Island - onshore, at least 
one grid missing

Mixing with data referenced to WGS84 is going to be more problematic, because 
of its dynamic nature indeed. So typically you will need to know if 
coordinates are expressed to one of the particular realizations of WGS84:
CRS EPSG:7816: WGS 84 (Transit)
CRS EPSG:7657: WGS 84 (G730)
CRS EPSG:7659: WGS 84 (G873)
CRS EPSG:7661: WGS 84 (G1150)
CRS EPSG:7663: WGS 84 (G1674)
CRS EPSG:7665: WGS 84 (G1762)

The EPSG datset contains coordinate operations between those WGS 84 or 
equivalent ITRF realizations, and GDA94 or GDA2020

To/from GDA2020:
- EPSG:8049: "ITRF2014 to GDA2020 (1)'" (Time-dependent Coordinate Frame 
rotation)
- EPSG:8448: "GDA2020 to WGS 84 (G1762)" (Time-dependent Coordinate Frame 
rotation)

To/from GDA94:
- EPSG:6276: "ITRF2008 to GDA94 (1)" (Time-dependent Coordinate Frame 
rotation)
- EPSG:6277: "ITRF2005 to GDA94 (1)" (Time-dependent Coordinate Frame 
rotation)
- EPSG:6278: "ITRF2000 to GDA94 (2)" (Time-dependent Coordinate Frame 
rotation)
- EPSG:6279: "ITRF97 to GDA94 (2)" (Time-dependent Coordinate Frame rotation)
- EPSG:6280: "ITRF96 to GDA94 (2)" (Time-dependent Coordinate Frame rotation)
- EPSG:6313: "ITRF96 to GDA94 (1)" (Time-dependent Coordinate Frame rotation)
- EPSG:6314: "ITRF97 to GDA94 (1)" (Time-dependent Coordinate Frame rotation)
- EPSG:6315: "ITRF2000 to GDA94 (1)" (Time-dependent Coordinate Frame 
rotation)
- EPSG:6392: "ITRF97 to GDA94 (1)" (Time-dependent Coordinate Frame rotation)

So it seems to me that the needed operations are there. GDAL 3 and PROJ 6 
should be able to use them. What is probably more difficult is to figure out 
the WGS84 / ITRF realization and the epoch in which your coordinates are 
expressed.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com