Vom Chat zur Karte: Wie DGGS + Agentic AI Geodaten in verifizierbare Entscheidungsgrundlagen verwandeln

Kontext: Warum „GeoAI“ ohne Standards scheitert

Wenn wir heute „KI + Geodaten“ sagen, denken viele zuerst an einen Chatbot, der Karten „beschreiben“ kann. In der Praxis scheitern Anwendungen jedoch selten an fehlenden Modellen – sondern lieber wegen Mangelnde Interoperabilität, Rückverfolgbarkeit und maschinelle Lesbarkeit:

• Die Daten werden über verschiedene Dienste und Formate verteilt.
• Die Anfragen sind oft nicht „KI-fähig“ (zu wenige Metadaten, zu wenige Leitplanken, unklare Kosten/Granularität).
• Die Ergebnisse sind schwierig reproduzieren or Prüfung – insbesondere in Krisensituationen, in denen Vertrauen, Herkunft, Zugriffskontrolle und Kontext von entscheidender Bedeutung sind.

Die OGC AI-DGGS-Pilotprojekt für Katastrophenmanagement Er ging genau auf dieses Problem ein: nicht auf „KI als Demonstration“, sondern KI als Orchestrator für interoperable Geodienste – mit einem klaren Fokus auf Standards, Umsetzbarkeit und Reibungsverluste in der Praxis.

Was wir im Pilotprojekt entwickelt und demonstriert haben

Im Pilotprojekt verwendeten wir DGGS (Diskrete globale Gittersysteme) als eine gemeinsame „räumliche Sprache“, um heterogene Katastrophendaten einheitlich zu referenzieren und zu analysieren.

Kernidee

DGGS-Zellen verhalten sich zur Geodaten-KI wie Token zur Sprache: stabil, hierarchisch, maschinenlesbarDies erleichtert die Aggregation, Analysen mit mehreren Auflösungen und die Interaktion verschiedener Datenquellen.

Architektur in einem Satz

Wir haben mehrere unabhängige DGGS-Datenserver und mehrere unabhängige KI-Clients so miteinander verbunden, dass sie sich wie folgt verhalten eine interoperable Analyse-Engine – ergänzt durch ein Gemeinsames Lagebild (COP) Ebene für Kontext, Vertrauen und die gemeinsame Nutzung der Frage, „was wann für wen gilt“.

Was funktionierte interoperabel (auf hoher Ebene)?

• Mehrere DGGS/DGGRS-Implementierungen (einschließlich H3, A5, verschiedene ISEA-Varianten usw.)
• Implementierungen auf mehreren Servern (unterschiedliche Stacks/Anbieter)
• Mehrere KI-Clients/agentenbasierte Workflows (toolbasierte Abfragen anstelle von „halluzinierten Koordinaten“)
• Weiterentwicklung des COP/OWS-Kontexts als Transfermechanismus für Situationsbewertung + Sicherheit/Vertrauen/Herkunft

Warum ist das wichtig?

Denn es zeigt, dass „KI-Schlussfolgerungen“ im Bereich der Geodaten nicht primär durch Modelltraining skalieren, sondern durch standardisierte, werkzeugähnliche Schnittstellen, maschinenlesbare Metadaten und reproduzierbare Serviceketten.

Die wichtigsten Erkenntnisse: Vier Reibungspunkte, die wir gezielt angehen müssen

1. Reibungsverluste bei geometrischer Ausrichtung: Unterschiede zwischen Bezugspunkten und Modellen (H3-Orthallisch vs. WGS84)
   Ein zentrales praktisches Problem war die geometrische Ausrichtung Zwischen weit verbreiteten Systemen kann es zu Problemen kommen, insbesondere wenn ein DGGS-Modell (z. B. mit orthallischen/sphärischen Annahmen) auf WGS84-/ellipsoidische Erwartungen trifft. In der Praxis bedeutet dies, dass Clients, wenn Serverantworten die zugrunde liegenden Parameter nicht eindeutig beschreiben, „rückwärts rechnen“ müssen – und genau dann wird es gefährlich.Mitnehmen: Wir brauchen klare Best Practices und eindeutige Parametrisierung „gleichnamig“ bedeutet also eigentlich „gleich“.
2. Leistungs-/Datenlückenproblem: Hochauflösende Erdbeobachtungsdaten sind oft „lückenhaft“.
   Katastrophenschutz-Workflows nutzen häufig hochauflösende Sensordaten – und diese Daten sind spärlichGroße Gebiete ohne Messungen, Lücken in Raum und Zeit sowie unterschiedliche Geometrien der Überflüge stellen keine Ausnahme, sondern die Regel dar. In der Praxis führt dies zu folgendem Bild: Ein agentenbasierter Workflow führt nicht nur eine einzelne Abfrage aus, sondern arbeitet iterativ: Zuerst werden Daten zur Überschwemmungsausdehnung angefordert, dann Bevölkerungsdaten, anschließend Infrastrukturdaten, dann höher aufgelöste Daten und schließlich Daten aus verschiedenen Zeitpunkten. Dies führt schnell zu Hunderten oder Tausenden von API-Aufrufen, oft in kleinen Kacheln. Die Folgen sind zunehmende Latenzen, das Eingreifen von Ratenbegrenzungen und immer mehr Wiederholungsversuche, bis der Agent in einer Schleife aus „Abrufen → Warten → Wiederholen“ gefangen ist und kein stabiles Ergebnis mehr erzielen kann. Darüber hinaus werden oft zu viele Daten übertragen, wenn der Client die benötigte Auflösung, das genaue Untersuchungsgebiet oder die relevanten Attribute nicht präzise angeben kann. Statt aggregierter Statistiken werden unnötig große Mengen an Rohdaten geladen, wodurch Netzwerk- und Speicherkosten zum dominierenden Faktor werden. Das typische Problem von Datenlücken in Erdbeobachtungs- und Katastrophendaten verschärft die Situation zusätzlich: Wolken, Satellitenorbits oder fehlende Zeitstempel erzeugen „Datenlöcher“. Erkennt der Workflow diese Lücken nicht, fragt er leere Bereiche ab, interpretiert fehlende Daten fälschlicherweise als „kein Ereignis“ oder versucht es erneut mit anderen Parametern. Dies führt zu zusätzlichem I/O, geringerer Ergebnisqualität und insgesamt weniger nutzbaren Daten. Im Pilotprojekt haben wir daher gezielt diskutiert und experimentiert mit … optimierte Kodierungen (z. B. kompakte Zellrepräsentationen, effiziente Backends, Parquet-Pfade für spärliche Daten).Mitnehmen: KI-Workflows scheitern nicht am Modell selbst, sondern an der Ein-/Ausgabe. Standardisierte Antworten sind erforderlich. Sparsity-kompatibel und BandbreitenbewusstMit anderen Worten: Der Flaschenhals ist oft nicht die Modellinferenz, sondern vielmehr, dass der Workflow zu langsam, zu teuer oder zu instabil wird, weil er zu viele oder zu große Datenmengen über das Netzwerk/den Speicher übertragen muss – und ständig auf fehlende/inkonsistente Abdeckung stößt (Sparsity, „Datenlöcher“). 
3. „Stapelparadoxon“ / Topologiereibung: Unterzonen und Überlappungen bei bestimmten Öffnungen
   In DGGS/DGGRS-Systemen wird oft implizit angenommen, dass eine Zone der Ebene L vollständig und disjunkt durch ihre Subzonen der Ebene L+1 partitioniert wird (z. B. „Apertur-7 ⇒ 7 Kinder“). In der Praxis kann diese Annahme jedoch zutreffen: Abhängig vom Gitterdesign, der Parametrisierung und geometrischen Sonderfällen können „Subzonen“ als topologische Überdeckung (Zellen, die die übergeordnete Zone schneiden/überlappen) anstatt als exakte, nicht überlappende Zerlegungen definiert werden. Dies führt dazu, dass deutlich mehr Kandidaten als erwartet zurückgegeben werden und sich diese räumlich überlappen. Empfehlung für Implementierer: Clients sollten Subzonen daher nicht über feste Kardinalitäten oder reine ID-Arithmetik ableiten, sondern über klar definierte Operationen und Semantik.
   • Explizit zwischen Partition (disjunkt, exakt) und Cover (mögliche Überlappungen) unterscheiden.
   • Führen Sie die Aggregationen so durch, dass Überschneidungen nicht zu Doppelzählungen führen (z. B. durch definierte Gewichtungs-/Schnittmengenregeln oder serverseitige Aggregationsendpunkte).
   • und Konformitätstests verwenden/ergänzen, die genau diese Grenzfälle (Überlappungen, Grenzfälle) aufdecken.

   Mitnehmen: Echte Interoperabilität erfordert nicht nur IDs, sondern auch Topologie- und Ausrichtungsregeln die umsetzbar und testbar sind.

4. Registry-/Metadaten-Reibung: Gleiche Bezeichnung, unterschiedliche Parameter
   Ein wiederkehrendes Muster: Bezeichnungen können in verschiedenen Bibliotheken ähnlich erscheinen, sich aber in Details unterscheiden (Parameter, Datumsannahmen, ID-Varianten/Indexierungsschemata). Darüber hinaus Zonen-IDs Sie unterscheiden sich manchmal, obwohl sie sich auf „dieselben Zellen“ beziehen.Mitnehmen: Wir brauchen eine maßgebliches OGC DGGS/DGGRS-Register die Parameter klar beschreibt, Varianten klar trennt und Querverweise bereitstellt. 

KI-Bereitschaft: Was die OGC-Standards jetzt leisten müssen

Das Pilotprojekt hat gezeigt, dass „KI-fähig“ nicht einfach nur eine „Chat-Oberfläche“ bedeutet, sondern vielmehr eine Schnittstelle und ein Ökosystem, die eine zuverlässige agentenbasierte Nutzung ermöglichen – mit klarer Semantik, maschinenlesbaren Einschränkungen und reproduzierbaren Ergebnissen.

KI-Bereitschaft erfordert:

1. Werkzeugfähigkeit: Endpunkte müssen so beschrieben werden, dass Agenten sie zuverlässig nutzen können.
2. Maschinenlesbare Metadaten: Abfrageobjekte, Grenzwerte, Kostenindikatoren, Unsicherheiten, Auflösung/Granularität.
3. Leitplanken: Schutz vor übermäßigem Abrufen von Daten, falscher Auflösungswahl und unkontrollierten Kosten.
4. Reproduzierbarkeit: Abfragen und Ergebnisse müssen reproduzierbar sein – insbesondere bei Situationsanalysen.
5. Vertrauen und Sicherheit: Kontext, Identität, Herkunft, Zugangsrichtlinien.

Die Diskussion über die Weiterentwicklung des OWS-Kontexts war hier besonders relevant: Der OWS-Kontext kann als Grundlage für die Übertragung eines gemeinsames Betriebsbild zwischen Organisationen, aber es muss aktualisiert werden, um den heutigen Anforderungen gerecht zu werden (Dienste/Workflows, dynamische Ereignisse, Sicherheit/Klassifizierung, KI-RAG/Agenten-Pipelines).

Benchmarks und Umsetzbarkeit: Warum „DGGRS-Wahl“ nicht neutral ist

Ich habe bei der Implementierung der verschiedenen DGGRS einen wichtigen, praktischen Punkt hervorgehoben: DGGRS-Implementierungen unterlasse verhalten identisch Hinsichtlich Leistung und Effizienz wurden im Pilotprojekt Benchmarks und Optimierungen (einschließlich Format/Komprimierung) diskutiert; unter anderem wurde darauf hingewiesen, dass einzelne Systeme bei bestimmten Operationen deutlich langsamer/schneller sein können.

Mitnehmen: Interoperabilität bedeutet nicht, dass alles gleich schnell ist – aber Standards sollten dies ermöglichen. Fähigkeiten, zu erwartende Kosten und geeignete Optionen transparent.

Roadmap: Sechs konkrete Schritte, die wir aus dem Pilotprojekt ableiten

Aus dem Pilotprojekt lassen sich sehr konkrete Standardisierungs- und Gemeinschaftsaufgaben ableiten:

1. OGC DGGS/DGGRS-RegisterParametrisierung, Datumsreferenzen, Indexierungsschemata, Querverweise.
2. H3 Best Practice: klare Vorgaben zur Modell-/Dateninterpretation und zu den Erwartungen an die Übereinstimmung.
3. Verbesserte Abfragemechanik: klarere Abfrageobjekte, robustere Muster für Begrenzung/Auswahl/Aggregation; optionaler „Einstieg“ für Nicht-DGGS-Clients (z. B. Geometrie-First-Anfrage, die serverseitig zu DGGS aufgelöst wird).
4. Zeitliche Rasterung als erstklassiges ThemaDGGS ist nicht einfach nur „Raum“; Katastrophen sind immer Raum und Zeit.
5. Operationalisierung von COP + Vertrauen/Herkunft (IPT): Weiterentwicklung des OWS-Kontexts zu einem maschinenlesbaren Lagebildcontainer inklusive Sicherheits-/Richtlinien-/Zugriffs-/Herkunftsinformationen.
6. Analytische Erweiterungen: ein übersichtlicher Katalog, welche Analysen in standardisierter „zellenweiser“ Weise verfügbar sein sollten (Aggregation, Zonenstatistiken, Indizes usw.).

Einladung: Wie Sie als Umsetzer oder Mitglied beitragen können

Wir möchten die Ergebnisse des Pilotprojekts der Gemeinschaft zugänglich machen und sie in priorisierte, umsetzbare Bausteine ​​verwandeln.

Wenn Sie OGC-Mitglied sind:

• Engagieren Sie sich im Agora-Diskussion auf registry/best practice/queryables.
• Schildern Sie die in der Praxis aufgetretenen Probleme bei der Implementierung (wenn möglich, inklusive Screenshots/Benchmarks).

Wenn Sie ein Umsetzer sind:

• Vergleichen Sie Ihre Parametrisierung mit anderen Bibliotheken/Servern.
• Geben Sie Feedback zu folgender Frage: „Welche Metadaten benötigt ein Agent wirklich?“

Wenn Sie bei der Gestaltung von Standards mitwirken:

• Helfen Sie mit, Konformitätstests zu definieren, die genau diese Reibungspunkte aufdecken.

Fazit: „Echte Reibung, echte Lösung“

Das Pilotprojekt hat gezeigt, dass wir kurz davor stehen, „KI für Geodaten“ vom Demo- zum Anwendungsstadium zu bringen. zuverlässige, interoperable Praxis—aber nur, wenn wir die eigentlichen Reibungspunkte standardisieren: Registrierung, Ausrichtung, Sparsity-kompatible Kodierungen, maschinenlesbare Metadaten, Vertrauen/Kontext.

Das ist die eigentliche Chance: Standards machen KI rechenschaftspflichtig.

Wenn Sie an Registry-/Best-Practice-Ansätzen, der Weiterentwicklung des COP/OWS-Kontexts oder KI-fähigen Metadaten arbeiten möchten: Kontakt aufnehmen

Anhang A

DGGS vs DGGRS

Ein DGGRS (Diskretes Globales Gitterreferenzsystem) ist ein vollständiges, operationelles räumliches Referenzsystem, das drei Komponenten kombiniert:

1. DGGH (Discrete Global Grid Hierarchy): Die hierarchische Tessellierung der Erdoberfläche in Zonen mit sukzessiven Verfeinerungsebenen
2. ZIRS (Zone Identifier Reference System): Ein Schema zur eindeutigen Benennung und Adressierung jeder Zone
3. Deterministische Unterzonenanordnung: Eine standardisierte Sequenz zur Organisation von Unterzonen innerhalb von übergeordneten Zonen, die eine optimierte Datenkodierung ermöglicht.

Im Wesentlichen handelt es sich bei einem DGGRS um ein sofort einsatzbereites System zur Referenzierung und Organisation von Geodaten in einem globalen Raster, während ein DGGS das umfassendere integrierte Software-Framework ist, das ein oder mehrere DGGRS zusammen mit Quantisierungsfunktionen, Abfragefunktionen und Interoperabilitätswerkzeugen implementieren kann.