What CRS should a drone orthomosaic and DEM be exported in?

Export in a projected CRS appropriate to your latitude and the survey's official datum, typically a UTM zone or a national grid (e.g. EPSG:32630 for UTM 30N, or a local plane). Use the same horizontal datum as your control points, and a defined vertical datum (geoid model) for heights.

Why is my drone DEM 30 metres higher than the survey ground?

Your DEM is almost certainly in ellipsoidal height (from raw GNSS/WGS84) while the ground survey is orthometric (height above the geoid/mean sea level). The geoid-ellipsoid separation is tens of metres in many regions; you must apply a geoid model to convert.

What is the difference between ellipsoidal and orthometric height in drone data?

Ellipsoidal height is measured from the reference ellipsoid and comes directly from GNSS. Orthometric height is measured from the geoid (approximately mean sea level) and is what engineers expect. They differ by the geoid undulation, which varies by location.

How do I reproject a drone GeoTIFF correctly without losing accuracy?

Use gdalwarp with explicit source and target CRS and a transformation pipeline, choosing bilinear or cubic resampling for continuous DEM/ortho data. Confirm the declared source CRS is correct first; reprojecting from a wrong CRS just moves the error.

CRS for Drone Mapping Outputs: A Practical Guide

Short answer

Drone mapping outputs (orthomosaics, DSMs, DTMs, point clouds) are only as trustworthy as the coordinate reference system they are tied to, and the failure mode that bites most teams is vertical, not horizontal. Raw GNSS gives you ellipsoidal heights on WGS84; engineers, surveyors, and national datasets expect orthometric heights on a geoid. Get the horizontal datum aligned with your ground control, pick a projected CRS suited to your latitude and the official grid, and apply the correct geoid model — then your deliverable will line up with the survey instead of floating tens of metres above it.

The two-axis problem

A drone deliverable carries two coordinate stories that fail independently:

Horizontal: which datum and projection the X/Y coordinates live in (WGS84 geographic, UTM, a national grid like British National Grid EPSG:27700 or a State Plane zone).
Vertical: what the Z values are measured from — the ellipsoid or the geoid — and on which realization.

Photogrammetry software (Pix4D, Agisoft Metashape, DroneDeck, OpenDroneMap) will happily produce a GeoTIFF that is horizontally fine and vertically 30–50 m off, and the map will still draw correctly. The error only surfaces when someone compares your DEM to a total-station survey or a national LiDAR tile.

Where the coordinates come from

The CRS of the output is inherited from how the survey was georeferenced:

Onboard GNSS only (no PPK/RTK, no GCPs): absolute accuracy of a few metres horizontally and worse vertically. Output is effectively WGS84 ellipsoidal. Fine for visual context, not for measurement.
Ground control points (GCPs): the model is fitted to surveyed marks. The output CRS must match the CRS the GCPs were surveyed in, including the vertical datum. If your GCPs are in EPSG:27700 with ODN orthometric heights, your deliverable should be too.
PPK/RTK on the drone: camera positions are corrected against a base station or network. Accuracy can reach 2–5 cm horizontal, but the heights are still ellipsoidal on whatever datum the base coordinates used unless a geoid is applied.

The rule: the output CRS is dictated by your control, not by preference. If control and imagery disagree on datum, you have a transformation to do, not a setting to flip.

Choosing the horizontal projection

For anything involving measurement (areas, volumes, distances, contours), export to a projected CRS, never to geographic lat/long. Picking the zone:

UTM is the safe general default: pick the zone for your longitude. UTM 30N is EPSG:32630, UTM 31N is EPSG:32631, southern-hemisphere zones use the 327xx range. Distortion stays low within a zone (scale factor ~0.9996 at the central meridian).
National grids are preferable when the deliverable feeds national datasets: British National Grid (EPSG:27700), Lambert-93 for France (EPSG:2154), State Plane zones in the US.
For very small, high-precision sites a local engineering grid with a project scale factor may be specified by the surveyor — match it exactly.

Avoid Web Mercator (EPSG:3857) for any computation: its scale distortion grows with latitude and areas/distances are wrong away from the equator.

The vertical datum, in detail

This is where most CRS problems in drone data actually live.

Ellipsoidal height (h) comes straight from GNSS, measured from the GRS80/WGS84 ellipsoid. Orthometric height (H) is measured from the geoid (a gravity-equipotential surface, roughly mean sea level). They are related by the geoid undulation N:

H = h - N

N is not small and not constant. It ranges from roughly -100 m to +85 m globally; over a single country it can vary by several metres. So a DEM left in ellipsoidal height can be off by a location-specific constant of tens of metres, and the offset slowly tilts across a large site.

You apply the geoid model with a defined transformation. With recent GDAL/PROJ you can warp using a compound CRS and a geoid grid:

# Inspect what the software actually wrote
gdalinfo ortho_dem.tif | grep -i -E "vertical|datum|EPSG|units"

# Reproject WGS84 ellipsoidal DEM to UTM 31N + EGM2008 orthometric height.
# PROJ resolves the geoid grid (e.g. egm08_25.gtx / us_nga_egm08_25.tif).
gdalwarp -s_srs EPSG:4979 -t_srs "EPSG:32631+3855" \
  -r bilinear -tr 0.10 0.10 -tap \
  ortho_dem.tif dem_utm31n_egm2008.tif

Here EPSG:4979 is 3D WGS84 (lat/long/ellipsoidal h), 3855 is the EGM2008 height datum, and 32631+3855 is the compound CRS. Use bilinear or cubic resampling for continuous surfaces; nearest-neighbour smears elevation. If your country has an official geoid model (e.g. OSGM15 for GB, RAF for France), use that grid rather than the global EGM model for survey-grade work.

Worked example: matching a survey

You receive a Metashape DEM that loads in QGIS but sits ~46 m above the client's total-station spot heights.

Diagnose, don't reproject blindly. gdalinfo shows the DEM is EPSG:32631 horizontally with no vertical CRS — a strong sign the Z is ellipsoidal.
Confirm the offset. Sample DEM elevations at three GCPs and compare to surveyed orthometric heights. The differences cluster around +46 m and vary by ~0.4 m across the site — consistent with a geoid undulation, not random noise.
Apply the geoid. Warp to the national geoid model so Z becomes orthometric. Re-sample at the GCPs: residuals should drop to a few centimetres.
Document the chain. Record source CRS (EPSG:32631 + ellipsoidal), geoid grid used, and output CRS (EPSG:32631 + national vertical datum).

Reprojecting without degrading data

Set, don't reproject, when metadata is missing. If the file has no CRS but you know the coordinates are EPSG:32631, assign it with gdal_edit.py -a_srs EPSG:32631 file.tif. Assigning a CRS does not move pixels.
Reproject when the coordinates need to physically change. gdalwarp resamples. Only do this once from the authoritative source to avoid compounding resampling blur.
Resampling choice matters. Bilinear/cubic for DEMs and orthos; nearest-neighbour only for categorical rasters (class masks). Never average a classification.
Pixel alignment. Use -tap and an explicit -tr so reprojected tiles align to a clean grid for mosaicking.

QA before you ship

GCP residuals: report horizontal and vertical RMSE at independent check points, not just the control used in the bundle adjustment.
Datum statement: every deliverable should name the horizontal CRS (with EPSG), the vertical datum, and the geoid model. "WGS84" alone is not a complete vertical statement.
Independent overlay: load the ortho against a known basemap or cadastral layer and confirm features land in the right place; load the DEM against a national elevation tile and confirm the heights agree.
Units check: confirm horizontal and vertical units (metres vs US survey feet matters in State Plane work — they differ by 2 ppm and accumulate).

Common pitfalls and why they happen

Floating DEMs — ellipsoidal height shipped as if orthometric. Happens because GNSS outputs ellipsoidal and the software default carries it through silently.
Mismatched control — GCPs in a national grid, imagery processed in WGS84, then "reprojected" after the fit, baking in the misalignment. Fix the datum before the bundle adjustment.
Web Mercator volumes — computing cut/fill in EPSG:3857; the area scale error inflates volumes, more so at high latitude.
Feet vs metres in US grids — a State Plane zone defined in US survey feet read as international feet or metres throws coordinates off by a predictable, easy-to-miss factor.

Bathyl perspective

We treat the CRS of a drone deliverable as part of the deliverable, not an export afterthought. A handover that names the horizontal EPSG code, the vertical datum, and the geoid model — and reports check-point residuals — lets the next surveyor trust the heights instead of rediscovering the geoid offset the hard way.

CRS for Drone Mapping Outputs