[PROJ] Using latest realization of a datum ensemble ?

[Even Rouault]

Hi,

For people not interested in my detailed analysis of Greg's experimentations but by the 
updated subject of this email, go directly at the bottom, after the REAL SUBJECT label.

> There are precise transforms from NAD83(2011) to WGS84(G1762),

$ projinfo -s "NAD83(2011)" -t "WGS84 (G1762)" --summary
Candidate operations found: 1
unknown id, Conversion from NAD83(2011) (geog2D) to NAD83(2011) (geocentric) + Inverse 
of ITRF2008 to NAD83(2011) (1) + Inverse of WGS 84 (G1762) to ITRF2008 (1) + Conversion 
from WGS 84 (G1762) (geocentric) to WGS 84 (G1762) (geog2D), 0.01 m

And the detail is a time-dependent Helmet transformation for the "ITRF2008 to 
NAD83(2011)" part (with central epoch at 1997.0), and a null transformation for "WGS 84 
(G1762) to ITRF2008". So PROJ is already smart here, since there's no direct transformation 
between NAD83(2011) and WGS84 (G1762) in EPSG. It finds that the ITRF2008 intermediate 
is a likely intermediate since there are transformations registered between it and the 2 CRSs 
we are interested in

> I noticed that the gpx with ITRF when I added it was treated as WGS84
> (which is how gpx is defined) and given a null transform to NAD83.  That
> was easy to fix by labeling it ITRF2014.

Actually, between plain old NAD83 (86) and generic WGS84, you've got many non-null 
transformations using NADCON4 grids (like one grid per state), or a null transformation 
"NAD83 to WGS 84 (1)" with a 4m accuracy:

$ projinfo -s "NAD83" -t "WGS84" --summary --spatial-test intersects
Candidate operations found: 53
[... snip ... ]

> It also seems wrong that if I set project CRS to NAD83(2011) one thing
> happens (null transform from WGS84) 

> but if I set it to ITRF2014 another
> (proper transfrom from NAD83 

You probably meant NAD83(2011) here ?

$ projinfo -s "NAD83 (2011)" -t "ITRF2014" --summary
Candidate operations found: 1
unknown id, Conversion from NAD83(2011) (geog2D) to NAD83(2011) (geocentric) + Inverse 
of ITRF2014 to NAD83(2011) (1) + Conversion from ITRF2014 (geocentric) to ITRF2014 
(geog2D), 0 m

which is a time-dependent Helmert transformation with 2010.0 as central epoch

vs

$ projinfo -s "NAD83" -t "ITRF2014" --summary
Candidate operations found: 1
unknown id, Ballpark geographic offset from NAD83 to ITRF2014, unknown accuracy, World, 
has ballpark transformation

which is a null transformation synthetized by PROJ because it didn't find anything better.

> and a now-correct null transform from WGS84
> to ITRF2014).

Did you mean WGS84 or WGS84 (G1762) ?

Because

$ projinfo -s "WGS84 (G1762)" -t "ITRF2014" --summary
Candidate operations found: 1
unknown id, Conversion from WGS 84 (G1762) (geog2D) to WGS 84 (G1762) (geocentric) + 
WGS 84 (G1762) to ITRF2008 (1) + ITRF2008 to ITRF2014 (1) + Conversion from ITRF2014 
(geocentric) to ITRF2014 (geog2D), 0.02 m, World

which is a non-null time-dependent transformation

vs


$ src/projinfo -s "WGS84" -t "ITRF2014" --summary
Candidate operations found: 1
Note: using '--spatial-test intersects' would bring more results (17)
unknown id, Ballpark geographic offset from WGS 84 to ITRF2014, unknown accuracy, World., 
has ballpark transformation

(if using --spatial-test intersects as suggested, PROJ infers complicated transformations 
around Gulf of Mexico, since EPSG has a complex NAD27 to ITRF2014 concatenated 
operation valid for GoM, and PROJ thus does WGS84 -> NAD27 and NAD27->ITRF2014, which 
is probably much too ""smart"" / incorrect)

> 
> One theory is that it's a bug that TMS is defined in a datum ensemble,
> rather then being defined to be in the latest WGS84.  But that seems
> entirely unfixable.

EPSG:3857 (TMS) uses EPSG:4326 (generic WGS84 geographic CRS based on the EPSG:6326 
WGS84 datum ensemble). Actually I believe that a lot of imagery published in EPSG:3857 / 
TMS can be considered has being in a unknown datum, and if the souce imagery was in a GPS-
era datum, it is probably labelled as WGS84 for TMS purposes without applying any shift.


> My preferred theory is that while NAD83 and WGS84, whentreated as
> ensembles, can be said to have a null transform (in that the oldest
> versions of each can be said to match), that is not a reasoable
> approach, and that while one should not ascribe high accuracy to a
> transform with ensembles, the best choice oftransform is the one between
> the most recent member of each ensemble.

Regarding NAD83 and ensembles, I guess one issue is that currently there is no different 
EPSG datum code to distinguish NAD83(86) and "NAD83 ensemble". So some decision would 
have to be taken if the current EPSG:6269 datum code should be only for NAD83(86), or if it 
would represent the NAD83 ensemble. But I'm definitely not the one that has a say about 
that.

============
REAL SUBJECT
============

What is tricky in the suggestion to 'promote' to the latest realization of a datum ensemble is 
that you might have both low accuracy transformations that exist like shown above for 
NAD83 -> WGS84 and high accuracy for NAD83(2011) -> WGS84 (G1762) (here I assume that 
NAD83 would be an enssemble, which it is not formally currently). Depending on the 
situation, one or the other might be relevant.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20201012/1ce13cbe/attachment-0001.html>