Welche Aussage steckt tatsächlich in der Exportbezeichnung?
| Angabe im Projekt oder Export | Was daraus folgt |
|---|---|
| Ellipsoidische Höhe, ETRS89/GRS80 | Die Höhe bezieht sich auf das Referenzellipsoid. Für eine DHHN2016-Normalhöhe wird der GCG2016-Modellwert benötigt. |
| Normalhöhe, DHHN2016 | Der gewünschte amtliche Höhenbezug ist bereits vorhanden. Eine weitere Reduktion mit GCG2016 wäre doppelt. |
| Nur „GNSS-Höhe“ oder „Z“ | Die Bezeichnung lässt offen, ob die Gerätesoftware bereits ein Höhenmodell angewendet hat. |
| Nur „NN“ oder „NHN“ | Für einen eindeutigen Vergleich fehlt noch die konkrete Systemangabe aus dem Projekt. |
Den mathematischen Zusammenhang H = h − ζ und ein Zahlenbeispiel erläutert die GCG2016-Anleitung. Entscheidend für eine vorhandene Messdatei ist zunächst, welche dieser Größen ihre Z-Spalte tatsächlich enthält.
Die Höheneinstellung im Messgerät entscheidet
Ein GNSS-Projekt kann ellipsoidische Höhen ausgeben. Hat das Messgerät oder die Bürosoftware bereits ein Quasigeoidmodell angewendet, können im Export aber schon DHHN2016-Normalhöhen stehen. „Mit GNSS gemessen“ reicht deshalb als Beschreibung der Z-Spalte nicht aus.
Prüfen Sie im Projekt, ob ein Höhenmodell aktiv war und welches. Bereits als DHHN2016 ausgegebene Werte werden nicht nochmals mit GCG2016 reduziert. Sonst wird die Höhenanomalie ein zweites Mal abgezogen. Umgekehrt wird eine ellipsoidische Höhe durch die bloße Beschriftung „NHN“ nicht zur Normalhöhe.
Auch die horizontale Bezugsangabe gehört dazu. Der fachlich passende direkte Zusammenhang ist ETRS89/GRS80 ↔ DHHN2016. Eine ungenau bekannte WGS84-Höhe ist nicht allein wegen des ähnlichen Namens ein präziser ETRS89-Höhenwert.
Das Fehlerbild zur passenden Ursache zuordnen
| Beobachtung | Zuerst prüfen |
|---|---|
| Die Höhe unterscheidet sich ungefähr um die örtliche Höhenanomalie. | Wurde GCG2016 noch nicht oder bereits zweimal angewendet? |
| Die Höhenänderung hat das falsche Vorzeichen. | War die Quelle ellipsoidisch oder bereits eine Normalhöhe? h → H zieht die Höhenanomalie ab, H → h addiert sie. |
| Die Höhe bleibt trotz gewünschtem Wechsel unverändert. | Ist eine Z-Spalte zugeordnet und die Höhenoperation eingeschaltet? |
| Für einen Punkt kommt kein gültiger Höhenwert zustande. | Liegen Lage und Höhenwert vollständig vor, und ist die Position vom gültigen GCG2016-Bereich abgedeckt? |
Vergleichen Sie dabei denselben Punkt mit unveränderter Lage. Eine vertauschte Länge/Breite oder ein falsch eingelesener UTM-Wert kann den Modellwert ebenfalls unbrauchbar machen. Wie die einzelnen Höhenmodi im Rechner eingestellt werden, steht im Schritt-für-Schritt-Ablauf.
Lagebezug und Höhenbezug getrennt dokumentieren
Ein korrektes UTM32-Koordinatenpaar beweist noch keinen bestimmten Höhenbezug. Halten Sie für die Übergabe deshalb beides fest: das Koordinatenreferenzsystem der Lage und die Bedeutung der Höhe, einschließlich eines bereits angewendeten Modells.
Bei einem historischen Lagebezug wie GK/DHDN sind in KoordiConvert zwei getrennte Umrechnungen erforderlich: zuerst die Lage ohne Höhenoperation nach ETRS89 umrechnen, danach die ETRS89-Ergebnisdatei als neue Quelle für GCG2016 verwenden. Der Rechner unterstützt den historischen Datumswechsel und die Höhenoperation nicht in einem gemeinsamen Aufruf. Dabei darf die ursprüngliche Z-Spalte nur entsprechend ihrem tatsächlich bekannten Höhenbezug verwendet werden.
Für eine getrennte Kontrolle stehen ETRS89-Eingabepunkte und DHHN2016-Sollhöhen mit dokumentiertem GCG2016-Bezug bereit. Der Begleittext nennt die Einstellungen; die Anwendungsseite führt durch die eigentliche Umrechnung.
Quellen und weiterführende Nachweise
Inhaltlich verantwortlich: KoordiConvert · Stand 03.11.2026 · Redaktion und Prüfmethode