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

[Even Rouault]

>         In summary: the different releases of the WGS/ITRF are different,
> but this doesn't make them "dynamic datums": they are fixed, to the
> the Earth on average, but relative to that different parts of the Earth's
> surface are moving. Not a new problem, but one that complicates things.

I believe one hurdle in that area (at least for a non-geodesist / non-
geophysist professional like me) is that the terminology seems to be somewhat 
fluctuating depending on speakers and a bit confusing in itself (not speaking 
here about even more complex beasts like NZGD2000 "semi-dynamic" datum)

ITRF realizations are considered by the ISO TC211 / OGC CRS WG as Dynamic 
reference frame.
See https://docs.opengeospatial.org/as/18-005r4/18-005r4.html#116
Given their definitions, my understanding is that any datum / CRS into which 
you need to qualify coordinates with an epoch is considered as a dynamic datum 
/ CRS.
The IOGP "Geomatics Guidance Note 25 – Dynamic versus static CRSs and use of 
the ITRF" (
https://www.iogp.org/bookstore/product/geomatics-guidance-note-25-dynamic-versus-static-crss-and-use-of-the-itrf/ ) also classifies ITRF and WGS84 as 
dyanmic reference frames.

At bottom of page 16 of this guidance note, there is even a quite funny 
discussion about whether NAD83(2011) should be considered as a static or 
dynamic CRS... The bottom line seems to be that it is in essence dynamic, but 
in practice, it is recommended to always express coordinates at epoch 2010.00

~~~

But those terminology discussions don't solve Cameron's pratical problem which 
is  that when transforming data that is originally in GDA94 or GDA2020 to 
WGS84 or WebMercator (using WGS84), the recommended transformations in EPSG, 
ESRI, etc... are null transformations, causign misalignments when mixing 
sources from GDA94 and GDA2020.

Using "some" realization of WGS84 with coordinates expressed at "some" epoch  
is perhaps not the best solution, since there are not so many accurate 
transformations published from fixed-plate datum to WGS84. Looking at a few 
"modern" CRS, it seems they are snapshots of ITRF realizations, with published 
transformations to ITRF realizations.
For example EPSG:8049 is "ITRF2014 to GDA2020 (1)" with an accuracy of 1mm, 
but EPSG:8848 is "GDA2020 to WGS 84 (G1762) (1)" (which uses the same 
parameters as EPSG:8049, at the sign difference excepted, due to the different 
direction of the transformation), is advertized to have an accuracy of 20cm. 
There is no transformation published from GDA94 to any WGS84 realization other 
than the generic one.
ITRF being defined from many sources, including satelite positionning, I guess 
we can assume it is inherently more accurately defined, right ?. Using 
something ITRF based would also have the communication advantage to no longer 
use the "WGS84" word for such a global CRS, and thus mark the break with the 
current practice.

So one could:
- select a ITRF realization (currently ITRF2014), and a
more or less arbitrary coordinate epoch into which to express coordinates. 
- ask all mapping agencies to publish official coordinate operations (possibly 
concatenated operations when coming from older CRS) from the popular fixed-
plate CRS (or dynamic CRS if those are the one adopted!) to that ITRF 
realization. The data might be already there. For example if that would 
ITRF2014, for GDA2020, there is a GDA2020->ITRF2014 transformation. But for 
GDA94, which path should be taken: GDA94->GDA2020->ITRF2014, or GDA94-> 
ITRF2005->ITRF2014 or GDA94->ITF2008->ITRF2014, or ... ? But as the epoch that 
would be selected would never be the epoch at which all fixed-plate CRS are 
related to ITRF, you need transformations that take into account at least 
plate motion (15-parameter Helmert might be sufficient for that), but if you 
need more accuracy, you might also need deformation models (grid based).
- that procedure should be repeated every 5 or 10 years, so as to minimize the 
difference between up-to-date coordinates and the one of the CRS. So if you 
decide for a 5 year cycle, then the coordinate epoch could be the middle date 
of the cycle: for example for 2020-2025, use 2022.50, etc.

[[[[ (if you're a geodesit, make sure the ceiling is high enough :-)

Or... I've a completely crazy idea, likely unsound from a geodesic point of 
view, but that might have some practical merits...

Let's define a "global mosaiced static CRS", that is the union / pachwork of 
the national/regional/continental CRS in current use.
For example right now, we would use GDA2020 in Australia, ETRS89 in Europe 
(*), NAD83(2011) for USA, NAD83(CSRS)v7 for Canada, JGD2011 for Japan, etc...
One issue in the definition of this global CRS is that some of those 
constituent CRS are dynamic, so a coordinate epoch should also be selected for 
those (not necessarily the same globally though. you might use 2010.0 for 
NAD83(2011) and something else for NAD83(CSRS)v7.

Advantages :
- in most cases, no datum transformation needed if you operate with recent 
enough data. (or a well-known one, like GDA94->GDA2020, NZGD49->NZGD2000, 
etc...)
- the fact that there is no datum transformation is not only saving 
computation time, but also solves the practical issue of getting 
transformation parameters. Not all grids needed to do some accurate 
transformations are available as open data, or easily available at all.
- coordinates in that CRS would have a legal validity in all considered areas, 
if you've selected constituent CRS that have a legal value.

Drawbacks:
- inconsistencies at the border between those CRSs, let's say the USA - Canada 
border, so seamless maps will show annoying discontinuities in those areas. 
(but I'm thinking that even with the previous ITRF based approach, you would 
also have discontinuities, as the transformation parameters might not be 
consistent on each side of borders, but probably the shift would be one or two 
order of magnitude lower than the gross approach of the global mosaiced 
static CRS)
- related to that: distance measurements that span over several of those 
countries/continents, etc will have an inaccuracy of possibly some metre 
level, wheras measurements inside one of those region will be as good as the 
original datum is !
- those effects can be minimized if it is possible to use constituent CRS that 
are snapshots of close enough ITRF realization at a close enough same epoch...
- if a constituent CRS is a dynamic CRS, then you still have the complexity of 
doing time-based transformations.

Like the ITRF-based solution, that process should be repeated every 5 or 10 
years to take into account the adoption of new static regional CRS and define 
a new version of this global mosaiced static CRS. 
]]]]]

Anyway, I guess any solution based on a static global CRS will involve 
repeating the definition process at regular interval (to avoid the current 
mess with 'WGS84'), so that Earth-fixed positions measured today and the 
corresponding ones on the static CRS don't diverge too much.

In both cases, you could still use the WebMercator projection parameters to 
transform the geographic coordinates to projected ones. So that would not be 
EPSG:3857, but something similar based on the global CRS. Actually, if you use 
the ITRF-based approach, it would be rather good to adopt a 'real' Mercator 
projection doing computation on the ellipsoid, like EPSG:3395 "WGS 84 / World 
Mercator", instead of the botched Popular Visualisation Pseudo-Mercator method 
of EPSG:3857 that has unpleasant cartographic properties (non-conformal, see
https://www.slideshare.net/NGA_GEOINT/ngas-position-on-webmercator)

Even

(*) But this is also tricky since ETRS89 is a system with multiple ETRFyy 
realizations, linked to ITRFyy realizations. The latest is ETRF2014. Each 
country may adopt a different ETRS89 realization. For example RGF93, the legal 
system in France, happens to be ETRS89 by realization of ETRF2000 at epoch 
2009.00 (in its v2. RGF93 v1 was ETRS89 by realization of ETRF93 @1993.00).

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