It is relatively a common occurrence for GNSS receiver end users, particularly when they are still learning the ins and outs of the positioning devices, to find themselves in front of an apparently valid coordinate or trajectory that is off-setted a few decimeters from its expected location.

As a general rule of thumb GNSS errors are distributed around a mean value in a random way, meaning that the errors due to the positioning algorithms running on the GNSS receivers will go back and forth a given average value so how comes that sometimes there maybe a constant offset between a given coordinate or trajectory and it’s expected value?

With the exception of certain types of multipath the typical culprit for such a position offset is what is commonly referred to as “datum” or more precisely “Reference frame”.

Usually when we look at the Planet Earth from afar, like when using Google Earth, we perceive a “static ball” but is that really the case?

Typical representation of the Planet Earth where is near impossible to grasp that the major axis is 1.003 times the length of the short one (source: https://www.esri.com/news/arcuser/0610/nospin.html).

The Motion of Tectonic Plates and GNSS Accuracy

First of all, that ball is better described as a “revolution ellipsoid” which we can loosely describe as a ball with a tiny bit of flattening, this is the tridimensional shape that best fits the irregular shape of the surface of our planet.

But second and not less important, our planet is not rigid, it has what we call tectonic plates which are parts of the Earth crust that slowly displace and flex over the inner, hotter, fluid Earth core.

Planet Earth major tectonic plates (source: https://en.wikipedia.org/wiki/Plate_tectonics)

So a new and interesting reality emerges with the acknowledgment that Planet Earth is not a rigid body. If we create a coordinate system centered in the Earth center of mass, with an axis aligned with the Earth rotation pole (which, by the way, changes with precession and nutation movements of the planet but that would be matter for another article) and we force the condition that should rigidly rotate with the planet as a whole, not tied to any point of the surface but referenced to the background stars (no-net-rotation condition) we would obtain the famous WGS84 datum or reference frame.

WGS84 is the datum in which the Global Positioning System (GPS) has its ephemeris expressed. An ephemeris is the mathematical definition of each satellite orbit which is a basic element in the computation of the final position of the end user GNSS receiver. By extension if the GPS ephemeris are expressed in WGS84 datum the position of the rover receiver will also be expressed in that very same datum. So we already have enough pieces of the puzzle to put us in a conundrum, think about it, if we know that WGS84 rotates with Planet Earth not tied to any particular geographic point in Earth surface but we know that the Earth Crust displaces every year a bit so we come to the conclusion that if we measure a the coordinates of a point with GPS in Earth surface, after one year those coordinates will have changed.

You may wonder how fast the earth tectonic plates move in reference to the no-net-rotation WGS84, depending on the plate but the fastest tectonic plates displace at a speed of 10 centimeters every year.

GNSS base station crustal dynamics horizontal velocity in centimeters per year (mind the legend) (source: Jet Propulsion Laboratory, NASA)

Those displacements of the Earth crust can be measured by high end GNSS receivers and therefore need some sort of correction as otherwise our map coordinates, which in principle are a static representation of our physical world reality, would be noticeably wrong in a matter of years.

Datum Transformation: A Solution to Plate Tectonics

So now that we have established a problem we need to lay out a solution that gets us closer to the adagio “this point in earth's surface only has a single coordinate that doesn't change over time”, and the solution comes in the shape of a datum transformation. What would happen if we define a mathematical transformation that would tie a coordinate system to the tectonic plate that we are measuring coordinates into? The most obvious benefit of such an operation would be that the final coordinates of the GNSS receiver operating within the tectonic plate would not change over time, in other words, we would have solved the issue that WGS84 datum had. Datum names like North American Datum 1983 (NAD83), Geocentric Datum of Australia 2020 (GDA20), European Terrestrial Reference System 1989 (ETRS89) and others were born with the idea to fix the coordinates to the continent they were surveyed in.

So it’s all sorted out! If we survey something in a given geographic place we just need to use the correct datum and the coordinates measured by our GNSS receiver would be immediately tied to the “Ground” so problem solved!

Old datums used to be tied to each individual country, nowadays new datums are tied to tectonic plates, it does not make any sense to try to measure the Greenwich meridian (0º of longitude) monument in the UK with a GNSS receiver unless the proper datum is selected (source: https://www.telegraph.co.uk/news/science/science-news/11800441/Greenwich-Meridian-line-is-actually-334-ft-east...near-a-rubbish-bin.html and https://es.wikipedia.org/wiki/Meridiano_de_Greenwich respectively).

Practical Application and Challenges

Sorry to ruin the joy but not quite, up until now we worked under the assumption that tectonic plates were rigid but unfortunately they are not, they are somewhat flexible which means that those internal strains cause local velocity fields.

Let’s see a practical example, in Barcelona the WGS84 plate speed is 26 millimeters per year, when we switch to ETRF20, which is one of the re-computations of ETRS89, the yearly displacement is reduced from 26 mm per year to 1 mm per year, which is not bad but most likely we would like to achieve the 0 mm per year mark.

The only solution left to us is to establish a remaining velocity field, in Barcelona we know that is 1 millimeter per year but in southern Italy or Greece that number is considerably higher.

When we apply a velocity field we always refer our results to our given year, so for instance in Spain all the official cartography is referenced to ETRF20 epoch 2017.0

The datum transformation along the application of the crustal velocity field gives us the reference frame which is what we need to apply to the “raw” positioning output of our GNSS receiver if we want to be compatible with the local institutions and cartography.

On the left the horizontal velocity of the Delta de l’Ebre in Catalunya (East up and North down plots) in WGS84 datum (mind the plot Y axis scale), on the right the same velocities but instead of WGS84 you have the ETRS89 velocities (mind the plot Y axis scale) (source: http://geodesy.unr.edu/NGLStationPages/stations/EBRE.sta).

Conclusions

Whenever you use a GNSS receiver or a post processing software you must make sure the correct datum is chosen, this typically means that you should first ask yourself where the positions you are computing will be overlaid or injected into and then you must match your GNSS reference frame to that of your surrounding cartography.

In many occasions it is typical to see coordinates standalone with no contextual information, that is a bad practice as the very minimum information that must be included with each coordinates always is:

  • Reference frame
  • Reference epoch
  • Coordinates (ECEF XYZ and/or Latitude+Longitude+Height and/or projected X+Y+Z)
  • Error estimation associated to the aforementioned coordinates

Without all this information it is impossible to provide any trust to a set of coordinates.