[PROJ] Right way to do this transformation/projection : ITRF2014 -> WGS84 UTM

[Even Rouault]

On lundi 30 décembre 2019 13:04:50 CET Julien Schroder wrote:
> Hello,
> First I want to apologize as this is a bit of a beginner question but after
> hours of experimentation I am still confused.

I find this is a rather advanced one :-)

You didn't specify which PROJ version you use. You might get different results 
as we have refined such transformations over time.

Hint: the latest one will probably be the better.

> 
> I have coordinates in ITRF2014 (both in geocentric and geodetic
> coordinates) with an associated EPOCH which I am trying to
> transform/project to WGS84 UTM18N using pyproj/PROJ and EPSG codes.

The "WGS84" datum as used by EPSG:4326, EPSG:4979 or any projected CRS based 
on them such as EPSG:32618 is a "datum ensemble", that is one of the 6 
possible realizations of the "WGS84 (Gxxxx)" datums, and the accuracy of 
coordinates in this "datum ensemble" cannot be better than 2 meters, so you 
should only get null transformations when transforming between it and 
ITRF2014.

With PROJ 6.3, you'll get non-null transformations if transforming between 
ITRF2014 and "WGS84 (G1762)" (*)

$ projinfo -s ITRF2014 -t "WGS 84 (G1762)" --spatial-test intersects --summary
Candidate operations found: 2
unknown id, Conversion from ITRF2014 (geog2D) to ITRF2014 (geocentric) + 
Inverse of ITRF2008 to ITRF2014 (1) + Inverse of WGS 84 (G1762) to ITRF2008 
(1) + Conversion from WGS 84 (G1762) (geocentric) to WGS 84 (G1762) (geog2D), 
0.02 m, World
unknown id, Conversion from ITRF2014 (geog2D) to ITRF2014 (geocentric) + 
ITRF2014 to GDA2020 (1) + GDA2020 to WGS 84 (G1762) (1) + Conversion from WGS 
84 (G1762) (geocentric) to WGS 84 (G1762) (geog2D), 0.201 m, Australia - GDA

> During my experimentation I noticed that doing EPSG 7789 => EPSG 32618
> holds different results (about 4cm diffrence) than  EPSG 7789  => EPSG 4919
> => EPSG 32614

Hum, doesn't make sense to me. Can you demonstrate this with PROJ command line 
utilities ?

> Which surprised me as I thought that going from ITRF2014 to WGS84 involved
> a step through ITRF2000.

How did you see that ? In the above, the first result, which has worldwide 
validity, goes from ITRF2014 to WGS 84 (G1762) through ITRF2008. Because there 
is no direct transformation between ITRF2014 and WGS 84 (G1762) in the EPSG 
dataset (I presume the reason is that WGS 84 (G1762) must have been defined 
from ITRF2008)

Even

(*) well, this isn't completely true. If you try
projinfo -s ITRF2014 -t WGS84 --spatial-test intersects --summary
with latest PROJ 6.3, you'll get not-null transformations in the USA in the 
Gulf of Mexico, but I think they are questionable as they involve a lot of 
hoops through other CRS such as ITRF2008, NAD83(2011), NAD83 and NAD27 ! This 
is due to latest EPSG database having a complex NAD27->ITRF2014 concatenated 
operation for Gulf of Mexico (using the NAD83, NAD83(2011) and ITRF2008 
intermediates), and thus it is chained with transformations from NAD27 to 
WGS84...

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