Geodaten- und GIS-Plattform in der Cloud

Das Datenmodell umfasst zahlreiche Layertypen: Anlagenstandorte, Abstandsflächen, Planungsrecht, Richtfunkstrecken, Kabeltrassen, Kranstellflächen, Fundamente, Zuwegungen, Netzverknüpfungspunkte, Batteriespeicher. Jeder Typ hat eine eigene Tabelle in PostGIS und ein festes Schema aus Pflicht- und optionalen Feldern. Entstanden ist das Modell entlang der Fragen, die im Projekt aus ganz verschiedenen Fachbereichen kommen. Es deckt beide Seiten des Hybridparks ab: Batteriespeicher haben einen eigenen Layertyp und sind kein Anhängsel der Windplanung.

Ein Beispiel: Der Typ für Anlagenstandorte verlangt Anlagennummer, Anlagentyp und Nabenhöhe. Damit steht die Nabenhöhe in jedem Projekt an derselben Stelle. Für eine Auswertung über alle Projekte hinweg genügt dann eine Abfrage, wo vorher eine Rundmail nötig war.

Das von uns entwickelte QGIS-Plugin packt Projekt und GeoPackage als Archiv nach S3 und meldet den Import an. Der Auftrag geht in eine FIFO-Warteschlange, mit einer Reihenfolge je Projekt. Eine Lambda-Funktion nimmt ihn auf und liest den Upload. Sie schreibt den Projektstand ins Archiv, prüft die Layer gegen das Datenmodell und schreibt sie nach PostGIS. Zum Schluss legt sie für jeden Layer den passenden Featuretype im Geoserver an.

An der Reihenfolge je Projekt scheitern viele Sync-Systeme. Hier können sich zwei Push-Vorgänge am selben Projekt nicht überholen und damit auch nicht gegenseitig überschreiben. Was trotzdem fehlschlägt, landet in einer Dead-Letter-Queue und ist dort einsehbar.

Layer im Datenmodell lädt niemand herunter. Der Geoserver liest die Tabellen direkt und veröffentlicht sie über WFS. QGIS und die Geo-Karte in der Web-App zeigen deshalb denselben Stand, und zwar in dem Moment, in dem er sich ändert. Ein Pull in QGIS passt für diese Layer nur die Quelle an, Daten fließen dabei keine.

Für alles andere gibt es den Delta-Mechanismus. Das Plugin fragt den Serverstand im Minutentakt ab und vergleicht ihn mit dem geöffneten Projekt: neu, geändert, umbenannt, entfernt. Diese Prüfung schreibt nichts, sie zeigt nur an. Erst der Delta-Pull baut ein Archiv aus genau den geänderten Vektor- und Rasterlayern und wendet es auf das offene Projekt an. Übertragen wird damit nur die Änderung und nie das ganze Projekt.

Das System historisiert jede Änderung an einem Layer im Datenmodell, mit Zeitpunkt und Urheber. Die Web-App zeigt, wer wann was zuletzt geändert hat. Gelöschte Layer lassen sich aus der Historie zurückholen.

Wer in QGIS löscht, entfernt Daten, Metadaten und den veröffentlichten Geoserver-Layer gemeinsam. Es bleiben keine Leichen zurück, die in der Karte noch auftauchen.

Auf demselben Datenmodell setzen die digitalisierte Flächenanalyse und die Vertragsgenerierung auf. Dazu gibt es einen eigenen Showcase.

Wir sind nicht mit einem fertigen Datenmodell angetreten. Am Anfang stand eine Pilotphase mit Key-Userinnen aus dem Planungsteam. Mit ihnen haben wir die Migration an echten Projekten erprobt und in denselben Sitzungen das Datenmodell erarbeitet. Welche Felder Pflicht sind, hing davon ab, welche Fragen im Projekt tatsächlich beantwortet werden müssen.

Erst nach Abschluss der Pilotierung sind wir in den Rollout gegangen. Das kostet Zeit, in der außerhalb des Pilotkreises niemand etwas sieht. Dafür war das Modell beim Rollout über das Entwurfsstadium hinaus: Es hatte an echten Projekten bereits funktioniert. Und im Planungsteam gab es Menschen, die es erklären konnten, weil sie es mitgebaut hatten.

Für das Datenmodell galt derselbe Ansatz wie für alles andere: erst der kleinste Umfang, der Nutzen bringt, dann erweitern. Wir haben deshalb nicht alle Layertypen auf einmal modelliert. Zuerst kamen die, an denen sich im Alltag entscheidet, ob die Plattform trägt.

Dieselbe Logik erklärt, warum die Plattform bis heute zwei Klassen von Layern kennt: standardisierte Layer im Datenmodell und alles andere. Das „alles andere" ist eine bewusste Entscheidung und keine Nachlässigkeit. Niemand sollte gezwungen sein, eine schnell gezogene Pufferfläche oder einen Layer aus einer externen Quelle in ein Datenmodell zu pressen. Schon gar nicht mitten in einer Migration unter Zeit- und Kostendruck.

Getroffen haben wir diese Entscheidung selbst. Wir haben die Migration geführt und hätten den Takt vorgeben und das Datenmodell zur Bedingung machen können. Das haben wir bewusst nicht getan. Ein Datenmodell, das den Alltag blockiert, wird umgangen. Dann steht es in der Dokumentation, aber die Daten liegen woanders.

Mit dem Go-Live war der Auftrag nicht zu Ende, es begann eine Hypercare-Phase. Wir haben das Planungsteam eng begleitet, Fragen und Fehlermeldungen kamen auf kurzen Wegen an. Wo das Modell in der Praxis klemmte, haben wir schnell nachgeschärft.

Der Grund dafür ist unspektakulär: Ein Werkzeug, das täglich benutzt wird, gewinnt Vertrauen in den ersten Wochen oder nie. Bleibt die erste Fehlermeldung drei Tage liegen, arbeiten die Leute wieder lokal weiter.