Geodaten-Plattform in der Cloud

Zahlreiche Layertypen, jeder mit eigener Tabelle in PostGIS und festem Schema aus Pflicht- und optionalen Feldern: Anlagenstandorte, Abstandsflächen, Planungsrecht, Richtfunkstrecken, Kabeltrassen, Kranstellflächen, Fundamente, Zuwegungen, Netzverknüpfungspunkte, Batteriespeicher. Das Modell ist entlang der Fragen entstanden, die im Projekt von verschiedensten Fachbereichen gestellt werden - und es deckt beide Seiten des Hybridparks ab: Für Batteriespeicher gibt es einen eigenen Layertyp, sie sind kein Anhängsel der Windplanung.

Ein Beispiel: Der Typ für Anlagenstandorte verlangt Anlagennummer, Anlagentyp und Nabenhöhe. Damit ist die Nabenhöhe in jedem Projekt an derselben Stelle - und eine Auswertung über alle Projekte hinweg wird zu einer Abfrage statt zu einer Rundmail.

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

Die Reihenfolge je Projekt ist der Punkt, an dem viele Sync-Systeme scheitern: Zwei Push-Vorgänge am selben Projekt können sich nicht überholen und sich damit nicht gegenseitig überschreiben. Was trotzdem fehlschlägt, landet in einer Dead-Letter-Queue und ist einsehbar.

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

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 die Änderung, nicht das Projekt.

Jede Änderung an einem Layer im Datenmodell wird systemseitig historisiert, mit Zeitpunkt und Urheber. In der Web-App ist sichtbar, wer wann was zuletzt geändert hat. Gelöschte Layer lassen sich aus der Historie zurückholen.

Beim Löschen in QGIS werden Daten, Metadaten und der veröffentlichte Geoserver-Layer gemeinsam entfernt. 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, hat sich daran entschieden, welche Fragen im Projekt tatsächlich beantwortet werden müssen.

Erst als die Pilotierung abgeschlossen war, sind wir in den Rollout gegangen. Das kostet Zeit, in der außerhalb des Pilotkreises niemand etwas sieht. Der Gegenwert: Beim Rollout stand kein Entwurf zur Diskussion, sondern ein Modell, das an echten Projekten funktioniert hatte - und es gab Menschen im Planungsteam, 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 echten Nutzen bringt, dann erweitern. Nicht alle Layertypen auf einmal, sondern 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 keine Nachlässigkeit, sondern eine Entscheidung. 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.

Bemerkenswert ist, wer diese Entscheidung getroffen hat: Wir haben die Migration selbst geführt - wir hätten den Takt vorgeben und das Datenmodell zur Bedingung machen können. Genau das haben wir nicht getan. Ein Datenmodell, das den Alltag blockiert, wird umgangen; dann steht es in der Dokumentation, aber die Daten liegen woanders.

Der Go-Live war nicht das Ende des Auftrags, sondern der Anfang einer Hypercare-Phase: Enge Begleitung des Planungsteams, kurze Wege für Fragen und Fehlermeldungen, schnelles Nachschärfen dort, wo das Modell in der Praxis klemmte.

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