[PROJ] Using latest realization of a datum ensemble ?

[Greg Troxel]

This is about the details of my issue; skippable by many.

Even Rouault <even.rouault at spatialys.com> writes:

>> 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

Thanks.  I didn't dig into what proj does, and it's cool that it can
create this chain.

>> 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 ... ]

Sorry, I was being sloppy.  I guess formally bare NAD83 is defined to
mean NAD83(1986), but I think of it as the name for the ensemble.  NGS's
NCAT tool at https://www.ngs.noaa.gov/NCAT/ lists:

    NAD83(2011)
    NAD83(NSRS2007)
    NAD83(FBN)
    NAD83(HARN)
    NAD83(1986)
    NAD27
    USSD

But a quick check around me shows agreement at the roughly 10cm level
among all the NAD83 flavors.

>> 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 ?

yes, sorry.

> $ 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.

This is due to EPSG not having an ensemble, and EPSG/proj not having the
transforms among NAD83 realizations from NGS.   There should be a
transform

  NAD83(1986) to NAD83(2011), null, accuracy 10cm region new england

somehow.  Or maybe somewhat worse accuracy, region US - I see about 0.6m
around LA.  In AZ it's much better - on the NA plate, not PA plate.
Still, all of that's much better than ballpark.

>> and a now-correct null transform from WGS84
>> to ITRF2014).
>
> Did you mean WGS84 or WGS84 (G1762) ?

Well, I guess either. One is the ensemble transform where null makes
sense and the second is a transform where 0 makes sense as very accurate.

> 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

Interesting, because both datums are dynamic and should have matching
current epoch values.

> $ 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

It seems that ballpark transform should be listed as 2m accuracy.

Interestingly, NGS seems to say that WGS84(TRANSIT) can be treated (now)
as equivalent to NAD83(2011).

> (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)

Yes, that's best avoided :)

>> 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.

I suspect that is true for a lot of older imagery.  I also think that
newer imagery is being handled more carefully.  I will try to figure
that out and post a report (comparing MassGIS 2019 orthos, bing, and
oher OSM-approved imagery around me, with some independent ground
control via MaCORS RTK).

>> 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.

Agreed that needs fixing and that it's not obvious.  I'd have to say
that it refers to NAD83(1986), because that first realization was really
2D, and the later ones are 3D.  So I guess we need a new ensemble code.
But that's  for someone to take up with EPSG.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20201014/6a9752cc/attachment.sig>