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