My last tweet caused quite some confusion, so here's a quick summary of why the coordinates from your $65k GPS receiver (or stored in your 6 decimal-place GeoJSON database!) have an implicit inaccuracy 🌏 A thread:
The underlying issue stems from the widespread use of the dynamic WGS84 datum, and affects all coordinate reference systems which utilise this datum. This includes EPSG:4326 (which is mandated by the GeoJSON spec), and the widely used Web Mercator (EPSG:3857) CRS!
These reference systems are "dynamic", in that they aren't fixed to positions on the actual surface of the Earth.
In order to accurately locate an observation taken in a dynamic CRS, it's necessary to know not ONLY the lat/long (or x/y) coordinates, but also the time at which those coordinates were recorded. This time value is referred to as the "coordinate epoch".
You can have the exact same latitude and longitude in EPSG:4326 (right down to a ridiculous number of decimal places) point to DIFFERENT locations on the surface of the Earth if these coordinates have a different coordinate epoch! 😱
Let me repeat that for emphasis: the exact same coordinates in a WGS84 derived reference system can point to **DIFFERENT** places. So we need the three values in order to accurately locate objects. Latitude, longitude AND coordinate epoch.
Now, if I go out with a fancy enough GPS receiver and record some points there's nothing **inherently** inaccurate about those observations.
I could record them down to centimetre (or millimetre) level and so long as I've also recorded the time of each observation (the coordinate epoch), it's all good -- we know exactly where those coordinates refer to. Great! 🥳
BUT... here's the problem. There's **NO** standard way to share those coordinate epochs. NONE of the current spatial data formats support storage of coordinate epoch. The information is discarded, because there's just nowhere to put it.
Sure, I could (and should!!) put the epoch into a PDF (or TXT, or DOC, or email, or ...) metadata file which I supply with the data. But that's not a standard, and it's definitely not software-readable.
As soon as the points are saved into ANY existing spatial format like Geopackage, GeoJSON, Shapefile, KML, etc, OR are saved into a spatial database like PostGIS, SQL Server, etc... then the coordinate epoch is effectively lost.
We're left with just the lat/long values in a dynamic CRS, and are missing the required third value which is **needed** to accurately locate these points on the surface of the Earth.
Now, given there's NO spatial data format which supports storage of coordinate epochs ALL the applications and utilities and web services and EVERYTHING which consumes data in these dynamic coordinate reference systems will have to make some assumptions in order to use this data.
For instance, if you're comparing multiple datasets then your software (or web service) has to attempt to transform their spatial locations into a common reference system in order to overlay and compare them. (That's spatial data 101! 🧑🏫)
But since the software has no way of knowing the coordinate epoch of each dataset (that information isn't available for the software to read), it's going to have to make some assumptions. And right now, those assumptions result in a +/-2 meter uncertainty! 😱
So to summarise: regardless of how accurate the original survey work was, as SOON as those locations are stored in a **standard** spatial data format in EPSG:4326 (or EPSG:3857,...) they now have an inherent +/-2 meter uncertainty.
(Now the situation gets even murkier, because even if you had a PDF/TXT/DOC available and know the original coordinate epoch, it's still basically impossible in existing software releases to manually inform the software of that epoch so that transforms are handled accurately.
Basically it's ...kind-of... theoretically possible, but it's black magic which is beyond the reach of us mere mortals 🧙♂️)
What's the solution? Well... it's complicated. We'll (hopefully) start to see the introduction of standard means of storing the coordinate epoch in spatial data formats sometime.
That would allow the software to know the epoch of each different location it's working with, and accurately transform them as a result.
(The GDAL library devs have started implementing some non-standard ways of storing coordinate epochs, but that only helps if your entire workflow is in GDAL 😆-- their initiative may help to get traction on the necessary changes to standards though, so it's a good step forward!)
Depending on your GPS receiver, you may have an option to make the receiver itself handle transformation and storage of locations in a static CRS. But be careful here, and check with the manufacturer to confirm any assumptions that the receiver itself may be using if doing this.
Depending on your geographic region, you may have the option to store data in a static CRS. E.g. in Australia datasets can be stored in GDA2020 (or the older GDA94) systems, which are static CRSes with a fixed coordinate epoch.
Since GDA uses a fixed epoch software can retrieve the epoch from the CRS definition and handle it correctly! This doesn't always solve the problem though... e.g. if you want to store data in GeoJSON, you have NO choice but to use EPSG:4326. Ultimately, there's no easy answers.
This issue will be around for the foreseeable future (growing in importance as demand for accuracy increases). Ultimately it's our responsibility to understand the decisions and assumptions made by software, formats, and data providers we rely on so that we handle them correctly!
(geodesy experts/surveyors: please excuse some of the shortcuts I've taken here -- I'm trying to keep this as simple as possible! And if I’ve made any glaring mistakes/omissions here, please (nicely) let me know! 😆 )
