Debunking geodetics in specifications

The basis of any construction or charting project is the definition of an unambiguous, retrievable horizontal and vertical Coordinate Reference System (CRS). This should be included in the contract specifications. Nothing new here, but procedures from the past may no longer be suitable with modern positioning techniques such as PPP GNSS. While the horizontal CRS can be difficult, the vertical often poses even more of a problem due to ambiguous references during the design of a construction. Even when defined unambiguously, retrieving vertical reference levels is still difficult. In this article, I describe some of the issues from a hydrographic viewpoint, focusing on geodetic issues that should be addressed in the specifications.

Specifying a horizontal CRS

The horizontal CRS specifies how the results from the survey should be provided to the client. Often, this is a regional or national projected CRS such as the UTM projection. A projection alone is not enough and should be accompanied by a horizontal datum. This horizontal datum is often not the same as that provided by the positioning system (GNSS) and thus in addition a datum transformation with accompanying parameters is required. The most common datum transformation requires seven parameters.

This datum transformation requires particular attention. Many people ‘assume’ that the output from a GNSS is in the WGS84 datum. Looking at for example the NMEA0183 specification, which even states this, this is logical. However, the output CRS of a GNSS receiver is directly tied to the CRS of the augmentation system. An absolute GNSS (unaugmented GNSS, code phase dGNSS and PPP) outputs its positions according to a worldwide CRS. This can be WGS84, but most PPP systems output ITRF-based positions. Though WGS84 is kept to within 10cm of ITRF, there are some small differences which might be noticeable with PPP. To make matters worse, the Earth is not stable and, because of continental drift, ITRF (but also WGS84) is recomputed on a regular basis with the last iteration (epoch) being ITRF2020.

RTK outputs its coordinates in a CRS that is directly tied to the specified coordinates of the base station or network. In general, RTK is tied into a regional CRS such as ETRS89 in Europe or NAD83 in the US. The CRS used by a relative system drifts with the continental plate it is fixed to and as such horizontal positions on a regional CRS are relatively stable over time. Nevertheless, they are not fully stable due to changes in the plate orientation and new realizations (epochs) are created at intervals.

Datum transformations

This brings us to the issue of the datum transformation parameters. The output datum is effectively defined through the input datum from the GNSS and the datum transformation used. Different realizations of a horizontal datum require adjusted datum transformation parameters. The seven-parameter shift itself does not compensate for continental drift and as such the accuracy deteriorates over time (within a single survey a semi-constant error). This requires regular updates of the datum transformation parameters, something not necessarily done with copy-paste specifications. The alternative is 14-parameter shifts, which include the seven parameters and their change over time. These parameters can be used for a longer time but still need to be tied to the datum given from the GNSS receiver, which in turn depends on the augmentation used.

Often, the datum transformation parameters quoted do not match the output datum from the GNSS receiver. For example, the Netherlands uses an ETRS89 to Bessel 1841 datum transformation inshore and nearshore. If RTK is used, this requires a check of the ETRS89 epoch in the RTK network and a selection of the appropriate datum transformation parameters in the software. However, matters are more complicated if PPP is used. In this case, we have an ITRF2020 output that needs to be transformed to ETRS89, which then needs to be transformed to Bessel 1841. Ignoring the first step results in errors of around nine decimetres, which is too much for most construction projects. Specifications usually quote ETRS89 to Bessel 1841 conversion (through a combined ‘RDNapTrans’ conversion set) and most (all?) survey software can only handle a single conversion. So, how to deal with the first step?

Some GNSS receivers have the internal option to do a datum transformation. While this is technically not allowed by the NMEA0183 protocol, it does solve an issue. In this case, the ITRF2020 to ETRS89 (check the epoch!) is done in the GNSS receiver and the ETRS89 to Bessel 1841 in the survey software. However, not all receivers have this option. The alternative is to perform a ‘block shift’ in the survey software. Most software allows this on the projected coordinates. In this case, the first datum transformation is computed as a dE, dN shift in UTM (or other chart projection) and applied to the transformed coordinates. For an area of a few tens of kilometres wide, the resulting error is limited to the cm-level and usually acceptable.

LAT and MSL

If the horizontal datum is complicated, the vertical datum is even more so. Depending on the type of project, a tide-derived datum is often specified such as ‘LAT’ or ‘MSL’. The former is also recommended by the IHO as vertical reference (or a level close to this). There is however no such thing as LAT or MSL. Or, as the EPSG database states for MSL (and LAT): “Approximate because not specific to any location or epoch. Users are advised to not use this generic CRS but instead use one with a specific datum origin (e.g. ‘Mean Sea Level at xxx during yyyy-yyyy’) or defined through a specified geoid/hydroid model.”

In other words, tidal-based vertical datums should be specified for a specific place and with a specific epoch on which they are based. For MSL, this is easy to understand as we have all heard about sea-level rise. On average, MSL rises 4mm/year but this change is not the same for every location. LAT varies even more from location to location as it depends on the shape and amplitude of the tidal curve. As a result, LAT can change significantly (decimetres to metres) over just a few kilometres of coastline whereas MSL is relatively stable.

GNSS heights and the vertical datum

This is however only one aspect of the vertical datum. Nowadays, many projects are performed using GNSS for height measurements (RTK or PPP GNSS). As stated above, these output their position in a global (ellipsoidal) datum. However, most projects are not interested in ellipsoidal heights but require ‘something’ related to either an onshore datum or a tidal reference. To convert an ellipsoid height to an onshore, geoidal (orthometric) datum, a geoid-ellipsoid separation model is required. Though often stated to be the same, MSL and the geoid are not identical. Where the geoid is based on gravity, MSL is (traditionally) based on actual tidal measurements. The differences depend on the geoidal (onshore datum) definition but also on the tidal behaviour. The changes over time between the two not only depend on sea-level rise but also on land subsidence (or indeed uplift), where the onshore datum can be influenced by geological changes (depending on how it is defined).

As a result, GNSS heights need to be transformed from ellipsoid heights to geoidal heights and from thereon to an MSL or LAT value using a separation model. For some areas in the world, models exist that allow direct transformation from a GNSS datum to a LAT or MSL value. For other areas, two separate corrections or models are required, one to derive the geoid height from the GNSS datum and another to determine MSL or LAT from the geoid. Though differences between the height as derived from different GNSS datums are small (cm-level), they have a systematic effect nonetheless. Different models for deriving LAT and MSL potentially give different answers, even without regarding MSL rise and the accompanying LAT rise (relative to the GNSS datum – geoid).

Obtaining vertical offset values

It is possible to derive a local geoid-ellipsoid separation at relatively little cost providing at least one benchmark is available. The GNSS height should be recorded over this benchmark (preferably over an extended period, say 24+ hours) and when compared to the given benchmark height will provide an offset for that point. Using a levelling campaign around the project will allow further determination of additional points. Thus, with relatively small effort, a crude but effective local geoid-ellipsoid separation model can be created.

Deriving a local geoid-LAT offset requires tidal measurements with a tide gauge tied into the local, onshore datum. For a proper harmonic analysis, at least 18.6 years of data (continuous) are required. It is not impossible to derive LAT from shorter time series, but these have an inaccuracy that depends on how representative the conditions are for that period. For example, a 30-day measurement period can be influenced by short-term meteorological events such as storms and will not include seasonal influences. A 30-day harmonic analysis has an accuracy of centimetres to decimetres from the long-period LAT value. A year’s worth of measurements will provide a more stable value. If the project is short enough, a single value is sufficient. For longer projects or tidal measurements from some time ago, MSL rise should be incorporated in the vertical offset.

Specifications and geodetics

When writing specifications, all the above should be considered but not necessarily be solved by the specifier. The output horizontal CRS (including the local datum) should be specified, but the datum transformation can be left to the contractor if a control point coordinate is provided by the client on which the contractor can verify that the datum transformation has been implemented correctly. Alternatively, the specifier should state the exact datums and parameters to be used and keep these updated for consecutive projects.

The vertical datum should be specified using location and reference epoch or alternatively through a model (clearly stating which input and output from the model is required). It is advised to keep models constant for consecutive projects providing sea-level rise is not an issue. When switching between models, an investigation into the effects should be made.