Wie wir es umsetzen

p2d2 ist eine Web-Anwendung zur browserbasierten Erfassung und Bearbeitung von Geodaten für die OpenStreetMap. Statt Dateien zu exportieren, um sie in Desktop-GIS zu bearbeiten, können Kommunen, Friedhofsverwaltungen und ehrenamtliche Mapper direkt im Browser editieren, versionieren und in einen OSM-Export überführen. Das System ist vollständig auf Open-Source-Komponenten aufgebaut.

Zwei Editoren, ein System

p2d2 umfasst derzeit zwei Facheditoren, die auf demselben technischen Fundament stehen. Der Grabflur-Editor bearbeitet die Polygone ganzer Grabfelder. Der Nutzer klickt auf einen Friedhof, die Karte zoomt heran, und mit einem Doppelklick auf eine Grabflur öffnet sich der Editier-Modus. Der Grabflur-Editor ist sehr weitgehend umgesetzt und steht kurz vor dem produktiven Einsatz.

Der Feature-Editor bearbeitet einzelne georeferenzierte Objekte innerhalb einer solchen Fläche - zum Beispiel Grabstellen innerhalb einer Grabflur, aber künftig auch Baumscheiben innerhalb eines Stadtbezirks oder Laternen innerhalb eines Straßenzugs. Der Name „Feature“ ist bewusst gewählt: Die Architektur ist offen für beliebige Objekttypen, nicht nur für Gräber. Der Feature-Editor war die Basis des Grabflur-Editors und wurde zugunsten des Grabflur-Editors etwas zurück gestellt und wird nach der Fertigstellung des Grabflur-Editors an dessen Entwicklungsstand angepasst.

Beide Editoren nutzen OpenLayers als Kartenbibliothek und kommunizieren per WFS-T (transaktionaler Web Feature Service) mit dem GeoServer. Die Geometrien werden clientseitig als GeoJSON gehalten, serverseitig in GML konvertiert und über eine WFS-Transaction an den GeoServer gesendet. Für Zwischenspeicherungen (Snapshots) einer Editier- Session werden differenzielle Geo-JSON Objekte direkt in die Datenbank (Server-seitige Zugriffskontrolle) geschrieben, so dass bei einem Verbindungsabbruch nach Time-Out ein Hintergrund-Prozess die einzelnen Snapshots wieder zusammen setzen und als eine Version abspeichern kann, die bei einer erneuten Editier-Vorgang als Version angeboten wird.

Authentifizierung und Berechtigungen

Nutzer melden sich über Zitadel als Identity Provider an. AstroJS übernimmt den Login-Flow serverseitig, setzt nach erfolgreichem Callback einen verschlüsselten Session-Cookie und prüft bei jeder weiteren Anfrage, ob der Nutzer die erforderliche Rolle mitbringt. Die GeoServer-Zugangsdaten bleiben ausschließlich auf dem Server - der Browser sieht sie nie. Das System kennt vier Rollen:

  • editor - Darf Geodaten öffnen, bearbeiten und speichern
  • qs1_reviewer - Interne Qualitätssicherung vor dem OSM-Export
  • qs2_reviewer - Feedback aus der OSM-Community vor der Freigabe
  • export_admin - Darf OSM-Exporte anstoßen und verwalten

Das gesamte Authentifizierungssystem wurde vollständig implementiert und ist produktiv. Die Berechtigungsprüfung erfolgt serverseitig in jeder Route; die Zugangsdaten für GeoServer und Datenbank werden pro Stage getrennt in Umgebungsvariablen vorgehalten.

Session-Workflow und Datenmodell

Jede Bearbeitung folgt einem klaren Ablauf, der sicherstellt, dass Änderungen nachvollziehbar sind, keine Datenkonflikte entstehen und jederzeit ein konsistenter Datensatz vorliegt. Der Ablauf ist:

  1. Der Nutzer klickt auf eine Grabflur und öffnet eine Bearbeitungssitzung. Der Server legt einen Sitzungseintrag an, setzt eine Sperre auf den gesamten Friedhof (eine aktive Sitzung pro Friedhof) und reserviert die nächste Versionsnummer.
  2. Der Nutzer bearbeitet Geometrien über OpenLayers. Änderungen werden clientseitig gesammelt, aber noch nicht persistiert.
  3. Der Nutzer speichert die Änderungen. Der Server sendet jede geänderte Geometrie per WFS-T an den GeoServer, ein Datenbank-Trigger sorgt dafür, dass alle unveränderten Objekte desselben Friedhofs automatisch in dieselbe Version übernommen werden, und die Sitzung wird geschlossen.

Versucht ein zweiter Nutzer, denselben Friedhof zu bearbeiten, erhält er eine verständliche Meldung - kein technischer Fehler, sondern ein erwarteter Zustand.

Datenmodell

Das Datenbankschema unterscheidet drei Ebenen. Die Stammdaten enthalten die ursprünglichen Geometrien aus dem Import; in sie wird nur beim Datenimport geschrieben. Die Versionen speichern jeden historischen Zustand einer Geometrie mit Versionsnummer, Zeitstempel, Bearbeiter und Kommentar. Die Workflow-Tabellen steuern den Lebenszyklus jeder editierbaren Einheit - vom Beginn der Bearbeitung über die interne Qualitätssicherung bis zur Freigabe für den OSM-Export. Eine kombinierte Sicht vereint Stammdaten und aktuelle Versionen, sodass nachgelagerte Prozesse stets auf dem letzten Stand arbeiten können. Dieses Datenmodell ist vollständig umgesetzt und produktiv.

Staging und Deployment

Die Grundinfrastruktur läuft stabil auf fünf unabhängigen Stages, die sich von der Datenbank bis zum Webserver durchziehen: Produktion, Entwicklung und drei parallele Feature-Stages für die Arbeit von zwei Teams und einem externen Partner. Jede Stage hat ein eigenes Datenbank-Schema, einen eigenen GeoServer-Workspace und eigene Zugangsdaten. Die Schemata sind untereinander lesend sichtbar, aber nur das eigene Schema darf beschrieben werden. Jeder Stage ist ein Git-Branch zugeordnet; CI/CD-Deployments laufen automatisch bei Push.

Infrastruktur

Die gesamte Infrastruktur ist open-source-basiert und wird auf eigener Hardware betrieben. Proxmox VE virtualisiert die Server, OPNsense übernimmt Firewall und Netzwerk-Trennung, GitLab CI steuert die automatisierten Builds und Deployments. Als Datenbank dient PostgreSQL mit PostGIS; der GeoServer stellt die OGC-konformen WFS- und WFS-T-Schnittstellen bereit. AstroJS im SSR-Modus liefert die Web-Anwendung aus - serverseitig gerendert, mit eigenen API-Routen und Middleware für Authentifizierung und Berechtigungsprüfung.

Mobilnutzung

Die Editor-Oberfläche wird derzeit für mobile Geräte optimiert. Die Arbeiten laufen aktiv und betreffen sowohl den Grabflur- als auch den Feature-Editor. Im Fokus stehen Touch-Interaktion (Verschieben, Pinch-Zoom, Punktbearbeitung) und responsive Layouts für Werkzeugleiste und Bedienelemente auf kleinen Bildschirmen.

Ausblick

  • Feature-Editor - Die Editor-Oberfläche wird fertiggestellt, das Datenmodell ist bereits angelegt.
  • OSM-Export - Geprüfte und freigegebene Daten nach OpenStreetMap exportieren.
  • Weitere Kategorien - Baumscheiben, Straßenlaternen und andere kommunale Objekttypen können aktiviert werden, sobald Kommunen Datensätze einbringen. Die Architektur ist dafür vorbereitet.
  • Plugin-Integration - p2d2 als Plugin für Civitas Core, einer kommunalen Open-Source-Datenplattform.