[PROJ] Using latest realization of a datum ensemble ?

Mon Oct 12 16:02:26 PDT 2020

Hello list

I've been following this thread with interest particularly the discussion about how to best educate users. Below is a link to a paper containing interim advice to Australian users in the context of the GDA2020 implementation, that may be of interest to some on the list, and shows how we have tried to explain a number of these (complex) concepts to users.

https://www.icsm.gov.au/sites/default/files/GMIWG%20Advisory%20on%20WGS%2084%20and%20Web%20Mapping%20%E2%80%93%2015%20June%202020.pdf

Subsequent to the date of the paper (June 2020) there has been further engagement with EPSG and OGC to address the medium term solutions outlined in the paper.

Regards
Michael

Michael Giudici   |   Surveyor General   |  Branch Manager Location Services
Land Tasmania

Department of Primary Industries, Parks, Water and Environment
134 Macquarie Street Hobart TAS 7000
GPO Box 44 Hobart TAS 7001
T: 03 6165 4121   |   M: 0447 168 189   |   E: Michael.Giudici at dpipwe.tas.gov.au<mailto:Michael.Giudici at dpipwe.tas.gov.au>
www.dpipwe.tas.gov.au<http://www.dpipwe.tas.gov.au/>   |   www.thelist.tas.gov.au<http://www.thelist.tas.gov.au/>   |   www.tasmap.tas.gov.au<http://www.tasmap.tas.gov.au/>

[Facebook Land Tasmania]<https://www.facebook.com/landtasmania>

CONFIDENTIALITY NOTICE AND DISCLAIMER

The information in this transmission may be confidential and/or protected by legal professional privilege, and is intended only for the person or persons to whom it is addressed. If you are not such a person, you are warned that any disclosure, copying or dissemination of the information is unauthorised. If you have received the transmission in error, please immediately contact this Office by telephone, fax or email, to inform us of the error and to enable arrangements to be made for the destruction of the transmission, or its return at our cost. No liability is accepted for any unauthorised use of the information contained in this transmission.

If the transmission contains advice, the advice is based on instructions in relation to, and is provided to the addressee in connection with, the matter mentioned above. Responsibility is not accepted for reliance upon it by any other person or for any other purpose.

From: PROJ <proj-bounces at lists.osgeo.org> On Behalf Of Even Rouault
Sent: Tuesday, 13 October 2020 4:15 AM
To: proj at lists.osgeo.org
Subject: [PROJ] Using latest realization of a datum ensemble ?

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.

So there could be 2 options:

1) in addition to the lower resolution results, also consider the ones using the latest realization of the datum. and do that systematically

- Pro: more possibilities returned

- Con: more possibilities returned! (users might already be overwhelmed by current output which in some cases can offer of the order of 100 possibilities), and greater pipeline computation time (there are already optimizations/heuristics to avoid doing the advanced pipeline searchs, like using an intermediate CRS/datum, when direct ones are returned.)

- Pro or con: the default pipeline (that is the one used by cs2cs or proj_create_crs_to_crs() when the user has no say on the pipeline to use) would probably be in a lot of situation the high resolution one, which might be appropriate or not. The high accuracy pipelines also often need a coordinate epoch, so when it is not specified in the input coordinates provided to PROJ, the transformation will be done at the central epoch of the Helmert transformation.

In some circumstances, I imagine there might not be a transformation registered from/to the latest realization of a datum ensemble, but to an earlier realization.

2) or the same, but do that only on user request (projinfo switch, new function in C/C++ API).

- End users have to turn that on to benefit from the new capability

- Downstream software (like QGIS) has to make use of that new API, and possibly reflect that in its user interface.

I am a bit unconfortable about having PROJ being "too smart" by default with option 1. There are already known circumstances where it is too smart in a bad sense, such as in one of the above examples with WGS 84 to ITRF2014, using a NAD27 intermediate, or in https://github.com/OSGeo/PROJ/issues/2348

Even

--

Spatialys - Geospatial professional services

http://www.spatialys.com

________________________________
CONFIDENTIALITY NOTICE AND DISCLAIMER:
The information in this transmission may be confidential and/or protected by legal professional privilege, and is intended only for the person or persons to whom it is addressed. If you are not such a person, you are warned that any disclosure, copying or dissemination of the information is unauthorised. If you have received the transmission in error, please immediately contact this office by telephone, fax or email, to inform us of the error and to enable arrangements to be made for the destruction of the transmission, or its return at our cost. No liability is accepted for any unauthorised use of the information contained in this transmission.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20201012/16a6595d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 58240 bytes
Desc: image001.png
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20201012/16a6595d/attachment-0001.png>