Hauptinhalt

Häufig gestellte Fragen (FAQ)

Bei der Benutzung von NTv2_SN in QGIS, bei dem zur Bezugssystemtransformation die proj.4-Bibliothek verwendet wird, ist das Problem, das in der Antwort auf die Frage zu verwendbarer Software für NTv2 beschrieben ist, ebenfalls festzustellen. Um dieses zu umgehen, kann man anstelle der NTv2_SN-Gitterdatei  (die ja mehrere Subgitter in einer Datei enthält) die Subgitter einzeln in die Anwendung einbinden und als Kaskade aufrufen. Sie können die dazu benötigten einzelnen Subgitter von NTv2_SN hier herunterladen und müssen sie entpackt in das dafür vorgesehene Datenverzeichnis der Anwendung für Transformationsgitterdateien kopieren (bei QGIS normalerweise nach ...\share\proj) . Der proj.4-Parameter, der die Gitterdateien kaskadiert aufruft, lautet:
+nadgrids=@suedwest.gsb,@nordwest.gsb,@ost.gsb,
@Elterngitter.gsb.

Hält man in der Befehlszeile die gegebene Reihenfolge der Einzelgitter ein, "fällt" ein zu transformierender Punkt, der aufgrund des o.g. Fehlers nicht korrekt seinem Subgitter zugeordnet werden kann, entweder ins hoch aufgelöste Nachbargitter, was sich in der Genauigkeit nicht merklich auswirkt, oder ins Elterngitter, das innerhalb von Sachsen eine Genauigkeit von etwa 5 cm gewährt.

Beispiel:

Für eine komplette benutzerspezifische Konfiguration für DE_RD-83_3GK5 (entspricht EPSG::3399):
+proj=tmerc +lat_0=0 +lon_0=15 +k=1 +x_0=5500000 +y_0=0 +ellps=bessel +nadgrids=@suedwest.gsb,
@nordwest.gsb,@ost.gsb,@Elterngitter.gsb +units=m +no_defs

Das Koordinatenreferenzsystem ETRS89_UTM33 - in der Form, wie es von den Vermessungsverwaltungen der Länder der Bundesrepublik Deutschland eingeführt wird - entspricht dem EPSG-Code 25833.
Gibt man auf der Webseite EPSG Geodetic Parameter Dataset unter 'Name' den Suchbegriff "ETRS89 / UTM zone 33N" ein und wählt unter 'Type' "Projected CRS" aus, werden auch alle weiteren in der EPSG-Datenbank aufgeführten, in Verbindung mit ETRS89 und UTM33 stehenden Koordinatenreferenzsysteme angezeigt. Momentan sind dies insgesamt vier Einträge, die sich voneinander in der Reihenfolge der Koordinaten und in der Speicherung der Zonenkennziffer unterscheiden.

Es gibt freie NTv2-Software sowohl für die Überführung von Einzelpunkten und Punktlisten als auch freie GIS-Systeme, die diesen Transformationsansatz unterstützen. Weitere Informationen und ein Konfigurationsbeispiel finden Sie hier:

Verwendung von NTv2-Gitterdateien mit freier Software [Download, NTv2-mfS_1411.pdf, 100 kByte]

Alle NTv2-Gitterdateien, und damit auch die NTv2_SN-Gitterdatei beinhalten im Header u.a. Informationen zum Gebiet, für die sie definiert sind. Außerhalb dieses Definitionsbereiches ist die Methode in Verbindung mit der konkreten Gitterdatei nicht anwendbar.

Erfahrungen haben gezeigt, dass Softwareprodukte, die den NTv2-Ansatz verwenden, leider nicht immer auf die Angaben im Header der Gitterdatei zugreifen. Für außerhalb der Definitionsgebiete liegende Punkte sind außerdem oftmals keine geregelten Abläufe wie z.B. Fehlermeldungen oder die automatische Anwendung alternativer globaler Ansätze realisiert, so dass dort tatsächlich unplausible Ergebnisse entstehen können. Als Nutzer ist man daher gut beraten, die eigene Software diesbezüglich vorab zu testen und ggf. beim Hersteller nachzufragen, wie die Software im beschriebenen Fall reagiert. Ist die Reaktion nicht bekannt oder nicht erwünscht, muss sichergestellt werden, dass sämtliche zu transformierenden Daten innerhalb des Definitionsgebietes liegen.

In der Header-Datei (*.gsa) sind alle Gradangaben in Sekunden und die Längenangaben darüber hinaus negativ notiert. Man kann das Definitionsgebiet im Startbezugssystem dort wie folgt "entschlüsseln":
Werte aus S_LAT bzw. N_LAT / 3600 ergeben die minimale und maximale Breitenbegrenzung in Dezimalgrad.
Werte aus W_LON bzw. E_LON / -3600 ergeben die minimale und maximale Längenbegrenzung in Dezimalgrad.

Die heutigen Methoden für den Austausch von digitalen Daten mit Raumbezug erfordern zwingend die Angabe des Koordinatenreferenzsystems (CRS) als Metadatum der Koordinaten. Deshalb ist es nunmehr üblich, bei ebenen Koordinaten die betreffende Abbildungszone nicht mehr in den Rechts- bzw. Ostwerten, sondern im Koordinatenreferenzsystemnamen zu verschlüsseln. Dazu wird die Zonenkennziffer dem Koordinatensystemkürzel angefügt, z.B. 3GK4, UTM33. In diesem Fall wäre die zusätzliche Erweiterung der Ost- bzw. Rechtswerte redundant und wird deshalb vermieden.

Laut Vorgabe der AdV für die amtlichen digitalen Geobasisdaten im AAA-Modell dürfen Rechts- bzw. Ostwerte in zonen- bzw. streifenbezogenen Koordinatenreferenzsystemen prinzipiell keine Zonenkennung mehr enthalten und sind daher bei 3GK und UTM stets 6-stellig. Digitale AAA-Daten des GeoSN genügen dieser Vorgabe.

Beispiele:
Bei der CRS-Angabe ETRS89_UTM33, ist der Ostwert 6-stellig und beinhaltet keine Zonenkennziffer.
Bei der CRS-Angabe DE_RD-83_3GK4, ist der Rechtswert 6-stellig und beinhaltet keine Streifenkennziffer.

Beispiel zur Koordinatenangabe innerhalb der Normbasierten Austauschschnittstelle (NAS):
<gml:Point srsName=" urn:adv:crs: ETRS89_UTM32">
<gml:coordinates>369949.671 5615301.383</gml:coordinates>
</gml:Point>

Lediglich für nicht maschinell auszuwertende AAA-Präsentationsausgaben, z.B. Drucklisten, kann laut AdV zur Verbesserung der Interpretierbarkeit zusätzlich zur Streifen- bzw. Zonennummer im CRS-Kürzel die vollständige Zonenkennung den Rechts- bzw. Ostwerten vorangestellt werden.

Beinhalten Koordinatenreferenzsystemangaben keine Streifen- bzw. Zonenkennung, kann man erwarten, dass diese in den Rechts- bzw. Ostwerten vollständig enthalten sind und die Koordinaten automatisch in der lagerichtigen Zone berechnet wurden. Im AAA-Modell sind solche nicht explizit zonenbezogenen Koordinatenreferenzsysteme nicht vorgesehen.

ETRS89/UTM – Der Bezugssystemwechsel und die Auswirkungen auf die Geodatennutzung

Fachaufsatz auf der Webseite der der Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder der Bundesrepublik Deutschland (AdV)

Zum Fachartikel

zurück zum Seitenanfang