From chat to map: How DGGS + Agentic AI turn geodata into verifiable decision-making bases

Context: Why “GeoAI” fails without standards

When we say “AI + geospatial” today, many people first think of a chatbot that can “describe” maps. In practice, however, real-world applications rarely fail due to a lack of models – but rather due to a lack of interoperability, traceability, and machine readability:

• Data is distributed across different services and formats.
• Queries are often not “AI-enabled” (too little metadata, too few guardrails, unclear costs/granularity).
• Results are difficult to reproduce or audit – especially in crisis situations where trust, provenance, access control, and context are crucial.

The OGC AI-DGGS pilot project for disaster management addressed precisely this issue: not “AI as a demo,” but AI as an orchestrator for interoperable geoservices – with a clear focus on standards, implementability, and real-world frictions.

What we built and demonstrated in the pilot

In the pilot, we used DGGS (Discrete Global Grid Systems) as a common “spatial language” to consistently reference and analyze heterogeneous disaster data.

Core idea

DGGS cells are to geospatial AI what tokens are to language: stable, hierarchical, machine-readable. This facilitates aggregation, multi-resolution analyses, and the interaction of different data sources.

Architecture in a sentence

We have linked several independent DGGS data servers and several independent AI clients in such a way that they behave like an interoperable analysis engine – supplemented by a Common Operating Picture (COP) layer for context, trust, and sharing of “what applies when to whom.”

What ran together interoperably (high level)

• Multiple DGGS/DGGRS implementations (including H3, A5, various ISEA variants, etc.)
• Multiple server implementations (different stacks/providers)
• Multiple AI clients/agent-based workflows (tool-based queries instead of “hallucinated coordinates”)
• COP/OWS context further development as a transfer mechanism for situation assessment + security/trust/provenance

Why is this important?

Because it shows that “AI reasoning” in geospatial does not primarily scale through model training – but through standardized, tool-like interfaces, machine-readable metadata, and reproducible service chains.

The most important findings: Four frictions that we need to address specifically

1. Geometric alignment friction: Datum/model differences ( H3 orthallic vs. WGS84 )
   A key practical problem was the geometric alignment between widely used systems, especially when a DGGS world (e.g., orthallic/spherical assumptions) encounters WGS84/ellipsoidal expectations. In practice, this means that if server responses do not clearly describe the underlying parameters, clients have to “calculate backwards” – and that’s when it gets dangerous.Takeaway: We need clear best practices and unambiguous parameterization so that “equally named” really means “equal.”
2. Performance/sparsity friction: High-resolution EO data is often “sparse”
   Disaster workflows often use high-resolution sensor data – and this data is sparse: large areas without measurements, gaps in space and time, different pass geometries. This is not a marginal case, but the norm. In practice, this results in the following picture:An agentic workflow does not just execute a single query, but works iteratively: it first requests flood extent data, then population data, then infrastructure data, then higher resolution data, and finally data from several different points in time. This quickly results in hundreds or thousands of API calls, often in small tiles. The consequences are accumulating latencies, rate limits kicking in, and more and more retries until the agent gets stuck in a loop of “fetch → wait → retry” and can no longer achieve a stable result.In addition, too much data is often transferred when the client cannot precisely specify the required resolution, the exact area of investigation, or the appropriate attributes. Instead of aggregated statistics, unnecessarily large amounts of raw data are then loaded, making network and storage costs the dominant factor.The typical problem of data gaps in Earth observation and disaster data further complicates matters: clouds, satellite orbits, or missing time stamps create “data holes.” If the workflow does not recognize these gaps, it queries empty areas, misinterprets missing data as “no event,” or tries again with different parameters. This leads to additional I/O, poorer result quality, and less usable signal overall.In the pilot, we therefore specifically discussed and experimented with optimized encodings (e.g., compact cell representations, efficient backends, Parquet paths for sparse data).Takeaway: AI workflows do not die because of the model, but because of I/O. Standardized responses must be sparsity-compatible and bandwidth-conscious. In other words, the bottleneck is often not model inference, but rather that the workflow becomes too slow, too expensive, or too unstable because it has to move too much or too large data over the network/storage – and constantly encounters missing/inconsistent coverage (sparsity, “data holes”). 
3. “Stacking paradox” / topology friction: sub-zones and overlaps at certain apertures
   In DGGS/DGGRS systems, it is often implicitly assumed that a zone at level L is completely and disjointly partitioned by its subzones at level L+1 (e.g., “aperture-7 ⇒ 7 children”). In practice, however, this assumption can break down: depending on the grid design, parameterization, and geometric edge cases, “subzones” can be defined as topological covering (cells that intersect/overlap the parent zone) rather than as exact, non-overlapping decompositions. This leads to situations where significantly more candidates than expected are returned and these candidates overlap spatially.Implementer recommendation: Clients should therefore not derive subzones via fixed cardinalities or pure ID arithmetic, but via clearly defined operations and semantics:
   • Explicitly distinguish between partition (disjoint, exact) and cover (possible overlaps).
   • Perform aggregations in such a way that overlaps do not lead to double counting (e.g., via defined weighting/intersection rules or server-side aggregation endpoints).
   • and use/supplement conformance tests that reveal precisely these edge cases (overlaps, edge cases).

   Takeaway: True interoperability requires not only IDs, but also topology and alignment rules that are implementable and testable.

4. Registry/metadata friction: Same label, different parameters
   A recurring pattern: labels may appear similar across libraries, but differ in details (parameters, date assumptions, ID variants/indexing schemes). In addition, zone IDs are sometimes different even though they refer to the “same cells.”Takeaway: We need an authoritative OGC DGGS/DGGRS registry that clearly describes parameters, clearly separates variants, and provides cross-references. 

AI readiness: What OGC standards must now deliver

The pilot has shown that “AI-ready” does not mean “chat interface,” but rather an interface and ecosystem that reliably enable agentic use—with clear semantics, machine-readable constraints, and reproducible results.

AI readiness requires:

1. Tool-ability: Endpoints must be described in a way that allows agents to use them robustly.
2. Machine-readable metadata: queryables, limits, cost indicators, uncertainties, resolution/granularity.
3. Guardrails: Protection against overfetching, incorrect resolution selection, and uncontrolled costs.
4. Reproducibility: Queries and results must be reproducible – especially for situation assessments.
5. Trust & security: Context, identity, provenance, access policies.

The discussion on the further development of OWS Context was particularly relevant here: OWS Context can serve as a basis for transferring a common operating picture between organizations, but it must be updated to meet today’s requirements (services/workflows, dynamic events, security/classification, AI-RAG/agent pipelines).

Benchmarks & implementability: Why “DGGRS choice” is not neutral

I highlighted an important, practical point during the implementation of the various DGGRS: DGGRS implementations do not behave identically in terms of performance and efficiency. Benchmarks and optimizations (including format/compression) were discussed in the pilot; among other things, it was pointed out that individual systems can be significantly slower/faster in certain operations.

Takeaway: Interoperability does not mean that everything is equally fast – but standards should make it possible to make capabilities, expected costs, and suitable options transparent.

Roadmap: Six concrete steps we derive from the pilot

Very specific standardization and community tasks can be derived from the pilot:

1. OGC DGGS/DGGRS Registry: Parameterization, date references, indexing schemas, cross-reference.
2. H3 Best Practice: clear guidance on model/data interpretation and alignment expectations.
3. Better query mechanics: clearer queryables, more robust patterns for bounding/selection/aggregation; optional “on-ramp” for non-DGGS clients (e.g., geometry-first request that resolves to DGGS on the server side).
4. Temporal gridding as a first-class topic: DGGS is not just “space”; disaster is always space+time.
5. Operationalize COP + Trust/Provenance (IPT): Further develop OWS Context into a machine-readable situation picture container including security/policy/access/provenance.
6. Analytical Extensions: clear catalog of which analytics should be available in a standardized “cell-wise” manner (aggregation, zonal stats, indices, etc.).

Invitation: How you can contribute as an implementer or member

We want to bring the pilot results to the community and turn them into prioritized, implementable building blocks.

If you are an OGC member:

• Get involved in the Agora discussion on registry/best practice/queryables.
• Share real-world “frictions” from your implementation (including screenshots/benchmarks, if possible).

If you are an implementer:

• Check your parameterization against other libraries/servers.
• Provide feedback on: “What metadata does an agent really need?”

If you help shape standards:

• Help define conformance tests that reveal precisely these frictions.

Conclusion: “Real Friction, Real Fix”

The pilot has shown that we are close to bringing “AI for geospatial data” from the demo level to reliable, interoperable practice—but only if we standardize the real frictions: registry, alignment, sparsity-compatible encodings, machine-readable metadata, trust/context.

This is the real opportunity: standards make AI accountable.

If you want to work on registry/best practices, COP/OWS context evolution, or AI-ready metadata: Get in Touch

Appendix A

DGGS vs DGGRS

A DGGRS (Discrete Global Grid Reference System) is a complete, operational spatial reference system combining three components:

1. DGGH (Discrete Global Grid Hierarchy): The hierarchical tessellation of Earth’s surface into zones at successive refinement levels
2. ZIRS (Zone Identifier Reference System): A scheme for uniquely naming and addressing each zone
3. Deterministic sub-zone ordering: A standardized sequence for organizing child zones within parent zones, enabling optimized data encoding

In essence, a DGGRS is a ready-to-use system for referencing and organizing geospatial data on a global grid, whereas a DGGS is the broader integrated software framework that may implement one or more DGGRS alongside quantization functions, query capabilities, and interoperability tools.