1. Navigation
  2. Inhalt
  3. Herausgeber
Inhalt

Häufig gestellte Fragen (FAQ)

Was sollte ich beim Transformieren meiner Geofachdaten mit NTv2_SN beachten, wenn ich höchste Anforderungen in Bezug auf die Passgenauigkeit zu den Geobasisdaten habe?

Eine Antwort finden Sie hier:

Gibt es eine Übersicht der für die Verarbeitung sächsischer Daten gebräuchlichen EPSG-Codes in GIS?

Eine tabellarische Übersicht finden Sie hier:

Ich möchte NTv2_SN mit QGIS nutzen. Hier wirkt jedoch der proj.4-Fehler Nr. 209 und erzeugt mitunter unzuverlässige Ergebnisse am Rand der Subgitter. Gibt es für dieses bekannte Problem eine Umgehung?

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

Welchen EPSG-Code hat ETRS89_UTM33?

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 http://www.epsg-registry.org/ 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.

Welche open source Software unterstützt die Transformation mit dem NTv2-Transformationsansatz? Können Sie uns ein Beispiel nennen und vielleicht sogar Anwendungstips geben?

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:

Warum bekomme ich bei der Anwendung von Transformationsgitterdateien außerhalb Sachsens unplausible Ergebnisse?

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.

Wo wird bei UTM-Koordinaten die Zonenkennung gespeichert?

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 (GeoInfoDok, Kapitel 11) dürfen Rechts- bzw. Ostwerte in zonen- bzw. streifenbezogenen Koordinatenreferenzsystemen prinzipiell keine Zonenkennung mehr enthalten und sind daher bei 3GK<sn> und UTM<zn> stets 6-stellig. Digitale AAA-Daten des GeoSN werden künftig dieser Vorgabe genügen.

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 derzeit (noch) nicht vorgesehen.

Beispiel:
Bei der CRS-Angabe ETRS89_UTM, ist der Ostwert 8-stellig und beginnt mit der zweistelligen Zonenkennziffer.
Bei der CRS-Angabe DE_RD-83_3GK, ist der Rechtswert 7-stellig und beginnt mit der einstelligen Streifenkennziffer.

 
Welche Auswirkungen hat der Bezugssystemwechsel auf die Geodatennutzung in Deutschland?

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)

© 2010 GeoSN
Zuletzt geändert am: 12.11.2014

 
 
 
 
 
 
 
 

Marginalspalte

Link zum Verwaltungsauftritt des Staatsbetriebes Geobasisinformation und Vermessung Sachsen (GeoSN)
 

Kontakt

  • PostanschriftStaatsbetrieb Geobasisinformation und Vermessung Sachsen
    Referat
    Geodätischer Raumbezug
    Postfach 10 02 44
    01072 Dresden