National Transformation version 2 in Proj4JS
Im Rahmen einer studentischen Arbeit habe ich mich mit Koordinatentransformationen über den NTv2-Standard in Proj4JS beschäftigt. Die dabei gewonnenen Erkenntnisse möchte ich hier kurz vorstellen.
Hintergründe
Die folgende Abbildung soll das Problem verdeutlichen:
Dargestellt sind drei markierte Positionen, die alle durch die gleichen Koordinaten (51°03′46,39″N, 13°44′46,23″O) beschrieben werden. Die Labels geben die verwendeten Koordinatensysteme an. Es lässt sich erkennen, dass die gleichen Koordinaten in unterschiedlichen Koordinatensystemen auch unterschiedliche Positionen beschreiben. Dies lässt sich durch die Verwendung unterschiedlicher Erdmodelle zur Definition von Positionen erklären.
Prinzipiell kann jeder Ort auf der Erdoberfläche durch zwei Winkel beschrieben werden:
Lambda und Phi bzw. Längen- und Breitengrad beschreiben dabei einen Punkt basierend auf Erdmittelpunkt, Äquator und Nullmeridian.
Allerdings ist die Erde, anders als hierfür angenommen, keine perfekte Ellipse, weshalb weitere Parameter für die Dimensionen und Lagerung der Ellipse innerhalb des Erdkörpers angegeben werden, um diese gewissermaßen an die Erdoberfläche bzw. an ein Interessengebiet optimal anzunähern. Hierbei treten Genauigkeitsverluste auf.
Um trotzdem mit diesen Koordinaten rechnen zu können (z.B. Distanzen bestimmen), ist es erforderlich, alle verwendeten Koordinaten in das gleiche Koordinatensystem zu überführen bzw. zu transformieren.
Für diesen Vorgang gibt es zwei Möglichkeiten:
- Ellipsenbasiert über 7-Parameter-Transformation
- Gitterbasiert über NTv2
Bei der 7-Parameter-Transformation wird durch sieben Parameter eine Verschiebung, Drehung und Skalierung der Ellipse definiert, um diese an das Zielsystem anzulehnen.
Im Gegensatz dazu verwendet man bei NTv2 eine Gitterstruktur mit sogenannten Verschiebewerten von einem System in ein anderes, welche in regelmäßigen Abständen über den Geltungsbereich des Gitters verteilt sind. Die benötigten Verschiebewerte für eine beliebige Koordinate werden durch bilineare Interpolation aus den Werten der vier Eckpunkte der die Ausgangskoordinaten umschließenden Gittermasche errechnet. Die eigentliche Transformation erfolgt dann durch einfaches Addieren der Verschiebewerte, vorliegend in Gradsekunden (1/3600tel Grad).
Eine Besonderheit von NTv2 ist, dass alle Gitterzellen voneinander unabhängig sind: Während bei der 7-Parameter-Transformation eine Ellipse immer als Ganzes betrachtet wird, können bei NTv2 einzelne Verschiebewerte, und damit einzelne Teilgebiete des Gitters, unterschiedlich transformiert werden. Es können demnach mehrere Teiltransformationen, z.B. zum Erhalt einer höheren Genauigkeit durch präzisere Annäherung bei kleineren Interessengebieten, kombiniert werden.
So wird u.a. bei dem deutschen BeTA2007 Gitter vorgegangen.
BeTA2007 ist ein NTv2-Gitter, herausgegeben von der Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder (AdV), zur Transformation von ATKIS (topographische Daten). Es wird für die Umstellung vom deutschen DHDN auf das europäische ETRS89 verwendet und vereint hochgenaue Transformationsansätze einzelner Bundesländer in einem deutschlandweit anwendbaren Verfahren.
BeTA2007 wurde im Rahmen der Arbeit als Beispiel gewählt, anhand dessen Erfahrungen mit NTv2 gesammelt werden sollten. Hierbei ging es konkret um den Einsatz von NTv2 im mobilen Bereich mit Proj4JS sowie um die Frage, ob und wie ein Genauigkeitsgewinn bei Transformationen vorliegt.
Untersuchung BeTA2007
In einem ersten Schritt sollte eine korrekte Ausgangslage für den weiteren Verlauf erarbeitet werden:
Die Darstellung auf der linken Seite wurde einer Präsentation über BeTA2007 aus dem Jahr 2007 entnommen. Sie zeigt eine Differenz zwischen einer nicht näher spezifizierten 7-Parameter-Transformation und der Transformation über BeTA2007. Die Heatmap auf der rechten Seite wurde von mir mit Proj4 (cs2cs) erstellt, wobei jede der 5208 Gitterzellen von BeTa2007 durch 100 Unterpunkte verfeinert wurde. Trotz unterschiedlicher Farbeinteilungen kann hierdurch die korrekte Funktionsweise der Einbindung von BeTA2007 in die verwendete Software, sowie der Einsatz von EPSG:31467 als 7-Parameter-Transformation zur Berechnung der Differenz, visuell bestätigt werden.
Nachfolgend wurde eine weitere Heatmap errechnet, die jeden Differenzwert in Relation zu allen anderen Werten innerhalb der gleichen Zelle anzeigt. Die Min/Max-Werte, die bei einer Heatmap über die Verteilung der Farben entscheiden, werden also nicht wie zuvor über den gesamten Geltungsbereich gesetzt. Stattdessen wird jede Zelle einzeln betrachtet. Ursprünglich ging es hierbei um die Frage, ob ein Einfluss der Erdkrümmung auf die bilineare Interpolation gezeigt werden kann. Während bei der 7-Parameter-Transformation eine Ellipse mit entsprechender Krümmung verwendet wird, wird bei BeTA2007 innerhalb einer Zelle auf einer Ebene interpoliert. Entsprechend ist eine stärkere Abweichung bei größerer Zellengröße in Richtung der Zellenmitte zu erwarten. Dies konnte so jedoch nicht gezeigt werden. Folglich war kein Einfluss der Erdkrümmung in diesem Zusammenhang festzustellen, weswegen diese anfängliche Frage nicht weiter untersucht wurde.
Hier zu erkennen sind vor allem die grob eingezeichneten Gebiete einzelner Bundesländer. Man sieht, dass die einzelnen hochgenauen Transformationsansätze der Länder innerhalb von BeTA2007 unterschiedlich transformieren und sich somit die Farbverläufe in einzelnen Zellen in unterschiedliche Richtungen ausbreiten. Weiterhin erkennt man im oberen rechten Bereich ein besonderes Muster. Auf Nachfrage wurde mir bestätigt, dass es sich hierbei um den Transformationsansatz Brandenburgs handelt, das schon vor BeTA2007 auf eine gitterbasierte Transformation umgestiegen war.
BeTA2007 mit Proj4JS
Proj4JS wird bei uns in der mobilen App GIS2go für Koordinatentransformationen eingesetzt. Offiziell gibt es hierfür, im Gegensatz zum normalen Proj4, keine NTv2 Unterstützung. Für eine französische Transformation findet sich eine modifizierte Proj4JS Version. Ich habe daher eine BeTA2007-Javascript Variante in Anlehnung an das französische JS-Gitter generiert, um anschließend hiermit die korrekte Funktionsweise der modifizierten Proj4JS Version testen zu können. Das Generieren selber hat sich als recht zeitaufwändig herausgestellt, da an mehreren Stellen unerwartete Fehler in der verwendeten Software aufgetreten sind:
- Proj4JS, auch die nicht-modifizierte Version, verwendet eine veraltete hardcodierte Definition des Potsdam-Datums. Dies wurde bereits vor mehreren Jahren in Proj4 geändert, weshalb die Ergebnisse bei der Berechnung der Differenzen nicht identisch waren
- Das französische Gitter liegt nur in binärer Form vor. Um Nachvollziehen zu können, in welcher Struktur das Gitter für die JS-Version vorliegen muss, habe ich es mit ntv2-file-routines in ASCII umgewandelt. Hierbei wurden scheinbar wahllos einzelne Zahlen weggeschnitten. Da BeTA2007 direkt in ASCII veröffentlicht wird, konnte auch ohne Umwandlung gearbeitet werden
Das Ergebnis ist eine Javascript-fähige BeTA2007 Variante, die sowohl rechnerisch als auch visuell validiert wurde. Das Ergebnis war nahezu genaue Übereinstimmung mit kleineren Unterschieden, die wohl durch die Verwendung von Javascript entstanden sind.
Genauigkeitsgewinn mit NTv2
Viele in GIS2go verwendete Karten liegen in Gauss-Krüger 3 vor. Bei der Anzeige der aktuellen Position wird das GPS-Signal, vorliegend in WGS84, durch EPSG:31467 nach DHDN/GK3 transformiert. BeTA2007 bietet eine elegante Möglichkeit eine deutschlandweit gültige Transformation bereitzustellen, bei der trotzdem der Vorteil hochgenauer Transformationsansätze einzelner Länder bestehen bleibt.
Um hierbei einen möglichen Genauigkeitsgewinn zu zeigen sind feste Referenzpunkte notwendig. Bayern stellt als einziges Bundesland solche Punkte sowohl in DHDN als auch ETRS89 öffentlich zur Verfügung. Die Ergebnisse am Beispiel der drei Punkte Lindau, Dreifrankenstein und Dachau:
Es lässt sich erkennen, dass die Transformation über BeTA2007 deutlich genauer ist und eine Verbesserung von bis zu 1.6m erreicht wird. Dieser Genauigkeitsgewinn ist nicht gleich der Differenz zwischen beiden Transformationen, da sich gewissermaßen die “Richtung” der Transformation unterscheiden kann. Die Differenz ist allerdings gleich dem Wert an den entsprechenden Koordinaten in der ersten erstellten Heatmap, weshalb auch hier eine korrekte Funktionsweise bestätigt werden kann.
Teilen via
