Convert between Orthometric and Ellipsoidal Elevations using GDAL

When working with elevation data, sometimes you may discover that 2 datasets from different providers have very different elevation values for the same location. A common reason for this being each dataset being referenced to a different surface.

Orthometric (or geoid) elevation measures height of a point from mean-sea-level (MSL). Ground based surveys will produce orthometric elevations

Ellipsoidal elevation measures height of a point from a reference ellipsoid (such as WGS84). Elevations derived from space-borne platforms are usually ellipsoidal elevations.

Ellipsoids are a simple model of the earth’s surface and are defined using semi-major axis (a) and semi-minor axis (b). Geoid is a much more complex model as it attempts to model the gravitational force of the earth which is not uniform. There exists several models which define the geoid shape across the entire surface of the earth.

As both of these are mathematical models, it is possible to convert elevations from one reference to another. GDAL command-line tools are a free and easy way to do these conversions

Here I will show a real example of converting between 2 elevation datasets.

Cartosat-1 Digital Elevation Model (CartoDEM) is a National DEM developed by the Indian Space Research Organization (ISRO). It is derived from the Cartosat-1 stereo payload launched in May 2005. The Cartosat DEM is referenced to the WGS84 ellipsoid model (and hence have ellipsoidal elevation). The source data at 30m resolution can be downloaded from BHUVAN.

Shuttle Radar Topography Mission (SRTM) is an international project spearheaded by the U.S. National Geospatial-Intelligence Agency (NGA) and the U.S. National Aeronautics and Space Administration (NASA). During its 11-day mission, the space shuttle Endeavour orbited the Earth 16 times and captured Earth’s topography at 1 arc-second (30 meters) for over 80% of the Earth’s surface. An easy interface to download SRTM 30m data is the 30-Meter SRTM Tile Downloader. SRTM data is distributed with referenced to the EGM96 geoid model (and hence have orthometric elevations)

If you have installed QGIS, the gdal commands can be accessed via OSGeo4W Shell on Windows and Terminal on Mac/Linux.

The command needed to convert the dataset is gdalwarp. We need to supply it with a source spatial reference system (s_srs) and a target spatial reference system (t_srs) values.

Both the datasets have the same horizontal srs but a different vertical srs. So we can reference them using EPSG codes as follows:

SRTM = WGS84 ellipsoid with EGM96 elevation


Cartosat-1 = WGS84 ellipsoid with WGS84 elevation


So now the conversion between the 2 is a matter of specifying the source and target srs.

Below is the command used for converting Cartosat-1 DEM to orthometric elevation.

gdalwarp  -s_srs EPSG:4326+4979 -t_srs EPSG:4326+5773 cartosat.tif cartosat_orthometric.tif

If you load original cartosat.tif, cartosat_orthometric.tif and srtm.tif in QGIS, and inspect the elevation values, you can see the the cartosat_orthometric and srtm elevations match almost exactly now since they are referenced to the same geoid.

comparison of elevations between srtm, cartisat and cartosat_orthometirc

Above image contains a visualization of CartoDEM Version-3 R1 provided by National Remote Sensing Centre, ISRO, Government of India, Hyderabad, India.

PROJ Grids

GDAL using the PROJ library to carry out CRS transformations. PROJ uses pre-defined grids for datum transformations. Vertical datum transformations are defined using a GTX file. In the example above, when we did the transformation to EGM96 vertical CRS, it used the parameters supplied in the egm96_15.gtx file. Many such grid files are included when you download and install GDAL. But there are other grids which are very large and are not included by default. If you want to convert to a vertical datum whose grid files are not included by default, you need to download them separately and copy them to appropriate directory on your system. Learn more about PROJ Resource files.

One such vertical CRS is EGM2008 (EPSG:3855). Say you wanted to transform WGS84 heights to this new and more precise geoid model. You can run a command such as below

gdalwarp  -s_srs EPSG:4326+4979 -t_srs EPSG:4326+3855 cartosat.tif cartosat_orthometric.tif

But if you run it, you may get an error such as below

ERROR 1: Cannot open egm08_25.gtx.

This is because the EGM2008 grid is very large and is not included in many GDAL installations. To fix this, you can download the grid file from

Copy the egm08_25.gtx file to the PROJ resource directory on your computer. The location of this directory will depend on your platform and the installation method. Some common paths are as below

Windows: C:\OsGeo4W64\share\proj\
Mac: /Library/Frameworks/PROJ.framework/Resources/proj/
Linux: /usr/share/proj/

Once you copy the file, gdalwarp should be able to do the transformation correctly.


Leave a Comment

  1. Hello, I tried to follow the step but I have this message: ERROR 1: SetCompoundCS() fails, vertical component is not VERT_CS. Can you help me?

  2. Hi, Thank you very much for sharing this.
    I tried this on GSGeo4W Shell that comes with QGIS LTR, and
    confirmed that these all work well from 2.18 (gdal 2.4.0).
    For some reason, I get the following error:
    ERROR 1: SetCompoundCS() fails, vertical component is not VERT_CS.
    with 3.10 (gdal 3.0.4)
    Any idea what is going on and any workaround?
    Thanks in advance,

    • Works for me on OSGeo4W shell with 3.10. Can you paste your exact command line here. The error might be misleading as a typo can also cause this.

  3. FROM QGIS 2.18 > OSGeo4W Shell
    C:\>gdalinfo –version
    GDAL 2.4.0, released 2018/12/14

    C:\>gdalwarp -r cubic -s_srs EPSG:4326+4979 -t_srs EPSG:4326+5773 C:\!WIP\test\DSM.tif C:\!WIP\test\DSM2.tif
    Processing C:\!WIP\test\DSM.tif [1/1] : 0…10…20…30…40…50…60…70…80…90…100 – done.

    FROM QGIS 3.10.4 > OSGeo4W Shell
    C:\>gdalinfo –version
    GDAL 3.0.4, released 2020/01/28

    C:\>gdgalwarp -r cubic -s_srs EPSG:4326+4979 -t_srs EPSG:4326+5773 C:\!WIP\test\DSM.tif C:\!WIP\test\DSM2.tif
    ERROR 1: SetCompoundCS() fails, vertical component is not VERT_CS.
    ERROR 1: SetCompoundCS() fails, vertical component is not VERT_CS.
    Creating output file that is 689P x 528L.
    Processing C:\!WIP\test\DSM.tif [1/1] : 0ERROR 1: SetCompoundCS() fails, vertical component is not VERT_CS.
    …10…20…30…40…50…60…70…80…90…100 – done.

    Both create a new destination GeoTIFF file, but GDAL 3.0.4 won’t change the height value
    (and GDAL 2.4.0 does what I expected)

    Any idea?

  4. If you will upload a video or screenshot pics of the process then it will be clear to all. I have not found these projection projections ( srs EPSG:4326+4979, trs EPSG:4326+5773) in gdal warp option.

Leave a Reply