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

Mon Jun 24 23:14:31 PDT 2019

This is a great discussion! I am happy to see that people outside of the
geodesy community is starting to realise that things can’t continue as they
have been. We’ve certainly done our fair share of the work here in PROJ
community but as Cameron points out there’s still some ways to go. From the
discussion it seems to me that everyone is converging towards a common
understanding of dynamic reference frames and what the challenges of them are.
I have worked quite extensively with the topic over the last couple of years
(see [0] for a summary) and there’s two important things that has not been
touched in this discussion yet:

1. WGS84 is practically equivalent to ITRF2008 and ITRF2014

The two frames coincide at the cm level [1] and hence there’s a
null-transformation between the two systems. This fact can be leveraged to
expand the number of direct transformation between WGS84 and regional/nation
frames. As Even pointed out often times the transformation between WGS84 and
national frame registered by the EPSG is a null transformation. Often times
there will be a transformation to a ITRFxxxx that offers better accuracy. This
of course requires that coordinates come with a timestamp, which brings me to
my next point:

2. GIS software does not offer reliable ways to store the observation time of
coordinates

To me this is the core of the problem in bringing dynamic reference frames into
practical use. Dynamic reference frames are inherently spatiotemporal - all
coordinates must consist of three spatial components and one temporal,
otherwise they simply are of no use. The timestamp of a coordinate has to be
the observation time of the coordinate and the timestamp must not be changed
during transformations (otherwise you can’t do the reverse transformation). If
those two criteria are met you can reliably transform between all reference
frames that are based on ITRFxxxx, for example between GDA94, WGS84 and GDA2020
as has been mentioned as currently being problematic in that regard.

So, if you keep track of time, it’s not all that difficult to work with dynamic
reference frames. The problem is that it is impossible in practice since there
is no standard that describes how to do this. The OGC Simple Features standard
which most file formats are based on simply doesn’t include time as a
dimension. At best, we can store X, Y, Z and M, with the M value being a
“measure” of some kind. This could in principle be observation times of the
coordinate but how would you distinguish between a time measure and some other
type of measure (e.g. a velocity)?

Cameron, if you want to take this up with the OGC, this is where you should
start. Most of what has been mentioned in this thread as problems are actually
solved in recent versions of PROJ and GDAL but we need GIS data formats that
can handle 4D coordinates before all those nice new features can be used to
their full extent. Most important is the Simple Features standard but I can
image that some minor tweaks will be needed in ISO19111 as well.

/Kristian

[0] http://www.geophysica.fi/pdf/geophysica_2019_54_kierulf.pdf
[1] ftp://itrf.ensg.ign.fr/pub/itrf/WGS84.TXT

On 25 Jun 2019, at 03:15, Nick Mein <nick_mein at trimble.com<mailto:nick_mein at trimble.com>> wrote:

Hi Evan, Cameron,

See https://docs.opengeospatial.org/as/18-005r4/18-005r4.html#116

That is a great document. Thanks for sharing!

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

It really depends on where you are working. Over most of the continental US you can consider NAD83(2011) to be a static reference frame. (I.e. you can consider the velocity of points to be zero.) But that isn't true if you are working in California.

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.

Right. But there is a solution to Cameron's practical problem, which is to transform his GDA94 dataset(s) to GDA2020.
In the longer term, we can all (practitioners, geospatial software providers) help clear up misunderstandings by being more precise with our terminology. Including pretending that there is such a thing as a precise WGS-84 coordinate, or that GDA, GDA2020, NAD83, etc are equivalent to "WGS-84".

Let's define a "global mosaiced static CRS", that is the union / pachwork of
the national/regional/continental CRS in current use.

I'm pretty sure that is what products such as Google Maps must do, though I'd love to get verification from someone that knows for sure.

A key point is - how do you access whatever reference frame you are using? Traditionally you would do that by locating physical marks on the ground, and looking up their published coordinates. Today, you are likely to using a real time GNSS corrections network, or a post-processing service such as OPUS/AUSPOS/etc, or you are going to be using a precise point positioning service. The coordinates that you get are going to be either in a local/regional reference frame such as GDA/NAD83/ETRF, or they are going to be ITRF. For (large scale?) web mapping applications, munging together data sets from different reference frames is fine. But ultimately you need to be able to drill down to the original data.

Regards,
Nick.

On Tue, 25 Jun 2019 at 05:04, Cameron Shorter <cameron.shorter at gmail.com<mailto:cameron.shorter at gmail.com>> wrote:

Thanks Doug, you have pointed me to Matt Higgins who is one of the Australians on this email's CC list. He has contributed toward identifying this problem. I believe we need to bring this conversation into an international forum, probably headed up by the OGC.

You might be able to suggest who we should connect with?

Warm regards, Cameron

On 24/6/19 11:30 pm, Newcomb, Doug wrote:
Cameron,
 I just emailed  someone working on this .  He sent me the links below.

https://www.gps.gov/governance/advisory/

https://www.gps.gov/governance/advisory/members/higgins/

Doug

On Thu, Jun 20, 2019 at 5:15 PM Cameron Shorter <cameron.shorter at gmail.com<mailto:cameron.shorter at gmail.com>> wrote:
Hi folks,

Our Australian spatial data users are about to face a systematic mismatch challenge when trying to use multiple static datums (GDA2020, GDA94) with the dynamic datum (WGS84). At the moment, it is government agencies grappling with the problem, but it is about to become a mainstream issue.

Australia now has static datums for the years 1994 and 2020 and uses WGS84 (a time-dependent datum!), for web-mapping and web-services.  We recognise:
1. Transforming from GDA94 to GDA2020 reflects Australia’s tectonic movement of ~ 1.8 metres to the North East.
2. GDA94 was defined as ‘equal to WGS84’ in 1994.
3. GDA2020  was defined as ‘equal to WGS84’ in 2020.
All three statements can’t be accurate. It results in mis-aligned maps in WGS84

I believe this is a problem the whole world needs to address, given the upcoming modernsation of significant national datums including the U.S and we need to bring this topic into an international conversation, ASAP.
I'm interested to know if anyone here is looking into and/or has opinions on how it should be solved. I'd like to incorporate your ideas into the recommendations that we are putting foward.
--
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254

--
Doug Newcomb - Cartographer
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 doug_newcomb at fws.gov<mailto:doug_newcomb at fws.gov>
---------------------------------------------------------------------------------------------------------

NOTE: This email correspondence and any attachments to and from this sender is subject to the Freedom of Information Act (FOIA) and may be disclosed to third parties.

--
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254

_______________________________________________
PROJ mailing list
PROJ at lists.osgeo.org<mailto:PROJ at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/proj
_______________________________________________
PROJ mailing list
PROJ at lists.osgeo.org<mailto:PROJ at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/proj

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20190625/92d8f2c7/attachment-0001.html>