Coordinate Systems for Drone Data done correctly

Why coordinate systems determine project quality

For drone data, image quality and RTK accuracy are only part of the story. The actual project value depends on whether the deliverables are aligned to the correct reference system for planning, CAD, BIM and GIS.

Typical failures appear downstream: a GeoTIFF seems fine, but the exported DXF is offset; a point cloud imports into Revit, but shared coordinates are wrong; or heights are delivered as ellipsoidal GNSS heights when the project expects national physical heights.

For Voxelia-style workflows, the final output must therefore be both accurate and correctly referenced.

WGS84 vs. ETRS89: global navigation system versus plate-fixed survey system

WGS84 is the global geodetic system used by many GNSS devices, drone metadata fields and web maps. It is excellent for navigation and approximate location.

ETRS89 is tied to the stable Eurasian plate and is therefore better suited for time-stable engineering and survey work in Europe.

The Austrian BEV notes that the Eurasian plate moves roughly 2.5 cm per year to the northeast. For long-term project data, this is why a plate-fixed system matters.

EPSG also notes that ETRS89 and WGS84 may be treated as coincident within 1 metre for medium- and low-accuracy applications. For CAD, BIM, PV planning and precise surveying, that simplification is usually too coarse.

Germany, Austria, Switzerland: which systems are used in practice?

There is no single universal target system across DACH. The correct answer depends on the country, the client requirement and the downstream software stack.

In Germany, BKG describes DE_ETRS89 / UTM with official zones 31, 32 and 33. In planning practice, 25832 and 25833 are especially common.

In Austria, BEV publishes ETRS89 references and explicitly lists UTM zones 32N and 33N, while older MGI / Gauss-Krüger data remains common in legacy datasets.

In Switzerland, swisstopo defines LV95 as the official survey reference framework since 2017, making it the default expectation for many Swiss planning workflows.

Heights: ellipsoid, national vertical datums and physical heights

Horizontal reference is only half of the story. GNSS first gives ellipsoidal heights on a mathematical reference ellipsoid, while planning workflows usually need physical heights in a national vertical datum.

For Germany, BKG explicitly states that the GCG2016 quasigeoid allows transformation from ellipsoidal ETRS89 heights to DHHN2016 heights using H = h − zeta.

Swisstopo also separates horizontal and vertical references and provides transformations between LN02, LHN95 and European frames.

The practical takeaway is simple: every 3D delivery should state not only the horizontal CRS but also the vertical reference used for Z values.

Which systems work best for orthophotos, DXF, LAS and BIM?

The correct target system depends on the final deliverable. Raster, vectors, point clouds and BIM models all carry reference information differently.

A practical rule is: use clear projected metric systems for planning, ensure CRS metadata is explicit for point clouds, and define shared coordinates before any BIM handoff.

Delivery workflow for clean project data

Most coordinate-system problems can be avoided if the target reference is defined before processing and verified again before export.

1. 01

   Define the target system before processing

   Clarify the horizontal and vertical target reference with the downstream team before exporting anything.

2. 02

   Do not confuse RTK, PPK or GCP with the final CRS

   These methods improve georeferencing quality, but they do not by themselves define the final delivery system.

3. 03

   Check legacy stock data

   If existing CAD or BIM files use MGI, LV03 or a local engineering origin, transformation strategy must be decided explicitly.

4. 04

   Document the vertical reference separately

   State clearly whether heights are ellipsoidal or tied to a national/project vertical datum.

5. 05

   Deliver metadata with the files

   Include CRS name, EPSG code where relevant, vertical reference, units and any transformation note.

6. 06

   Test-import in the target software

   A real import into AutoCAD, Revit, GIS or PV software reveals offsets, axis issues and height problems immediately.

The most common real-world mistakes

Mistake one is assuming WGS84 is sufficient for every technical delivery.

Mistake two is mixing horizontal and vertical references, producing correct planimetric data with unusable heights.

Mistake three is ignoring legacy coordinate systems in existing CAD or BIM stock.

Mistake four is missing documentation. Without explicit CRS and height notes, the receiving team is forced to guess.