Ellipsoidal height vs height above sea level

Ellipsoidal height equals orthometric height plus geoid undulation: h = H + N. Rearranged for the number you usually want, H = h - N. Everything below is about where N comes from and how wrong you are if you skip it.

N is negative over most of the world, including all of India, which means the geoid sits below the ellipsoid there and your GNSS height reads higher than the elevation you want. The global minimum, about 105 m below the ellipsoid, sits in the Indian Ocean south of the subcontinent. The global maximum is about 85 m above. The total spread is roughly 190 m.

N changes slowly across the ground - tens of centimetres over a few kilometres in most places - so within one site it behaves like a constant offset. That is exactly what makes it dangerous. A uniform 50 m error looks like a correct survey until someone compares it with a benchmark.

The geoid is the equipotential surface of the earth's gravity field that best matches global mean sea level. Put differently: the shape the oceans would take if they were free to flow everywhere, with no tides, currents or wind, responding only to gravity and rotation.

Because rock is denser than water and mountains are not evenly distributed, gravity is not uniform, so the geoid is bumpy. It is not an ellipsoid and no ellipsoid fits it closely. The ellipsoid is the smooth approximation that makes the maths tractable; the geoid is the surface that means something physically.

This is why heights referenced to the geoid are the ones that predict where water goes. A drainage design, a flood extent and a contour line are all statements about gravity, not about a mathematical reference surface.

EGM96 is the Earth Gravitational Model of 1996, a spherical harmonic model of the geoid complete to degree and order 360. It is the model almost every consumer GNSS device carries, and it is why a handheld receiver can display something labelled 'elevation' at all - internally it computes ellipsoidal height and subtracts an EGM96 undulation before showing you a number.

Its accuracy is usually quoted around 0.1 to 0.5 m one-sigma, with worst cases of 1 to 5 m in poorly surveyed and mountainous regions. That is fine for navigation and for knowing roughly how high a hill is. It is not survey grade, and it is not what you should use to deliver contours against a national vertical datum.

EGM2008 superseded it, with coefficients to degree 2190 and completeness to 2159 - about six times the resolution of EGM96, and three to six times the accuracy depending on quantity and region. Where a national geoid model exists it beats both: a study over South India found the local geoid and EGM2008 agreeing to within about 2 m, with the differences tracking the topography.

A DJI image can carry three different altitudes, and they mean three different things. RelativeAltitude is height above the takeoff point, which is the number the pilot flew to and is referenced to nothing outside that flight. GPSAltitude is the EXIF field, with GPSAltitudeRef flagging above or below sea level. AbsoluteAltitude is a DJI XMP field, and it is usually the same value that lands in GPSAltitude.

The honest answer to what AbsoluteAltitude is referenced to is: it depends on the model, the firmware and the altitude source, and published accounts contradict each other. Some documentation treats it as WGS 84 ellipsoidal. Other sources describe it as a barometric estimate of MSL derived from air pressure, which on a consumer drone can drift by tens of metres over a flight. Newer airframes expose an AltitudeType field with values such as GpsFusionAlt, which tells you which sensor produced the number.

This matters because photogrammetry software has to guess. A community manual for Metashape records that it treats EXIF GPSAltitude as ellipsoidal height, which is the wrong assumption for a DJI barometric value - and nothing in the processing will complain. The same images then produce a model that is internally consistent and vertically wrong.

The one thing you can do cheaply is look. Open your own images in the metadata viewer on this site and read all three fields plus GPSAltitudeRef, before deciding what the numbers mean. Nothing is uploaded; the parsing happens in your browser.

Horizontal errors get caught. Someone opens the data over a basemap, sees the site sitting in the wrong field, and asks a question. A vertical datum error produces a dataset that looks perfect in plan and is uniformly displaced in a direction nobody renders.

An RTK drone survey sold on centimetre accuracy, delivered in ellipsoidal height when the client's control is orthometric, is a product with a 50 m error and a 2 cm label. The relative geometry is excellent. Every absolute elevation is wrong by N.

The cost lands late. It shows up when the deliverable is compared against a benchmark, a flood study, an existing contour set or a neighbouring survey - which is usually after the aircraft, the crew and the processing have all been paid for.

There is a second, quieter version of the same mistake: mixing RelativeAltitude into anything absolute. Height above takeoff is meaningful only relative to wherever the drone happened to launch, so two flights of the same site from different launch points do not agree, and neither agrees with anything else.

It cannot convert your heights. The converter here runs proj4 in your browser, and proj4 cannot carry a vertical axis through a transformation - EPSG:4979, the three-dimensional form of WGS 84, is handled as its two-dimensional equivalent for exactly that reason. Applying a geoid model properly needs a gridded geoid file, which is a large binary and the same constraint that stops this site doing grid-based horizontal datum shifts.

What it can do is tell you what you have. The metadata viewer reads every altitude field your images carry, in the browser, so you can see whether you have a relative height, a barometric height or a GNSS height before anyone processes it.

For the actual conversion, use tooling that ships the grids: the National Geodetic Survey's GEOID models and VDatum in the United States, your national geodetic agency's model elsewhere, or PROJ with the relevant geoid grid installed. In India the Survey of India is the authority for the vertical datum, and the practical route is usually to tie the survey to a published benchmark rather than to trust any global model.

Whatever you use, write the vertical datum and the geoid model into the deliverable next to the horizontal one. A file that says 'WGS 84' and nothing else has not told anyone what its heights mean.