GNSS Correction Services and Geodetics
Part 4: GNSS Correction Services and Geodetics
In Part 2 of our ‘Geodetics Blog Series’ we talked about how geodetics in differential correction can be a common source of error for users collecting GIS data. In this blog post we will dive into a little bit more detail about this topic.
Geodetics of Differential Correction
In differential correction of GNSS data, whether in real-time or offline (post-processing), GNSS error is “removed” by comparing the data a user collects with data collected at one or more reference, or base, stations. The position of these reference stations is almost always known to a high degree of accuracy. As with any measurement of positions on the surface of the Earth, the coordinate must be expressed relative to some coordinate system, or reference frame (at least a datum and epoch). The results of differential correction will therefore always share the same reference frame as that of the correction source.
Types of Correction Sources
Correction sources can be generally considered local or global:
Local Correction Sources
Local correction sources depend on reference stations in local proximity to where the user is collecting data, with accuracy generally a function of distance from the reference stations. For real-time GNSS corrections, single-base and network Real-Time Kinematic (RTK) correction sources including VRS are the most common. Corrections from these sources are usually delivered over IP-based or radio connections. For offline (post-processed) GNSS corrections, Trimble Mapping and GIS software makes use of local base stations, many of which also participate in RTK networks.
In the case of these local correction sources, the reference frame is commonly a local reference frame, and specifically, the most current realization of the officially recognized datum for that area.
Some examples:
Region | Local Correction Source | Local Datum |
---|---|---|
United States of America | Trimble VRSNow |
NAD 1983 (2011) epoch |
United States of America | State/Regional Departments of Transportation, and other local networks1 |
NAD 1983 (2011) epoch 2010.00 |
UK | Trimble VRSNow | ETRF97 |
Europe | Trimble VRSNow | ETRS89 |
Europe | EUREF | ETRS89 |
1 Examples for Ohio, Minnesota, New York
Global Correction Sources
Global correction sources generally apply to a much wider area, if not the entire globe, and rely on a more dispersed network of reference stations. Real-time correction streams from global correction sources are generally delivered from L-band satellites, but Internet protocol (IP) streams can also be available. The most common global correction sources are Satellite Based Augmentation Systems (SBAS) available in North America, Japan, and Europe and Trimble RTX, available globally.
As with the local correction sources, the global correction sources also directly impact the coordinate system of the collected data through the reference frame used. In all cases, global correction sources will use a global reference frame (typically ITRF2014) at the epoch of measurement (EoM; the current date).
Some examples:
Region | Global Correction Source | Global Datum |
---|---|---|
Global | Trimble RTX | ITRF2020 EoM |
North America | WAAS (SBAS) | ITRF2014 EoM |
Japan | QZSS and MSAS (SBAS) | ITRF2014 EoM |
Europe | EGNOS (SBAS) | ITRF2014 EoM |
Relation of Differential Correction Datum to GIS Coordinate System
In many regions of the world, the local datum or reference frame used by local correction sources is the “same” as that commonly used by GIS customers when storing their data. By “same” we mean that it, or a closely related realization of the datum, is used in the coordinate system (geographic or projected) in which GIS data is stored. For example, in the United States, GIS data is often stored in a projected coordinate system based on NAD 1983 (2011) and as the table earlier shows, this matches the reference frame used by most local correction sources in the region.
However, in some regions of the world, the datum used by local correction sources is distinctly different from that commonly used to store GIS data. This is typically because the correction sources will utilize a local datum more closely aligned with the global datum used by GNSS. Fortunately, a datum transformation is generally well defined for such cases. In the table below, we illustrate some common examples of this:
Region | Local Correction Datum (typical) | GIS Coordinate System (typical) |
---|---|---|
UK | ETRF97 (frame of ETRS89) | OSTN15 (OSGB36) |
Netherlands | ETRF2000 (frame of ETRS89) | RD 2018 (Amersfoort) |
Software Handling of Corrected Data
During field data collection using GNSS, users will often use a mix of local and global correction sources, sometimes with the latter being a backup for the former. Additionally, data may be collected prior to when the real-time correction source is available, or delivering a real-time correction solution. Together, this means that the field data collection software needs to be able to dynamically deal with different coordinate systems and apply datum transformations as necessary to store collected data in a consistent coordinate system. The previous blog post discussed the various ways in which Trimble® TerraFlex™ does this and specifically allows for the use of both global and local correction services.
Similarly, in offline (post-processed) GNSS correction workflows, the office software needs to apply datum transformations as necessary to handle different coordinate systems among the collected GNSS data (which could have been corrected in real-time as well), the base station used for processing, and the GIS repository where the corrected data will be stored.