Van chat naar kaart: hoe DGGS + Agentic AI geodata omzetten in verifieerbare beslissingsgrondslagen

Context: Waarom “GeoAI” faalt zonder standaarden

Als we het vandaag de dag over "AI + geospatiaal" hebben, denken veel mensen meteen aan een chatbot die kaarten kan "beschrijven". In de praktijk falen toepassingen echter zelden door een gebrek aan modellen, maar eerder door een gebrek aan interoperabiliteit, traceerbaarheid en machineleesbaarheid.

• De gegevens zijn verspreid over verschillende diensten en formaten.
• Zoekopdrachten zijn vaak niet "AI-compatibel" (te weinig metadata, te weinig waarborgen, onduidelijke kosten/granulariteit).
• De resultaten zijn moeilijk reproduceren or controleren – vooral in crisissituaties waar vertrouwen, herkomst, toegangscontrole en context cruciaal zijn.

Het OGC AI-DGGS-pilotproject voor rampenbeheer pakte precies dit probleem aan: niet "AI als demonstratie", maar AI als orkestrator voor interoperabele geodiensten – met een duidelijke focus op standaarden, implementeerbaarheid en praktische knelpunten.

Wat we hebben gebouwd en gedemonstreerd in de pilot.

In de pilot gebruikten we DGGS (Discrete Global Grid Systems) als een gemeenschappelijke "ruimtelijke taal" om op consistente wijze naar heterogene rampgegevens te verwijzen en deze te analyseren.

Kerngedachte

DGGS-cellen zijn voor geospatiale AI wat tokens zijn voor taal: stabiel, hiërarchisch en machinaal leesbaar . Dit maakt aggregatie, analyses met meerdere resoluties en de interactie tussen verschillende databronnen mogelijk.

Architectuur in één zin

We hebben verschillende onafhankelijke DGGS-dataservers en verschillende onafhankelijke AI-clients zodanig met elkaar verbonden dat ze zich gedragen als een interoperabele analyse-engine – aangevuld met een Common Operating Picture (COP) -laag voor context, vertrouwen en het delen van "wat wanneer op wie van toepassing is".

Wat werkte op een interoperabele manier samen (op hoog niveau)?

• Meerdere DGGS/DGGRS-implementaties (inclusief H3, A5, diverse ISEA-varianten, enz.)
• Meerdere serverimplementaties (verschillende stacks/providers)
• Meerdere AI-clients/agentgebaseerde workflows (op tools gebaseerde zoekopdrachten in plaats van "gehallucineerde coördinaten")
• Verdere ontwikkeling in de context van COP/OWS als overdrachtsmechanisme voor situatiebeoordeling + veiligheid/vertrouwen/herkomst

Waarom is dit belangrijk?

Omdat het aantoont dat "AI-redenering" in de georuimtelijke sector niet primair schaalbaar is door middel van modeltraining, maar door gestandaardiseerde, toolachtige interfaces, machineleesbare metadata en reproduceerbare serviceketens.

De belangrijkste bevindingen: vier knelpunten die we specifiek moeten aanpakken.

1. Wrijving bij geometrische uitlijning: Verschillen tussen referentiepunten/modellen (H3 orthollisch versus WGS84)
   Een belangrijk praktisch probleem was de geometrische uitlijning Er kunnen problemen ontstaan ​​tussen veelgebruikte systemen, vooral wanneer een DGGS-wereld (bijvoorbeeld met orthollische/bolvormige aannames) botst met WGS84/ellipsoïdale verwachtingen. In de praktijk betekent dit dat als serverreacties de onderliggende parameters niet duidelijk beschrijven, clients "achteruit moeten rekenen" – en dat is waar het gevaarlijk wordt.Afhaal: We moeten duidelijke beste praktijken en eenduidige parameterisering zodat "gelijk genoemd" eigenlijk "gelijk" betekent.
2. Prestatie-/schaarste-wrijving: Hoogwaardige aardobservatiegegevens zijn vaak "schaars".
   Bij rampenbestrijding wordt vaak gebruikgemaakt van sensorgegevens met een hoge resolutie – en deze gegevens zijn dunGrote gebieden zonder metingen, hiaten in ruimte en tijd, verschillende doorgangsgeometrieën. Dit is geen uitzondering, maar de norm. In de praktijk resulteert dit in het volgende beeld: een agentworkflow voert niet slechts één query uit, maar werkt iteratief: eerst worden gegevens over de omvang van de overstroming opgevraagd, vervolgens bevolkingsgegevens, dan infrastructuurgegevens, dan gegevens met een hogere resolutie en ten slotte gegevens van verschillende tijdstippen. Dit resulteert al snel in honderden of duizenden API-aanroepen, vaak in kleine tegels. De gevolgen zijn oplopende latentie, snelheidslimieten die in werking treden en steeds meer herhaalpogingen totdat de agent vastloopt in een lus van "ophalen → wachten → opnieuw proberen" en geen stabiel resultaat meer kan behalen. Bovendien wordt er vaak te veel data overgedragen wanneer de client de vereiste resolutie, het exacte onderzoeksgebied of de juiste attributen niet nauwkeurig kan specificeren. In plaats van geaggregeerde statistieken worden onnodig grote hoeveelheden ruwe data geladen, waardoor netwerk- en opslagkosten de belangrijkste factor worden. Het typische probleem van datahiaten in aardobservatie- en rampendata compliceert de zaken verder: wolken, satellietbanen of ontbrekende tijdstempels creëren "datagaten". Als de workflow deze hiaten niet herkent, worden lege gebieden opgevraagd, ontbrekende data verkeerd geïnterpreteerd als "geen gebeurtenis" of wordt het opnieuw geprobeerd met andere parameters. Dit leidt tot extra I/O, een slechtere resultaatkwaliteit en over het algemeen minder bruikbaar signaal. In de pilot hebben we daarom specifiek besproken en geëxperimenteerd met geoptimaliseerde coderingen (bijv. compacte celrepresentaties, efficiënte backends, Parquet-paden voor schaarse data).Afhaal: AI-workflows lopen niet vast door het model zelf, maar door de input/output. Gestandaardiseerde reacties zijn noodzakelijk. schaarste-compatibel en bandbreedtebewustMet andere woorden, het knelpunt zit vaak niet in de modelinferentie, maar eerder in het feit dat de workflow te traag, te duur of te instabiel wordt doordat er te veel of te grote hoeveelheden data over het netwerk/de opslag moeten worden verplaatst – en er constant sprake is van ontbrekende/inconsistente dekking (schaarste, "datagaten"). 
3. "Stapelparadox" / topologische wrijving: subzones en overlappingen bij bepaalde openingen
   In DGGS/DGGRS-systemen wordt vaak impliciet aangenomen dat een zone op niveau L volledig en disjunct is opgedeeld door zijn subzones op niveau L+1 (bijv. "aperture-7 ⇒ 7 children"). In de praktijk kan deze aanname echter niet kloppen: afhankelijk van het rasterontwerp, de parameterisering en geometrische randgevallen kunnen "subzones" worden gedefinieerd als topologische bedekking (cellen die de ouderzone snijden/overlappen) in plaats van als exacte, niet-overlappende decomposities. Dit leidt tot situaties waarin aanzienlijk meer kandidaten dan verwacht worden geretourneerd en deze kandidaten elkaar ruimtelijk overlappen. Aanbeveling voor implementeerders: Clients dienen daarom geen subzones af te leiden via vaste cardinaliteiten of pure ID-rekenkunde, maar via duidelijk gedefinieerde bewerkingen en semantiek.
   • Maak expliciet onderscheid tussen partitie (disjunct, exact) en dekking (mogelijke overlappingen).
   • Voer aggregaties zodanig uit dat overlappingen niet tot dubbele tellingen leiden (bijvoorbeeld via gedefinieerde weeg-/intersectieregels of server-side aggregatie-eindpunten).
   • en gebruik/aanvulling van conformiteitstests die juist deze randgevallen (overlappingen, randgevallen) aan het licht brengen.

   Conclusie: Echte interoperabiliteit vereist niet alleen ID's, maar ook topologie- en uitlijningsregels die implementeerbaar en testbaar zijn.

4. Wrijving tussen register en metadata: hetzelfde label, verschillende parameters
   Een terugkerend patroon: labels lijken misschien op elkaar in verschillende bibliotheken, maar verschillen in details (parameters, datumveronderstellingen, ID-varianten/indexeringsschema's). Daarnaast, zone-ID's Soms zijn ze verschillend, ook al verwijzen ze naar dezelfde cellen.Afhaal: Wij hebben een nodig gezaghebbend OGC DGGS/DGGRS-register die parameters duidelijk beschrijft, varianten helder scheidt en kruisverwijzingen biedt. 

AI-gereedheid: wat moeten de OGC-normen nu opleveren?

De pilot heeft aangetoond dat "AI-klaar" niet betekent "chatinterface", maar eerder een interface en ecosysteem die betrouwbaar gebruik door agenten mogelijk maken – met duidelijke semantiek, machineleesbare beperkingen en reproduceerbare resultaten.

Om klaar te zijn voor AI is het volgende vereist:

1. Gereedschapsmogelijkheden: Eindpunten moeten zodanig worden beschreven dat agenten ze op een robuuste manier kunnen gebruiken.
2. Machineleesbare metadata: opvraagbare gegevens, limieten, kostenindicatoren, onzekerheden, resolutie/granulariteit.
3. Leuningen: Bescherming tegen overmatig ophalen van gegevens, onjuiste resolutiekeuze en onbeheersbare kosten.
4. Reproduceerbaarheid: Vragen en resultaten moeten reproduceerbaar zijn – vooral bij situatieanalyses.
5. Vertrouwen en veiligheid: Context, identiteit, herkomst, toegangsbeleid.

De discussie over de verdere ontwikkeling van OWS Context was hier bijzonder relevant: OWS Context kan dienen als basis voor het overdragen van een gemeenschappelijk operationeel beeld tussen organisaties, maar moet worden bijgewerkt om te voldoen aan de huidige eisen (services/workflows, dynamische gebeurtenissen, beveiliging/classificatie, AI-RAG/agent-pipelines).

Benchmarks en implementeerbaarheid: Waarom de "DGGRS-keuze" niet neutraal is.

Tijdens de implementatie van de verschillende DGGRS-systemen heb ik een belangrijk, praktisch punt benadrukt: DGGRS-implementaties gedragen zich niet identiek qua prestaties en efficiëntie. Benchmarks en optimalisaties (inclusief formaat/compressie) werden besproken in de pilot; daarbij werd onder andere aangegeven dat individuele systemen bij bepaalde bewerkingen aanzienlijk trager/sneller kunnen zijn.

Kernboodschap: Interoperabiliteit betekent niet dat alles even snel is, maar standaarden moeten het mogelijk maken om mogelijkheden, verwachte kosten en geschikte opties transparant te maken.

Routekaart: Zes concrete stappen die we uit de pilot hebben afgeleid

Uit de pilot kunnen zeer specifieke standaardiserings- en gemeenschapstaken worden afgeleid:

1. OGC DGGS/DGGRS-registerParameterisering, datumreferenties, indexeringsschema's, kruisverwijzingen.
2. H3 Beste praktijkDuidelijke richtlijnen voor de interpretatie van modellen/gegevens en de verwachtingen ten aanzien van de afstemming.
3. Betere querymechanismen: duidelijkere querymogelijkheden, robuustere patronen voor begrenzing/selectie/aggregatie; optionele "on-ramp" voor niet-DGGS-clients (bijv. een geometrie-eerst-verzoek dat aan de serverzijde wordt omgezet naar DGGS).
4. Tijdsrastervorming als een eersteklas onderwerpDGGS is niet zomaar "ruimte"; een ramp is altijd ruimte + tijd.
5. Operationaliseer COP + Vertrouwen/Herkomst (IPT): Ontwikkel OWS Context verder tot een machineleesbare container voor situatiebeelden, inclusief beveiliging/beleid/toegang/provenance.
6. Analytische uitbreidingenEen duidelijke catalogus van welke analyses op een gestandaardiseerde manier per cel beschikbaar moeten zijn (aggregatie, zonestatistieken, indexen, enz.).

Uitnodiging: Hoe u kunt bijdragen als implementeerder of lid

We willen de resultaten van de pilot met de gemeenschap delen en ze omzetten in prioritaire, implementeerbare bouwstenen.

Als u lid bent van de OGC:

• Doe mee aan de Agora-discussie op register/beste praktijken/opvraagbare gegevens.
• Deel de daadwerkelijke knelpunten die je bij de implementatie bent tegengekomen (inclusief screenshots/benchmarks, indien mogelijk).

Als u een implementeerder bent:

• Vergelijk uw parameterinstellingen met die van andere bibliotheken/servers.
• Geef feedback op de vraag: "Welke metadata heeft een agent nu echt nodig?"

Als u meehelpt bij het vormgeven van standaarden:

• Help mee met het definiëren van conformiteitstests die juist deze knelpunten aan het licht brengen.

Conclusie: “Echte wrijving, echte oplossing”

De pilot heeft aangetoond dat we dicht bij de overgang zijn van "AI voor geospatiale data" van demonstratieniveau naar betrouwbare, interoperabele praktijk – maar alleen als we de werkelijke knelpunten standaardiseren: registratie, uitlijning, compatibiliteit met sparse data, machineleesbare metadata, vertrouwen/context.

Dit is de echte kans: standaarden maken AI verantwoordelijk.

Wil je meewerken aan register-/best practices, de evolutie van de COP/OWS-context of AI-geschikte metadata? Neem dan contact met ons op.

Appendix A

DGGS versus DGGRS

Een DGGRS (Discrete Global Grid Reference System) is een compleet, operationeel ruimtelijk referentiesysteem dat drie componenten combineert:

1. DGGH (Discrete Global Grid Hierarchy): De hiërarchische indeling van het aardoppervlak in zones met opeenvolgende verfijningsniveaus.
2. ZIRS (Zone Identifier Reference System): Een systeem voor het uniek benoemen en adresseren van elke zone.
3. Deterministische ordening van subzones: een gestandaardiseerde volgorde voor het organiseren van subzones binnen hoofdzones, waardoor geoptimaliseerde gegevenscodering mogelijk wordt.

In essentie is een DGGRS een gebruiksklaar systeem voor het verwijzen naar en organiseren van geospatiale gegevens op een wereldwijd raster, terwijl een DGGS het bredere, geïntegreerde softwareframework is dat een of meer DGGRS-systemen kan implementeren, samen met kwantificeringsfuncties, zoekmogelijkheden en interoperabiliteitstools.