Is your data floating in the air? Or do you have two datasets that don’t align vertically? It’s very likely that you’ve used the wrong vertical datum. Often, the vertical datum associated with data isn’t specified, or even wrongly specified.

What is a vertical datum?

Before delving into the topic, it’s important to understand what a vertical datum is. A geodetic datum can be broken up into two components:

  • A horizontal datum is used to measure a location across the Earth’s surface, in some coordinate system, like longitude and latitude.

  • A vertical datum is used to measure the heights relative to a standard origin, such as mean sea level. In essence, it’s a level surface to which heights are being referenced.

Combined, the horizontal and vertical datums provide a three-dimensional geodetic coordinate system.

Heights might be depth below the ground, height above the ground, elevation above sea level, and so forth. They all involve some kind of measurement starting from a specific reference point, which is the vertical datum.

Common types of vertical datums include:

  • The surface of the ellipsoid, resulting in ellipsoidal height. An ellipsoid, in the context of geodesy and geography, represents a mathematically described surface that approximates the shape of the Earth.

  • The mean sea level as described by the gravity geoid, resulting in orthometric height. The geoid is often expressed as a geoidal height above/under a reference ellipsoid. Adding the geoidal height of a location to the orthometric height results in an ellipsoidal height for that location. The geoid is a more accurate representation of the shape of the Earth than an ellipsoid is. The geoid surface is irregular, unlike the reference ellipsoid, but is considerably smoother than Earth’s physical surface.

Vertical Datum Diagram
Figure 1. Relationship between ellipsoidal height, orthometric height and geoidal height

Knowing which vertical datum is used in measurements is critical because different datums can provide different measurements for a location’s height or depth.

Detecting vertical datum issues

Vertical datum issues often become evident when you’re integrating different datasets. For example, an otherwise flat surface may suddenly display unexpected jumps or fall-offs. Your data may become inconsistent, it might partially appear underneath the terrain layer, or be "floating" above the terrain.

One manual check you can do is comparing key elevations to a reliable, known source. If there’s a discrepancy, it could indicate a mismatch in vertical datums. Some example sources are:

  • Topographic maps: contains topographic maps which can be used to check the height above geoid (orthometric heights) of certain locations.

  • PROJ.org Datumgrid CDN: this CDN contains GeoTIFF datasets that represent various geoids. These datasets can be used to compare different geoid and ellipsoid values at a certain location.

Correcting vertical datum issues

If you’ve detected a vertical datum issue, follow these steps to resolve it:

Verify the vertical datum

Start with identifying and confirming the vertical datum for each dataset. Most datasets should come with metadata specifying the vertical datum. However, this metadata is often missing or wrong. You can retrieve the vertical datum information from a file by decoding your file and extracting the vertical datum name from the TLcdGeodeticDatum of the model’s ILcdModelReference.

Program: Program: extracting vertical datum information from a ILcdDataSource
public static Optional<String> decodeVerticalDatumName(ILcdDataSource aSource) throws IOException {
  ILcdModelDecoder decoder
      = new TLcdCompositeModelDecoder(TLcdServiceLoader.getInstance(ILcdModelDecoder.class));
  TLcdModelMetadata modelMetadata = decoder.decodeModelMetadata(aSource);
  return modelMetadata.getModelReference()
                      .filter(modelReference -> modelReference instanceof ILcdGeoReference)
                      .map(modelReference -> (ILcdGeoReference) modelReference)
                      .map(ILcdGeoReference::getGeodeticDatum)
                      .filter(datum -> datum instanceof TLcdGeodeticDatum)
                      .map(datum -> (TLcdGeodeticDatum) datum)
                      .flatMap(TLcdGeodeticDatum::getVerticalDatumName);
}

Fix incorrect vertical datums

If you identify files that contain incorrect vertical datum information, you must correct this information. You can do this by configuring the application that produces the data so that it correctly sets the vertical datum or use third-party tools like exiftool to override the metadata of your GeoTIFF files, for example.

This isn’t always straightforward, so LuciadLightspeed offers a way to override model references in its API. You can do so by including a compound WKT reference .prj file, containing correct vertical datum information, next to the file that you want to fix. The reference file must have the same file name as your data file, with a .prj extensions.

Example: compound WKT reference containing the EGM96 geoid as vertical datum
COMPD_CS["WGS84 + EGM96",
  GEOGCS["WGS84 + EGM96",
     DATUM["WGS84 + EGM96",
     SPHEROID["WGS_1984",6378137.0,298.257223563],
     TOWGS84[0.0,0.0,0.0,0.0,0.0,0.0,0.0]],
     PRIMEM["Greenwich",0.0],
     UNIT["Degrees",0.017453292519943295]
  ],
  VERT_CS["EGM96 geoid height", VERT_DATUM["EGM96 geoid",2005],UNIT["Meters",1.0]]
]

Once you have placed a reference file next to your data file, you must configure the model decoder to give priority to the external reference file. By default, external files are only used if the reference information is completely missing from the data file. Currently, you can change this priority for the LAS/LAZ, GeoTIFF, and E57 formats using the following properties:

  • com.luciad.format.las.TLcdLASModelDecoder.referenceDecoderPriority

  • com.luciad.format.raster.TLcdGeoTIFFModelDecoder.referenceDecoderPriority

  • com.luciad.format.e57.TLcdE57ModelDecoder.referenceDecoderPriority

To give priority to the external reference file, you must set these properties to EXTERNAL_FIRST. This is explained in more detail in the Setting model reference decoder priority article.

Use accurate terrain data

If you’re combining high-precision LAS point cloud data for example, scanned close to the terrain, with inaccurate terrain layers, you may encounter issues where your point cloud is partially under the terrain or floating above the terrain. If you use high-precision point cloud data, it’s important that you combine it with high-precision terrain data, using the same geoid as your point clouds.

If there’s no terrain layer at all, all Luciad portfolio products will display the WGS84 ellipsoid instead.