[PROJ] [gdal-dev] Static/Dynamic datum problems

[Cameron Shorter]

Thanks Even, I really appreciate your feedback.

I'm pretty sure we have a problem which needs to be addressed at an 
international level - likely through the OGC.

I've drafted a one pager, in simple language, which incorporates 
feedback from both Joel Haasdyk and Even Rouault. The aim is to provide 
this doc to decision makers who are probably not technically across the 
details.

https://docs.google.com/document/d/15uBX2qICODRkiHXeksT0zEy6TuysanIxuc4anV0o5F0/edit#heading=h.e745vpszg17c

I'm unclear on the exact definition of WGS 84 and whether I'm explaining 
it correctly.

I'd also unclear on what URLs should be referred to from this type of 
document to reference different EPSG codes and the like.

All, feel free to reply with suggestions via email, or add comments into 
this document. (Please use your google login before doing so, so we can 
see who has said what).

For the record, the version of the doc I've just edited is version 1.2, 
and after Joel's prior review was 1.1.

Cheers, Cameron

On 21/6/19 7:26 pm, Even Rouault wrote:
>> 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.
>>
>> This has led to the situation we have in Australia where:
>>
>> WGS94 -transform-> WGS2020 (leads to a coordinate shift of ~ 1.8 metres)
>> WGS94 -null transform-> WGS84 (which was correct in 1994)
>> WGS2020 -null transform-> WGS84 (which will be correct in 2020)
> You likely meant GDA94 (instead of WGS94) and GDA2020 (instead of WGS2020).
>
> Yes, indeed if you look in the EPSG dataset, and transform between GDA94 and
> EPSG:4326 (the "average" WGS84 CRS), you'll get a null transform, but
> advertized with a 3m accuracy only, whereas direct transformation between
> GDA94 and GDA2020 has 1 or 5cm accuracy depending on which method is taken.
> And same for GDA2020. So there is no transitivity in chaining transformations.
>
> The thing is that EPSG:4326 is really a not super accurate CRS, given that its
> underlying datum is actually a "datum ensemble" in the modern geodetic
> terminology:
> http://docs.opengeospatial.org/as/18-005r4/18-005r4.html#53
>
> If you look at the candidate for the new CRS WKT revised standard
> https://portal.opengeospatial.org/files/81176
> you' ll see this
>
> 	ENSEMBLE["WGS 84 ensemble",
> 	  MEMBER["WGS 84 (TRANSIT)",ID["EPSG",1166]],
> 	  MEMBER["WGS 84 (G730)",ID["EPSG",1152]],
> 	  MEMBER["WGS 84 (G834)",ID["EPSG",1153]],
> 	  MEMBER["WGS 84 (G1150)",ID["EPSG",1154]],
> 	  MEMBER["WGS 84 (G1674)",ID["EPSG",1155]],
> 	  MEMBER["WGS 84 (G1762)",ID["EPSG",1156]],
> 	  ELLIPSOID["WGS 84",6378137,298.2572236,LENGTHUNIT["metre",1.0]],
> 	  ENSEMBLEACCURACY[2]
> 	]
>
> And I've heard that EPSG might consider to revise their future dataset to use
> that datum ensemble as the base for CRS EPSG:4326 to better reflect this
> reality, instead of basing it on the datum EPSG:6326, which is not really well
> defined.
> So mapping to EPSG:4326 makes only sense if you don't need accuracy lower than
> 2 meters.
>
> You might pick up one of the WGS 84 realization, and use the time-dependent
> transformations I mentionned in my previous email to go from GDA94 or GDA2020
> to that realization.
>
> Even
>
-- 
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254