[PROJ] Multifaceted Dynamic/Static datum problem

Cameron Shorter cameron.shorter at gmail.com
Fri Jun 28 00:03:47 PDT 2019

The dynamic/static datum problem we have been discussing appears to be
multifaceted. I feel it would be useful to define and then consider each
facet of the problem separately. Each has different characteristics and
there are different strategies that can be applied to each. Later we can
decide when, how and if we deal with each facet.

I’m interested to hear feedback. Have I’ve covered all the facets worth
mentioning? Am I using the right terminology? Do my descriptions make sense?

   1. Missing observation timestamp from coordinates:

Applications which capture coordinates will typically copy these
coordinates to a dataset on the server, in a specific datum.

Problem 1.1: In copying the coordinates to the server’s datum, the
coordinates’ observation timestamp is dropped. This means we won’t be able
to reverse engineer the (time, coordinate) when the observation was made.

Problem 1.2: An error is introduced when moving from the epoch of TODAY to
the epoch of the server’s datum. For example, an OpenStreetMap contributor
uses their mobile phone to create a track of their local street. When
loaded to the server, the latest WGS84 epoch is used instead of TODAY.

2. Using WGS84 dynamic datum as if it were static:

Problem 2.1: In many (most?) webmapping applications, the dynamic WGS84
datum is used as if it were a static datum:


   WGS84 based maps are fixed in time when they are tiled.

   Webmapping applications would typically collect and store coordinates in
   WGS84, fixing the coordinates at that point in time. (The datum moves on).

WGS84 Web Mercator is based on the WGS84 CRS (Lats, Longs), which is based
on “The World Geodetic System 84” which is defined in the EPSG Registry
<https://www.epsg-registry.org/> as a dynamic datum.

EPSG:3857 <- EPSG:4326 <- EPSG:6326

3. Webmapping has been topologically aligned, not always accurate:

To date web-mapping applications, based on the WGS84 datum, have been
precise but not always accurate. Or explained another way, within a region,
layers have been topologically aligned.

Problem 3.1: Webmapping has had tolerated low accuracy, as long as maps
were topologically aligned. However, EPSG definitions have focused only on

precision requirements and tolerance of low accuracy has not been
considered by providers of web services.

Problem 3.2: The poor accuracy of WGS84 Web Mercator has been masked from
system testers due to prior high precision. Effectively, there has been a
communication gap between the geospatial community and software developers
in understanding this problem.

4. Australia’s misaligned maps:

Australia is facing map mis-alignment challenges earlier than most due to
our advanced datum modernisation program

Australia now has static datums for the years 1994 and 2020 and uses the
time-dependent WGS84 datum for web-mapping. We’ve defined:


   Transforming from GDA94 to GDA2020 reflects Australia’s movement of ~
   1.8 metres to the North East.

   GDA94 is defined as ‘equal to WGS84’, accurate to 3 metres.

   GDA2020 is defined as ‘equal to WGS84’, accurate to 3 metres.

Problem 4.1: While technically correct, combining map layers from GDA94 and
GDA2020 sources into WGS84 results in systematically mis-aligned maps,
(although technically within the 3 metre tolerance).

5. WGS84 datum is tied to different epochs in different regions:

We could set a convention to use a specific WGS84 epoch for web mapping

Problem 5.1: In fact, different regions currently use different epochs of
WGS84. For example, Australia’s epoch of WGS84 is tied to GDA94 from 1994,
USA is tied to NAD83 from 2011 etc.

Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20190628/3cf43ed4/attachment.html>

More information about the PROJ mailing list