[NAS] 7 magische Zahlen

["Jäger, Frank (KRZ)"]

Hallo Freunde von ALKIS,
 nachdem PostNAS erste Tabellen gefüllt hat und der ALKIS-WMS schöne Bilder zeigt, kommt ein Problem an die Oberfläche, dass ich gerne noch länger verbuddelt lassen würde: der Lagebezugswechsel von Gauss-Krüger zu UTM/ETRS89.

Zusammen mit dem Verfahrenswechsel haben die ALKIS-Weltmeister in Lippe eine "Transformation über 1000 Punkte" im Kreisgebiet durchgeführt. Auf einer Informationsveranstaltung wurde den Kommunen erläutert, dass die dabei aufgetretenen Spannungen i.d.R. im Zentimeter-Bereich lagen, maximal im unteren Dezimeter-Bereich; also innerhalb der Darstellungsgenauigkeit bei den meist verwendeten Maßstäben.

Für unsere Situation war ich daher von einer "weichen Migration" ausgegangen:
Wir betreiben ein kommunales GIS mit UMN und Mapbender, das bisher komplett auf Gauss-Krüger-3-Koordinaten basiert. ALK (zukünftig ALKIS) ist darin ein Datenbestand unter vielen anderen.

Mein /Plan/ sah vor, ALKIS über dem WMS (der UMN benutzt dazu proj) "on the fly" umzuprojezieren solange GK3 das "führende" System bleibt.
Dann sollten nach und nach immer mehr Datenbestände auf UTM umgestellt werden.
Sobald die Mehrheit umgestellt ist, sollte dann ETRS89/UTM das führende System werden und die verbleibenden GK3-Bestände könnten vorübergehend "on the fly" umprojeziert werden.

Dieser Plan ging - offensichtlich irrtümlich - davon aus, dass zwischen den Systemen GK3 (epsg:31467) und UTM32 (epsg:25832) eine feste mathematische Beziehung besteht. Die Parameter für die Umrechnung finden sich in der PostGIS-Tabelle "spatial_ref_sys" oder in der Datei "/usr/share/proj/epsg" (unter Debian-Linux).
Dies wird mit "PostGIS" und "proj" weltweit einheitlich installiert und angewendet.

Die ersten "Bilder" von ALKIS zeigen, dass das ganze Kreisgebiet um 3,40 Meter in Richtung Grönland verrutscht ist. Das sind nicht die erwarteten "Zentimeter", das liegt deutlich über der Schmerzgrenze!

Die Suche nach den Ursachen förderte /7 magische Zahlen/ zutage, die sozusagen als Essenz der "Transformation der 1000 Punkte" heraus gekommen sind. Diese 7 Parameter beschreiben lokale Korrekturwerte (für das Kreisgebiet) für die Beziehung zwischen UTM32 und GK3.
Sie werden eingebaut als Parameter "+towgs84=" in die Zeilen zu den epsg-Codes in spatial_ref_sys oder der Datei proj/epsg.

Die Korrekturwerte für epsg:25832 (UTM) sind dabei "7 mal 0.0", aber nicht 0 für epsg:31467.
ALKIS zeigt hier die Mentalität eines Geisterfahrers: "ALLE Koordinaten sind falsch, nur meine nicht!".
Wahrscheinlich stimmt das sogar, denn es ist ja Aufwand in diese Korrektur geflossen. Alle kommunalen Datenbestände müssen das mittelfristig nachvollziehen.

Unter Anwendung dieser lokalen Korrektur-Parameter sind das alte ALK und das neue ALKIS im Mapbender nun wieder deckungsgleich.
Wir könnten das in die zentrale Datei /proj/epsg unseres Mapservers einbauen und somit alle GK-basierten WMS unseres Servers auf einen Schlag korrigieren. Alle "eigenen" Dienste - egal ob UTM- oder GK-basiert - würden dann hervorragend zueinander passen.
Leider scheint die Information, dass wir jetzt alle 3,40 Meter an Grönland ranrutschen noch nicht beim Land angekommen zu sein. Die WMS, die von Servern des Landes eingebunden sind, passen dann weder zu ALKIS/UTM noch zu unseren korrigierten GK3-Diensten.

Diese Lösung ist also für die tägliche Praxis unbrauchbar.
Es nutzt dem Geisterfahrer nichts, wenn er Recht hat und die anderen falsch fahren. Es wird zum Crash kommen.
Bis auch das Land "korrigierte" Koordinaten verwendet, sehe ich die Lösung darin, die ALKIS-Daten während der PostNAS-Konvertierung wieder auf die "unverbesserten" GK-Werte zurückzuverschlimmbessern.

Unsere kommunale (+NRW) Mapserver-Welt bleibt dann allerdings "unkompatibel" zu den Diensten der Kreisverwaltung, von denen ich annehme, dass sie ab sofort "korrigierte" Koordinaten verwenden.

Das ganze widerspricht meinen bisherigen positiven Erfahrungen mit WMS-Diensten. Bisher brauchte man sich keine Gedanken darüber machen, worauf ein Dienst intern basiert.
Über GetMap mit gleichen epsg-Codes passte bisher alles auf wunderbare Weise zusammen. Seit das Katasteramt vom Apfel der Transformations-Erkenntnis gegessen hat, hat es erkannt, dass wir alle immer schon falsche Koordinaten gehabt haben.
Dadurch sind wir nun aus dem OGC-Paradies verbannt. 

Vielleicht ist meine Analyse der Situation noch falsch. Aber ich ahne, dass mit dem Lagebezugswechsel noch so Einiges auf uns zukommt.


Mit freundlichen Grüßen
Frank Jäger

Kommunales Rechenzentrum
Minden-Ravensberg/Lippe