GEO Monitoring System: Schritt-für-Schritt Anleitung für Geomonitoring

Einstieg: Was Geomonitoring ist – und was du am Ende gebaut hast

Geomonitoring bedeutet: räumlich‑zeitliche Veränderungen kontinuierlich beobachten, bewerten und in Maßnahmen übersetzen. Typische Ziele sind Bodenbewegungen (Rutschungen, Setzungen), Bauwerks‑/Infrastrukturüberwachung (Brücken, Tunnel, Gleise) und Umweltindikatoren (Hydrologie, Vegetation). In diesem Tutorial baust du ein praxistaugliches System: von Sensorik und Satellitendaten über ETL‑Pipelines und Datenhaltung bis zu Web‑GIS, Zeitreihen‑Analysen und automatischen Warnungen.

Damit dein System interoperabel bleibt, orientieren wir uns an offenen Spezifikationen. Ein zentrales Fundament liefern die Standards des Open Geospatial Consortiums. Die Übersicht „Standards“ erklärt WMS/WFS/WCS, OGC API und SensorThings konsolidiert und verlinkt in die Spezifikationen: siehe die Seite zu den OGC‑Standards.

Zielbild und Referenzarchitektur

Ein robustes GEO‑Monitoring folgt einer klaren Schichtenlogik:

Sensor‑ und Datenquellenebene: Satellit (z. B. SAR für InSAR), GNSS‑Stationen, Totalstation/Tachymetrie, In‑situ‑Sensorik (Inklinometer, Piezometer, Dehnung, Faseroptik), UAV‑Befliegungen.
Ingestion/ETL: Streaming und Batch, Zeitbasis‑Harmonisierung (UTC), CRS‑Konsistenz, Metadaten und Qualitätsprüfungen.
Speicherung/Katalog: Geodatenbank (Vektor/Zeitscheiben), Rasterstrategie (Cloud‑Raster/COG), Katalog/Index, Provenienz.
Analyse: Zeitreihen, Geostatistik, InSAR‑Deformationen, Anomalieerkennung, saisonale Komponenten.
Dienste/Visualisierung: OGC‑Dienste und OGC API, Web‑GIS, 3D‑Szenen, thematische Stile, zeitliche Animationen.
Alerting/Operations: Schwellenwerte, Eskalationsketten, Trockenläufe, Monitoring, Wartung.

Batch vs. Near‑Real‑Time hängt von Risiko und Latenzanforderungen ab: Kritische Hänge oder Tunnelbau profitieren von Streaming, großflächige InSAR‑Analysen laufen meist in Batches. Frag dich: Welche Veränderungsgeschwindigkeit ist fachlich relevant, und wie kurz muss deine Reaktionszeit sein?

Schritt 1: Datenquellen auswählen und vorbereiten

Satellitendaten: Für Bodenbewegungen sind Radarinterferometrie‑Produkte (InSAR) aus Sentinel‑1 etabliert. Europaweit zeigt der European Ground Motion Service, wie standardisierte Deformationsdaten aussehen und wie sie interpretiert werden; ein guter Referenzrahmen ist das EGMS‑Portal. Für eigene Prozessketten liefert die ESA mit SNAP/STEP Werkzeuge, Tutorials und Dokumentation; Einstieg über die ESA SNAP/STEP‑Seite.

GNSS‑Stationen liefern punktgenaue Zeitreihen in Millimeter‑ bis Zentimeter‑Genauigkeit. Achte auf Standortqualität (Multipath‑Armut, freie Himmelsicht) und stabile Monumentierung. In‑situ‑Sensorik (Inklinometer, Piezometer, Dehnung) ergänzt das Bild direkt im Bauwerk oder Untergrund. UAV‑Bilder helfen bei optischer Dokumentation oder hochauflösenden DEMs/Orthos.

Compliance: Erhebst du personenbezogene Daten (z. B. identifizierbare Personen in UAV‑Bildern) oder Standortdaten mit Personenbezug, gelten die Vorgaben der EU‑Datenschutzgrundverordnung; offizieller Einstieg bei der Europäischen Kommission – Datenschutz. Für Drohnenbetrieb sind die EASA‑Regeln maßgeblich (ggf. nationale Auflagen beachten).

Checkpoint vor Schritt 2

Liegen für jede Quelle Metadaten (Sensor, Standort, Genauigkeit, Zeit) vor?
Sind Referenzpunkte/‑flächen definiert (z. B. stabile Targets für InSAR, GNSS‑Basispunkt)?
Sind Einwilligungen/Genehmigungen (UAV, Gelände, Datenschutz) geklärt?

Schritt 2: Ingestion & ETL aufsetzen

Ziel ist ein reproduzierbarer, beobachtbarer Datenfluss. Für Streaming‑Szenarien etablierst du Topics/Queues für Sensorstreams, im Batch verarbeitest du periodische Stacks (z. B. Sentinel‑1 SLC). Harmonisiere stets:

Zeit: UTC, klare Zeitfenster, Watermarks für Out‑of‑Order‑Daten.
Raum: einheitliches CRS (EPSG), dokumentierte Reprojektionen.
Struktur: Validierte Schemas und klare Einheiten.

Orientiere dich bei Beobachtungsdaten am OGC‑Ökosystem: Das SensorThings‑Datenmodell unterstützt historische und Echtzeit‑Messungen innerhalb der OGC‑Familie (Überblick in den OGC‑Standards verlinkt). Für InSAR‑ETL (Coregistrierung, Interferogramme, Phasenentfaltung, Geokodierung) nutzt du die in SNAP/STEP dokumentierten Prozessschritte; die ESA SNAP/STEP‑Seite verlinkt Tutorials und Komponenten.

Was tun, wenn… Zeitreihen Lücken oder Sprünge haben? Prüfe zuerst Sensorstatus, Kommunikationsausfälle und geplante Wartungsfenster. Bei InSAR liegt die Ursache oft in Dekorrelation (Vegetation, Schnee) oder ungünstiger Geometrie (Layover/Schatten); maskiere problematische Zonen und stütze dich auf stabile Referenzen.

Schritt 3: Speichern & Katalogisieren

Ein praktikabler Standard ist eine relationale Geodatenbank für Vektor und Zeitreihen (z. B. Stationen, Messpunkte, Deformationsvektoren) plus Cloud‑Raster für große Bild‑/Zeitdatensätze. Für Raster nutzt du Cloud‑Optimized GeoTIFFs (COG) im Objektspeicher und bindest sie über GDAL/VRT oder OGC‑Coverages an. Dokumentiere Provenienz: Quelle, Prozesskette, Versionen, Parameter.

Zur Performance: Indiziere Geometrien, Zeitstempel und Schlüsselattribute. Lege Zeitreihen als Messungen‑pro‑Feature mit sauberer Normalisierung an (z. B. Messwerttabelle mit foreign key auf Sensor/Ort). Für Governance hilft dir ein Lakehouse‑Denkmuster (einheitliche Tabellenformate, Batch/Stream unter einem Dach), ohne dich auf einen Anbieter festzulegen.

Entscheidungshilfe: Batch vs. Near‑Real‑Time

Kriterium	Batch-Verarbeitung	Near-Real-Time
Risiko/Use Case	Flächenhafte Analysen, periodische Reports	Baugrube, Tunnel, Hang mit schneller Dynamik
Latenz	Stunden bis Wochen	Sekunden bis Minuten
Kosten/Komplexität	Geringer in Betrieb	Höher (Streaming, Monitoring, SLOs)
Qualitätssicherung	Umfangreiche Off‑line‑Checks	Laufende QC, Drift-/Ausreißer-Detektion
Skalierung	Große Stacks planbar	Event‑Lastspitzen, Backpressure-Handling

Schritt 4: Verarbeitung & Analysen

InSAR‑Zeitreihen: Erzeuge aus Sentinel‑1‑Stacks Interferogramme, entferne die topographische Phase (DEM), entfalte Phasen, korrigiere Atmosphäre und invertiere Zeitreihen. Verankere die Serie über stabile Referenzflächen. Die Prozesslogik ist in den SNAP/STEP‑Ressourcen beschrieben (siehe ESA SNAP/STEP‑Seite). Beobachte Kohärenzmetriken; in komplexem Gelände sind Masken Pflicht.

GNSS‑Zeitreihen: Überwache Ausreißer, Sprünge (Eingriffe, Erdbeben) und saisonale Signale (Temperatur, Hydrologie). Kreuzvergleiche mit Referenzstationen erhöhen die Plausibilität. Für Anomalieerkennung in beiden Welten (InSAR/GNSS) reichen oft robuste Statistiken: gleitende Median‑/MAD‑Filter, saisonale Dekomposition, anschließend simple Regelwerke (z. B. n‑Sigma über Basislinie) als Vorstufe zu ML‑Methoden.

Schritt 5: Dienste & Visualisierung

Veröffentliche deine Daten als standardisierte Webdienste, damit Analyse und Lagebild überall erreichbar sind. Der GeoServer deckt WMS/WFS/WCS und moderne OGC API‑Features ab; Konfiguration, Publikation und Styling sind im GeoServer User Manual dokumentiert. Für Desktop und schnelle Analysen eignet sich QGIS. Zeitabhängige Layer bindest du an den Temporal Controller und kannst Animationen/Fenster definieren; die deutschsprachige Anleitung findest du unter QGIS – Zeitliche Steuerung.

Kurzer Praxis‑Workflow: Lade Deformationspunkte als WFS in QGIS, verknüpfe die Zeitreihe, aktiviere „Layereigenschaften → Zeitlich“, setze das Zeitfenster (z. B. 14 Tage) und erstelle eine animierte Karte. Style Schwellenwerte über abgestufte Farben und klare Legende. Für Raster (COG) nutze WMS/WCS oder direkte COG‑Tiling.

Schritt 6: Alerting & Betrieb

Technisch sollten Warnungen strukturiert, maschinenlesbar und über mehrere Kanäle versendbar sein. Das Common Alerting Protocol (CAP) ist der De‑facto‑Standard im Katastrophen‑ und Warnwesen; Spezifikation und Profile pflegt OASIS, Einstieg über das OASIS CAP Technical Committee. Erzeuge CAP‑Payloads mit aussagekräftigen Feldern (Beschreibung, Geometrie, Schweregrad, Dringlichkeit) und spiele Trockenläufe durch, bevor du live gehst.

Betrieb heißt außerdem: Service‑Monitoring (Latenz, Fehlerquoten), Eskalationsketten (Wer entscheidet, wer benachrichtigt wird?), Wartungsfenster, Backups und ein Incident‑Playbook. Plane regelmäßige End‑to‑End‑Tests – sie finden Schwächen, bevor es kritisch wird.

Kompakte Betriebs‑Checkliste

Alarmschwellen definiert und dokumentiert (Bezug: Messunsicherheiten)?
CAP‑Payloads validiert, Trockenläufe protokolliert?
Eskalationsmatrix (Rollen, 24/7‑Abdeckung) etabliert?
Monitoring/Logs/Metriken mit Alarmierungen verbunden?
Backup/Restore, Failover und Wartungsfenster getestet?

Mini‑Fallbeispiel: Hangböschung mit Setzungstendenz

Ausgangslage: Ein 600‑m‑Hang oberhalb einer Landstraße zeigt historische Setzungen. Ziel sind frühzeitige Hinweise auf Beschleunigung.

Datenlage: Du kombinierst Sentinel‑1‑InSAR (monatlicher Batch) mit drei GNSS‑Punkten (1‑Minuten‑Stream) und zwei Inklinometern (5‑Minuten‑Takt). Ein UAV‑Flug pro Quartal liefert aktualisierte Orthos/DEM.

Pipeline: InSAR‑Stacks werden monatlich verarbeitet, Qualität geprüft (Kohärenzschwelle, Masken), anschließend als Deformationspunkte mit Zeitreihen in die Geodatenbank geschrieben. GNSS und Inklinometer laufen als Streams in definierte Topics, ETL harmonisiert Zeit/CRS und prüft Ausreißer. Alle Layer werden als WMS/WFS veröffentlicht, QGIS visualisiert die Entwicklung über den Temporal Controller.

Schwellenwerte: Für GNSS definierst du 2‑mm/Tag (Warnung) und 4‑mm/Tag (Alarm) über 48‑h‑Fenster; InSAR meldet, wenn die monatliche Geschwindigkeit 10 mm/Jahr überschreitet und das Muster mit GNSS korreliert. Ein CAP‑Alarm wird ausgelöst, wenn mindestens zwei Sensorfamilien gleichzeitig Alarm zeigen. Trockenläufe werden monatlich geübt, inklusive Benachrichtigungskette.

Ergebnis: Ein Dashboard zeigt Zeitreihen, Karte mit Schwellenwert‑Styling und letzte Alarme. Das Team erhält belastbare, kontextreiche Signale statt bloßer Zahlen.

Häufige Fehlerbilder – und wie du sie schnell entschärfst

InSAR‑Artefakte: Layover/Schatten in steilen Hängen führen zu unzuverlässigen Phasen. Lösung: Maskiere betroffene Zonen, prüfe Blickrichtung und nutze stabile Referenzflächen. Dekorrelation durch Vegetation/Schnee? Verkürze zeitliche Baselines, setze kohärenzschonende Filter und bewerte Saisonalität.

GNSS‑Probleme: Sprünge nach Eingriffen oder Störungen wirken wie Anomalien. Dokumentiere Ereignisse, prüfe Antennen‑/Kabelzustand und aktualisiere Antennenkalibrierdateien. Multipath zeigt sich als systematische Wellen – Standortoptimierung und geeignete Antennen (z. B. Choke‑Ring) helfen.

Dienste/CRS‑Konflikte: Falsche EPSG‑Codes oder uneinheitliche Achsenreihenfolge führen zu Versätzen. Validiere Capabilities, prüfe Layer‑SRS und Styles. Bei Coverages kläre Subsetting‑Parameter, um Server‑Timeouts zu vermeiden. Details zur Dienstkonfiguration findest du im GeoServer User Manual.

Nächste Schritte & Verantwortlichkeiten

Rollen klären: Wer betreibt Sensorik, wer pflegt ETL/DB, wer verantwortet Analyse, Visualisierung und Alarmierung? Eine klare Ownership reduziert Mean‑Time‑to‑Repair.
Wartung fixieren: Regelmäßige Inspektionen (Sensorik), Software‑ und Sicherheitsupdates (Server/Cloud), Backups/Restore‑Tests, Alarmläufe.
Dokumentation leben: Systemarchitektur, Datenmodelle, QC‑Regeln, Schwellenwerte, Playbooks. Jede Änderung mit Version und Datum festhalten.
Roadmap planen: Erweiterungen (weitere Sensorfamilien), Performance‑Verbesserungen (COG‑Tiling, Caches), Governance (Katalog/Metadaten), Schulungen.

Zum Schluss eine Frage: Wenn morgen früh ein Alarm eingeht – weiß dein Team in fünf Minuten, was passiert ist, wie zuverlässig das Signal ist und was als Nächstes zu tun ist? Baue dein System so, dass die Antwort „Ja“ lautet.