Geodaten in der 4. Dimension?

Derzeit können wir im Bereich der Geoinformationssysteme ein verstärktes Interesse an der dritten Dimension wahrnehmen. Es werden per Laserscanner ganze Innenstädte digitalisiert, die dann häufig als City-GML Daten in 3D Systemen visualisiert oder für das Internet aufbereitet werden. Sinnvolle und wichtige Anwendungsgebiete gibt es durchaus dafür. Die Hochwasservorhersage oder die Bestimmung von nutzbaren Flächen für Solaranlagen wären dafür gute Beispiele.

Der Weg in eine mögliche vierte Dimension ist ein ganz Anderer. Von möglicher Dimension reden wir, da wir nicht die räumliche Dimension meinen. Die drei uns Bekannten nutzen wir, wie oben erwähnt, bereits schon. Auch wenn mancher Physiker uns von einem n-Dimensionalen Universum überzeugen möchte, geht es hier um ein ganz anderes praktisches Problem und deren Lösung.

Die Nutzer arbeiten häufig mit großen Geodatenbeständen. Diese erfahren in der Regel nur geringe Veränderungen in festgelegten Intervallen. Aus der täglichen Praxis heraus hat uns eine Problemstellung zur hier gezeigten Lösung bewogen. Die Städte und Gemeinden erhalten Geodaten von den Landesvermessungsämtern im Rahmen der Verfahren ALK oder ALKIS. Üblich sind dabei Datenlieferungen im Quartalsrhythmus. Oft wird nur ein Gesamtdatenbestand geliefert. Dieser wird dann über Schnittstellen komplett in die bestehenden Systeme übernommen. Der alte Datenbestand wird überschrieben. Eine Historie entstand dadurch nicht.

In der Praxis gibt es aber die Anforderung, dass man mehrere unterschiedliche Versionen vergleichen kann. Die Veränderungen sollten visualisiert werden können. Etwas überzogen dargestellt, wird von der Zeit hier als die vierte Dimension gesprochen. Die denkbar ungünstigste Variante ist es, pro Update jeweils eine Ebene mit den kompletten Daten im GIS darzustellen. Damit müsste das GIS mit sehr vielen redundanten Daten arbeiten.

Die Analyse der Daten und deren Veränderungen ergab eine Änderungsrate von ca. einem Prozent pro vierteljährlichem Update. Dabei waren im konkreten Fall ungefähr 22000 Flurstücke im Datenbestand. Um die zeitlichen Veränderungen im Datenbestand abzubilden muss der komplette Datenbestand einmal gespeichert werden. Es werden danach nur noch die Veränderungen datumsbezogen abgelegt. Schon vorhandene, identische Objekte werden nicht noch einmal gespeichert. Auf diese wird lediglich datumsbezogen verwiesen. Ob ein Objekt schon existiert und somit nicht noch einmal gespeichert werden muss, kann anhand verschiedener Merkmale festgelegt werden. Im Normalfall wird die Geometrie des Objektes hierzu herangezogen. Es gibt aber auch Situationen, wo das nicht funktioniert. Bei einem Wechsel des Koordinatensystems, z.B. auf ETRS89 im Rahmen der ALKIS/NAS Umstellung, macht ein Vergleich der Koordinaten keinen Sinn. In solch einem Fall kann man auch eindeutige Identifikationsmerkmale der Objekte nutzen.

Werden die Daten von OpenJUMP abgerufen, gibt es zwei Möglichkeiten. Entweder liefert die Datenbank alle aktuellen Objekte des Zeitpunktes zurück. Oder es werden nur die zu diesem Zeitpunkt geänderten Objekte zurück geliefert. Kombiniert man diese Möglichkeiten geschickt mit der Ebenendarstellung, dann muss das GIS nicht von jedem Zeitpunkt alle Objekte verarbeiten und anzeigen. Das führt zu wesentlich kleineren Datenbeständen und somit zur schnelleren Anzeige der Daten im GIS.

Fazit

• Beim Import von extern gepflegten Datenbeständen sind die Veränderungen meist sehr gering.
• Eine Deduplizierung auf Datenbankebene (PostGIS) reduziert die Datenbestände massiv und führt zu wesentlich schnellerer Verarbeitung und Anzeige auf dem Client.
• Die Datenbank macht die Datenbestände für das GIS automatisch transparent sichtbar.
• Eine Art Zeitreise Modus ist möglich und bietet eine völlig neue Sichtweise auf die Daten.
• Der Aufbau einer Änderungshistorie wird automatisch gewährleistet.

Wenn Sie Interesse oder Fragen zu der aufgezeigten Lösung oder ähnliche Probleme haben, können Sie uns das gern über das Kontaktformular mitteilen.