Koordinatensysteme bei Drohnendaten richtig wählen

Warum das Koordinatensystem über Projektqualität entscheidet

Bei Drohnendaten geht es nicht nur um Bildqualität, GSD oder RTK-Fix. Ebenso wichtig ist die Frage, in welchem Bezugssystem die Ergebnisse vorliegen. Ein Orthofoto im falschen CRS ist für Planungsteams praktisch wertlos, weil es nicht deckungsgleich zu Kataster, BIM-Modell, Dachbelegung oder Bestandsplan liegt.

In der Praxis treten Fehler oft erst nachgelagert auf: Ein GeoTIFF passt scheinbar, die exportierte DXF liegt aber mehrere Dezimeter bis Meter daneben. Eine Punktwolke wird in Revit importiert, aber die Shared Coordinates stimmen nicht. Oder Höhen werden als ellipsoidische GNSS-Höhen geliefert, während das Projekt physikalische Höhen im nationalen Höhensystem erwartet.

Für Voxelia-relevante Workflows ist deshalb nicht nur die Genauigkeit der Erfassung entscheidend, sondern die saubere Georeferenzierung des Endprodukts. Das gilt für PV-Dachmodelle, Fassadenaufmaße, Lagepläne, Punktwolken, Orthofotos und BIM-Handoffs gleichermaßen.

WGS84 vs. ETRS89: globales Navigationssystem gegen plattfestes Vermessungssystem

WGS84 ist das weltweit genutzte geodätische Bezugssystem vieler GNSS-Empfänger, Karten-Apps und Drohnen-Metadaten. Für Navigation, Kartenanzeige und grobe Positionsangaben ist das ideal. Für Vermessung und dauerhafte Projektdaten in Europa ist WGS84 allein aber oft nicht das richtige Zielsystem.

ETRS89 wurde für Europa so definiert, dass es an die stabile Eurasische Platte gebunden ist. Genau das macht ETRS89 für Vermessung, Katasterbezug und technische Planung so wichtig: Koordinaten bleiben im europäischen Rahmen zeitstabil, statt der globalen Plattentektonik zu folgen.

Das österreichische BEV weist darauf hin, dass sich die eurasische Platte durch globale Einflüsse grob um etwa 2,5 cm pro Jahr nach Nordost bewegt. Für langlaufende Bestandsdaten, Referenznetze und konsistente Planungsgrundlagen ist ein plattfestes System daher fachlich sinnvoller als ein rein global-dynamischer Bezug.

Gleichzeitig zeigt die EPSG-Datenbank: Für Anwendungen mit mittlerer oder geringer Genauigkeitsanforderung kann ETRS89 näherungsweise wie WGS84 behandelt werden; die dort ausgewiesene Näherung liegt bei 1 m. Für PV-Planung, Dachvermessung, CAD-Layouts oder BIM-Koordination ist diese Vereinfachung jedoch meist zu grob. Dort sollte das Zielsystem explizit als ETRS89/UTM, LV95 oder projektspezifisches lokales System festgelegt werden.

Deutschland, Österreich, Schweiz: Welche Systeme gelten in der Praxis?

Für DACH-Projekte gibt es keinen einzigen Universalstandard. Entscheidend ist immer das Land, der Projektkontext und oft auch die Vorgabe von Vermesser, Generalplaner oder öffentlicher Stelle. Für Drohnendaten müssen deshalb Zielsystem und Exportformat gemeinsam gedacht werden.

In Deutschland beschreibt das BKG für DE_ETRS89 / UTM die amtlichen UTM-Zonen 31, 32 und 33. Im Alltag von Architektur, PV und Bauplanung begegnen Teams am häufigsten ETRS89 / UTM Zone 32N (EPSG:25832) und Zone 33N (EPSG:25833). Welche Zone gilt, hängt von Lage und Vorgaben des Projekts ab.

In Österreich stellt das BEV ETRS89-Koordinaten bereit und nennt für UTM insbesondere EPSG:25832 und EPSG:25833. Gleichzeitig sind ältere MGI/Gauß-Krüger-Bestände weiterhin verbreitet. Genau hier entstehen oft Transformationsfehler, wenn Drohnendaten unkritisch mit Altbestand verschnitten werden.

In der Schweiz basiert die amtliche Vermessung auf LV95. Swisstopo beschreibt LV95 mit dem bekannten Nullpunkt Bern und den siebenstelligen Ost-/Nordwerten. Seit 2017 ist das erneuerte Bezugssystem offiziell. Für Schweizer Projekte ist LV95 daher regelmäßig das richtige Zielsystem für planbare, landesbezogene Outputs.

Höhenbezug: Ellipsoid, NHN, LN02 und physikalische Höhen sauber trennen

Neben der Lage wird in Projekten sehr häufig der Höhenbezug verwechselt. GNSS misst zunächst ellipsoidische Höhen auf einem mathematischen Referenzellipsoid. Für Bau, Planung und Bestand braucht man aber meist physikalische Höhen, also Höhen über einem national definierten Bezugsniveau.

Für Deutschland beschreibt das BKG den Zusammenhang explizit: Mit dem Quasigeoidmodell GCG2016 lassen sich ellipsoidische Höhen im System ETRS89/GRS80 in nationale Höhen des DHHN2016 umrechnen. Die vom BKG angegebene Beziehung lautet H_DHHN2016 = h_ETRS89 − ζ_GCG2016. Wer diese Unterscheidung ignoriert, produziert formal korrekte, aber praktisch falsche Höhen.

In der Schweiz unterscheidet swisstopo ebenfalls zwischen Lage- und Höhenbezug. Für lokale Referenzrahmen nennt swisstopo LV95 und LHN95; zugleich wird die Transformation von LN02 nach LHN95 und EVRF bereitgestellt. Für Projektteams ist die wichtigste Konsequenz: Nicht nur das Lage-CRS, sondern auch das verlangte Höhenmodell muss dokumentiert werden.

Für Österreich stellt das BEV APOS in ETRS89 bereit und weist zugleich darauf hin, dass Projektionen in ebene Systeme und fachlich belastbare Transformationen anwendungsseitig sauber verarbeitet werden müssen. Gerade bei der Weitergabe von Drohnendaten an CAD und BIM sollten Höhen nie stillschweigend als „Meter“ übernommen werden, ohne den vertikalen Bezug zu benennen.

Welche Systeme für Orthofoto, DXF, LAS und BIM?

Nicht jedes Ausgabeformat transportiert Raumbezug gleich gut. Deshalb sollte das Zielsystem immer zusammen mit dem Endformat definiert werden. Ein GeoTIFF kann ein projektiertes CRS sauber mitführen; bei DXF oder DWG hängt vieles davon ab, wie die Zielsoftware und das Planungsteam die Datei weiterverarbeiten.

Für Solarteure, Architekturbüros und Vermessungspartner lohnt sich eine einfache Denkweise: Rasterdaten brauchen einen klaren geografischen oder projizierten Raumbezug, Vektordaten brauchen metrische Koordinaten im Projektbezug, Punktwolken brauchen nachvollziehbare CRS-Metadaten, und BIM braucht zusätzlich eine abgestimmte Shared-Coordinate-Strategie.

Übergabe-Workflow für saubere Projektdaten

Mit einem sauberen Übergabeprozess lassen sich fast alle typischen Koordinatenprobleme vermeiden. Entscheidend ist, dass das Zielsystem nicht erst beim Export, sondern schon vor der Verarbeitung feststeht.

1. 01

   Zielsystem vor der Verarbeitung festlegen

   Vor dem Processing klären, welches Lage- und Höhensystem das Folgegewerk tatsächlich benötigt: ETRS89/UTM, LV95, lokales Bauachsen-System oder BIM-Shared Coordinates.

2. 02

   RTK, PPK oder GCP nicht mit dem Ziel-CRS verwechseln

   RTK, PPK und GCP verbessern die Georeferenzierung, definieren aber nicht automatisch das endgültige Ausgabesystem. Genauigkeit und Koordinatenbezug sind zwei getrennte Themen.

3. 03

   Altbestand aktiv prüfen

   Liegt ein DWG-Bestand noch in MGI, LV03 oder einem lokalen Ingenieur-Nullpunkt vor, muss vor der Verschneidung entschieden werden, ob transformiert oder im Bestandssystem gearbeitet wird.

4. 04

   Vertikalbezug separat dokumentieren

   Bei 3D-Daten immer festhalten, ob Z-Werte ellipsoidisch, NHN-, LN02-, LHN95- oder projektspezifisch geführt werden. Ohne diese Information sind Höhen fachlich riskant.

5. 05

   Export und Metadaten gemeinsam liefern

   Zum eigentlichen Output gehören Dateiformat, CRS-Bezeichnung, EPSG-Code oder nationale Systembezeichnung, Höhensystem, Einheit und gegebenenfalls Transformationshinweis.

6. 06

   Importtest in der Zielsoftware machen

   Vor Projektabschluss mindestens einen echten Import in AutoCAD, Revit, GIS oder PV-Software prüfen. Sichtbarer Versatz, verdrehte Achsen oder falsche Höhen fallen dort am schnellsten auf.

Die häufigsten Fehler in der Praxis

Fehler Nummer eins ist die stillschweigende Annahme, WGS84 sei für jede technische Übergabe ausreichend. Für Kartenansichten stimmt das oft, für vermessungsnahe Planung jedoch nicht.

Fehler Nummer zwei ist die Vermischung von Lage- und Höhenbezug. Ein Projekt kann in der Lage korrekt in ETRS89 / UTM liegen und gleichzeitig falsche Z-Werte haben, weil ellipsoidische und physikalische Höhen nicht getrennt wurden.

Fehler Nummer drei betrifft Altbestände: CAD-Dateien, Vermessungspläne oder IFC-Modelle liegen oft in älteren oder lokalen Systemen. Wer Drohnendaten dagegen ohne Transformationsstrategie legt, erzeugt scheinbar kleine, aber planerisch kritische Abweichungen.

Fehler Nummer vier ist fehlende Dokumentation. Ein sauberer Export braucht nicht nur den Dateinamen, sondern auch Angaben wie „ETRS89 / UTM Zone 32N“, „LV95“, „NHN“ oder „ellipsoidische Höhe“. Ohne diese Metadaten beginnt beim Empfänger das Rätselraten.