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

[Nick Mein]

Hi Duncan, Cameron,

Interesting discussion. As far as terminology is concerned, refer to, eg
Donnelly et. al Dynamic Datum Transformations in Australia and New Zealand
<http://ceur-ws.org/Vol-1142/paper6.pdf>:

The points being measured are attached to the surface of the Earth, which
is continually moving due to crustal
dynamics and other localised deformations. Thus if a point is regularly
re-measured, its coordinates will change to
reflect the reality that the point’s relationship to the centre of the
Earth has changed due to crustal dynamics. A
reference frame or datum which enables this changing position to be tracked
is referred to as ‘dynamic’.


I believe that is common usage. A reference frame in which coordinates of
points on the surface of the earth are more-or-less constant over time is
referred to as being "static" or "plate fixed". An exemplar is GDA2020. A
reference frame in which coordinates of points on the surface of the earth
are time dependent is referred to as being "dynamic".

As Cameron points out, this is muddied by the fact that WGS-84 was
originally considered to be a "static" datum, and is still treated as such
by a lot of software. See Mike Craymer's Making Sense of Evolving Datums:
WGS84 and NAD83 <http://www.naref.org/transf/nad83_hydroscan2006.pdf> for a
nice overview.

Cameron's proposed solution is:

To support web-mapping use cases, at centimetre level accuracy, we require
an internationally accepted static datum (and accompanying projection). As
WGS84 Web-Mercator has become the world’s defacto-standard, we propose that
the international community select, and lock in a specific WGS84 epoch
(date)


Actually, I suggest that the solution is more along the lines of making
sure that any spatial data set is clearly tagged with the reference frame
that it refers to. That gives us a chance of being able to combine data
sets. For example, if you have a data set referring to GDA94, with a known
accuracy, and you have a second data set referring to GDA2020, with a known
accuracy, and you have a transformation GDA94 -> GDA2020, with known
accuracy, then you can make a reasonable estimate of how well the two data
sets will fit together. In practice, the reference frame for a cm level
data set is going to be either one of the ITRF's (eg ITRF2014) or it is
going to be a national datum (eg GDA2020). We need to reserve the term
"WGS-84" to refer to positions based on broadcast GPS orbits - having an
accuracy of a couple of meters.

Regards,
Nick.


On Sun, 23 Jun 2019 at 19:00, Duncan Agnew <dagnew at ucsd.edu> wrote:

> All:
>
>         As a geophysicist who studies crustal deformation, I'll weigh
> in and say that the issue is not (I think) the dynamic nature of the
> datum, but plate tectonics.
>
>         Taking WGS84 (of various dates) to be matched to the various
> releases of the ITRF, I'd say that the latter is as fixed as it is
> possible to make it: origin at the Earth's center of mass, Z axis
> to the Conventional International Origin, X axis defined so the X-Z
> plane is parallel to the local vertical through Greenwich (to maintain
> continuity of Universal Time). The ITRF deals with plate tectonics
> by including a model of what the plate motions are, and then chooses
> a variation of orientation that makes the these motions,
> averaged over the Earth, zero: as close as we can get to "average
> Earth motion". As the data series get longer and the coverage better,
> there are new releases, but the differences between them are small.
>
>         What isn't small is the plate motion relative to this system:
> in it, a location on the Australian plate moves northeast at the rate
> of of 1.8 m from 1994 to 2020. This isn't because of updates to the
> datum, it is because the ITRF coordinate system is designed to be fixed
> relative to the average Earth. That is, the datum, and the coordinate
> system, is fixed, but the location of a point on the ground in that
> system varies with time.
>
>         The only way around this, so far as I know, is to include dates
> with coordinates and have some code that will allow you to convert
> measured coordinates between epochs. For Australia, Europe, and much
> of North America this is just a time-dependent shift that is nearly the
> same everywhere: on a plate boundary it is a lot more complicated, as
> is shown by the NGS HTDP program, which has lots of grids and allowances
> for earthquakes.
>
>         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.
>
>         Hope this clarifies rather than muddies.
>
> Thanks
> Duncan Agnew
> _______________________________________________
> PROJ mailing list
> 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/20190624/e6db64d6/attachment.html>