Das richtige Bezugssystem für Ihre Punktliste

1. Geodätischer Bezug: DHDN, RD/83, PD/83, ETRS89, WGS84 oder MGI? Die Bezeichnung „Gauß-Krüger“ allein beantwortet das nicht.
2. Projektion und Zone: beispielsweise GK4 oder UTM32. Eine Zone beschreibt einen Mittelmeridian; ein Land oder eine Dateiendung bestimmt die Zone nicht zuverlässig.
3. Zahlenkonvention: Welche Spalte enthält den Ost-/Rechtswert? Ist die UTM-Zonenkennziffer bereits im Ostwert enthalten? Stehen die Werte in Metern oder Dezimalgrad?
4. Höhenbezug: Ist z eine ellipsoidische Höhe, eine Normalhöhe im DHHN2016 oder eine lokale Projekthöhe? Ohne bekannte Höhenart darf z nicht automatisch mit GCG2016 korrigiert werden.

Steht im Begleitblatt nur „GK, Deutschland“, fehlt mindestens das Datum. Fragen Sie den Datenlieferanten nach dem vollständigen CRS beziehungsweise EPSG-Code und einem bekannten Kontrollpunkt. Eine Karte hilft bei der Plausibilitätsprüfung, ersetzt diese Angaben aber nicht.

GK4 ist nicht eindeutig: DHDN/GK4 trägt EPSG:31468, sächsisches RD/83/GK4 EPSG:3398 und thüringisches PD/83/GK4 EPSG:3397. Ihre Koordinaten können ähnlich aussehen. KoordiConvert führt sie als getrennte Eingaben und verbindet RD/83 mit NTv2_SN sowie PD/83 mit NTv2gridTH. Die geodätische Zuordnung muss aus dem Projekt bekannt sein.

Die Produktkonvention ist stets x = Rechtswert und y = Hochwert. Bei einzelnen formalen EPSG-Definitionen, insbesondere den hier genannten älteren GK-CRS, ist die definierte Achsenfolge Hochwert/Rechtswert. Wer aus einer anderen Software exportiert, muss deshalb die tatsächliche Spaltenfolge prüfen. GeoSN dokumentiert diese Unterschiede ausdrücklich.

Bei UTM32 ohne Zonenkennziffer kann der Ostwert beispielsweise 693397,328 m lauten. In der Variante mit Zonenkennziffer wird daraus 32693397,328 m; der Nordwert bleibt gleich. Das ist eine Änderung der Koordinatendarstellung innerhalb derselben Zone. Eine andere UTM-Zone verändert dagegen die Projektion und beide Zahlen können sich ändern.

UTM34 mit Zonenkennziffer besitzt in KoordiConvert keinen EPSG-Code. Die eigene Kennung lautet KOORDICONVERT:UTM34_ZE_N: GRS80, Mittelmeridian 21°, Maßstab 0,9996, falscher Ostwert 34500000 m, falscher Nordwert 0 m. Diese Kennung darf nicht als EPSG:25834 ausgegeben werden; EPSG:25834 ist die Variante ohne vorangestellte 34.

Die Auswahl einer angebotenen Zone ist keine Aussage, dass diese Zone für jede Position fachlich sinnvoll ist. Folgen Sie dem vereinbarten Ziel-CRS Ihres Projekts. Der kontrollierte Präfixtest zeigt den Unterschied an einem konkreten Punkt.

In KoordiConvert bedeutet bei geografischen Eingaben x = Länge und y = Breite, jeweils in Dezimalgrad. Ein Punkt im Raum München kann daher x ≈ 11,58 und y ≈ 48,12 haben. Grad-Minuten-Sekunden müssen zunächst in Dezimalgrad umgerechnet werden. Die formale Achsenfolge einer EPSG-Definition und eine Softwarekonvention wie x/y sind unterschiedliche Ebenen.

WGS84 und ETRS89 werden hier ohne Realisierung und Koordinatenepoche angenähert. Bei einem Wechsel zwischen diesen Rahmen meldet die Anwendung diese Einschränkung. Sie rechnet keine zeitabhängige Plattenbewegung oder Deformation. Für eine vermessungstechnische Gleichsetzung eines aktuellen GNSS-Ergebnisses mit einer bestimmten ETRS89-Realisierung reichen die allgemeinen Bezeichnungen EPSG:4326 und EPSG:4258 allein nicht aus.

Web Mercator (EPSG:3857) ist für die Darstellung von Webkarten vorgesehen. Seine Meterkoordinaten sind keine geeignete Grundlage für ungeprüfte Geländestrecken oder Katastergenauigkeit.

Die Bezeichnungen M28, M31 und M34 allein reichen auch hier nicht: Austria GK und BMN verwenden unterschiedliche Koordinatenoffsets. Historische Ferro-Varianten beziehen die Länge auf einen anderen Nullmeridian. Verwenden Sie die zum Datensatz dokumentierte Kennung.

KoordiConvert verwendet für MGI-Übergänge einen Helmert-Ansatz; ein österreichisches hochauflösendes NTv2-Modell ist nicht eingebunden. Diese Unterstützung wird deshalb nicht als hochgenaue österreichische Katastertransformation angeboten. Die EPSG-Übersicht des BEV hilft bei der Identifikation der tatsächlichen Eingabeform.

Ein zweidimensionaler EPSG-Code beschreibt keine beliebige z-Spalte mit. Für ellipsoidische ETRS89-Höhen h und Normalhöhen H im DHHN2016 (vertikales CRS EPSG:7837) verwendet die Höhenfunktion GCG2016 mit H = h − ζ. In Gegenrichtung gilt h = H + ζ. Eine reine Lageumrechnung lässt z unverändert; sie macht aus einer lokalen Höhe keine NHN-Höhe.

Prüfen Sie vor einem großen Import einen Punkt mit unabhängig bekanntem Sollwert: richtige Region, richtige Achsen, vollständige Präfixe, passendes Modell und passende Höhenart. Bewahren Sie Quell-CRS, Ziel-CRS, Modellname, Laufzeitstand und Einheit gemeinsam mit dem Ergebnis auf. Die offenen Referenzbeispiele dienen zum Prüfen der Rechenkette; Ihre projektspezifischen Kontrollpunkte prüfen zusätzlich den tatsächlichen Datenbezug.