[PROJ] Multifaceted Dynamic/Static datum problem

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[PROJ] Multifaceted Dynamic/Static datum problem

Cameron Shorter

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 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 accuracy. 

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:

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

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

  3. 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 applications.

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

PROJ mailing list
[hidden email]