1.1.  Operational Challenges in Modern Disaster Management

Flood events and other disasters are becoming increasingly frequent and severe, demanding robust and timely planning responses. However, in the wake of a crisis, decision-makers are often “data-rich but information-poor.” This pilot identifies this barrier as the “Discovery Gap”—the disconnect between the vast proliferation of Earth Observation (EO) data and the ability of responders to extract instant, actionable answers to plain-language questions.

Despite the abundance of geospatial data, current systems remain fragmented. Data arrives in incompatible formats and different coordinate systems, processed through tools that rarely interoperate. This lack of uniform frameworks restricts cross-agency coordination and slows the adoption of intelligent, scenario-based decision support systems.

This Report addresses these challenges by integrating OGC-compliant DGGS services, AI modeling pipelines, and explainable analytics. By establishing a shared Common Operating Picture (COP), the pilot provides a unified framework for dynamic disaster risk assessment and scenario communication.

1.1.1.  Red River Basin: A Historical Testbed for Flood Modeling

The Red River Basin provides a high-consequence geographic context for testing AI-DGGS-enabled flood risk assessment. Its unique northward flow, flat topography, and climatic conditions make it prone to recurrent large-scale flooding that challenges communities on both sides of the Canada–US border.

To anchor the pilot in real-world conditions, the participants simulated an operational experiment modeled after the most notable historical events in the basin.

• 1826 Flood – The largest known flood on record, inundating vast portions of the basin.

• 1950 Flood – Displaced over 100,000 people in Winnipeg and prompted major projects like the Red River Floodway.

• 1997 “Flood of the Century” – Required large-scale emergency measures and record-breaking international cooperation.

• 2011 Flood – Characterized by widespread overland flooding and prolonged high water levels.

• 2022 Flood — Severe flooding across the province resulting from the cumulative effects of multiple storms. Also a wide range of high quality data was collected from recently modernized systems. NASA Report Manitoba Province Operation Report

Figure 1 — An aerial photo showing flooding in the St. Vital area, 1950 (Source: Government of Manitoba).

By integrating DGGS for consistent spatial partitioning and AI for predictive analytics, the pilot simulates scenarios similar to these historic events. The goal is to improve decision-making capabilities for civil protection agencies by providing a “Geospatial Brain” that understands the interplay between hydrology, infrastructure, and socio-demographic vulnerability.

1.2.  The Case for DGGS: A Digital-First Spatial Foundation

Discrete Global Grid Systems (DGGS) offer more than a new way to partition the Earth; they provide a “Digital Fabric” designed for the realities of modern geospatial integration. DGGS supply a globally consistent spatial framework that allows observations, models, and sensor data to be combined at multiple scales without the distortions or “Raster-Vector Divide” inherent in traditional map projections.

DGGS enable uniform, multiscale indexing where every location on Earth is represented by a unique cell identifier. In the context of AI, this serves as a Spatial Tokenizer. By indexing authoritative data to specific grid cells, Artificial Intelligence can access location-indexed facts rather than relying solely on pre-trained knowledge.

Furthermore, DGGS provides a solution to “Scale Blindness”—the tendency for general-purpose AI to request computationally impossible amounts of data (e.g., asking for a 1-meter map of an entire province). By utilizing the grid’s hierarchical structure, the pilot enables an Orchestration Layer that provides progressive refinement, ensuring that AI responses are grounded, efficient, and mathematically accurate.

Ultimately, DGGS provide the foundation needed to establish a Common Operating Picture (COP) across diverse stakeholders. This uniform structure supports cross-agency collaboration and standardized reporting, ensuring that the “Server Backbone” and the “Intelligence Frontier” work together as a single, interoperable engine.

1.3.  Participants and Deliverables

The AI-DGGS Pilot brought together a diverse group of OGC members and industry partners to develop a distributed environment for disaster management. The following table summarizes the key participants and their primary contributions.

The project was executed in four primary phases:

2.1.  The Case for DGGS: A World Model Paradigm Shift

To understand the architecture of this pilot, it is necessary to recognize that DGGS represents a fundamental paradigm shift in geospatial representation. Rather than viewing the Earth as a collection of static layers—an approach rooted in the legacy of paper maps and carried over into modern digital systems—DGGS serves as the most sophisticated World Model currently available, transitioning from traditional imagery to a structured global fabric (see Figure 2).

Figure 2 — The DGGS World Model paradigm shift: transitioning from legacy layers to a structured global fabric (courtesy of GeoInsight).

As a world model, DGGS delivers a structure that is consistent, readable, and analyzable by both humans and machines. As detailed by Jendryke in Annex B, DGGS moves away from a purely data-centric approach to provide a system of containers that can be filled with diverse data types. By flipping the traditional layer-based approach on its head, DGGS offers several critical advantages for disaster management.

The convergence of DGGS and multi-source data results in a “digital fingerprint” for every zone on Earth. Within the context of this pilot, these are referred to as Spatial Tokens. As illustrated in Figure B.1, these tokens—machine-readable packages of localized facts—serve as the primary ingredient for the Intelligence Frontier, enabling GeoAI to reason across multiple variables within a unified spatial context.

2.2.  DGGS-centric System Design

The pilot architecture follows a distributed, modular design where data ingestion, spatial quantization, and analytical modeling are decoupled from user interaction. This design ensures that heavy geospatial processing occurs close to the data source (the Backbone), while AI agents focus on reasoning and orchestration.

The system flow is categorized into three primary phases.

Figure 3 — AI-DGGS Pilot Architecture: Logic and Components

2.3.  The Foundational Stack (Server Backbone)

The architecture is built upon a set of open-source libraries that provide low-level DGGS abstractions and interoperability frameworks.

For a detailed breakdown of library features, git repositories, and supported bindings, see Annex D.

2.4.  Functional Analysis Capabilities

DGGS servers in the pilot expose standardized capabilities aligned with OGC API – DGGS. These operations allow AI agents to navigate the grid and retrieve evidence.

For specific HTTP request/response examples and API endpoint walkthroughs, see Annex E.

2.5.  The Spatial Tokenizer: Data Models and Encodings

To facilitate AI ingestion, geography must be converted into discrete, machine-readable indices. The pilot explored three primary encoding styles for Spatial Tokens.

The proposed Zarr metadata attribute schema and draft specifications are documented in Annex F.

2.6.  The Integration Glue: Intelligent COP Schema

The Common Operating Picture (COP) serves as the “Integration Glue” of the pilot, evolving the OGC OWS Context Standard (12-080r2) into a machine-readable JSON-LD framework that aligns situational awareness for both human operators and AI agents. By replacing traditional coordinate bounding boxes with DGGS Zone Identifiers (ZIRS), the schema allows Areas of Interest (AOI) to be defined as discrete sets of grid cells, enabling spatially consistent, multi-resolution views of the same geographic extent regardless of the underlying coordinate reference system.

The inclusion of Identity, Provenance, and Trust (IPT) metadata, contributed by 4113 Engineering, ensures operational reliability by embedding verifiable digital signatures, security classifications, and chain-of-custody information directly into every data layer. This structured context acts as the primary knowledge base for Retrieval-Augmented Generation (RAG), providing the “Spatial Conscience” required for AI agents to generate natural-language summaries that are strictly anchored in “Grid-Truth” and authoritative sensor data.

To maintain operational continuity, a QGIS COP Plugin was developed that serves as a bridge from legacy workflows, allowing desktop GIS analysts to export their layouts directly as AI-ready COP packages complete with DGGS grid references and IPT metadata. For the detailed technical specification of the COP schema extensions, implementation notes on the QGIS Plugin, and example JSON-LD instances, refer to Annex X.

3.1.  Overview: Giving AI a “Geospatial Brain”

The core objective of the AI-DGGS Pilot was to demonstrate how Artificial Intelligence can interpret a natural hazard crisis as easily as it interprets text. By using DGGS as a common “Digital Fabric,” the pilot moved beyond simple natural-language summarization toward Geospatial Reasoning—the ability for an AI system to independently devise an analytical plan, execute multi-step workflows across federated servers, and interpret results as actionable intelligence.

A key takeaway from the pilot project is that DGGS services and Large Language Models (LLMs) are not inherently compatible. DGGS zone identifiers and index-based query responses are optimized for machine efficiency, but they are not directly interpretable or analyzable by LLMs in a meaningful way. As a result, an orchestration layer is required to mediate both user requests and system responses between the LLM and DGGS services. This mediation was essential for enabling multi-step reasoning, cross-layer analysis, and explainable outputs, effectively bridging the gap between spatial indexing systems and language-based reasoning systems.

To achieve this, the pilot established an Orchestration Layer that acts as the “Spatial Conscience” of the Large Language Model (LLM), reconciling high-level human intent with the physical realities and computational limits of geospatial data. Beyond syntactic translation, the orchestration layer also provides semantic grounding by mapping DGGS zones to real-world geographic features, administrative units, and domain concepts. This enables the LLM to reason over spatial results in context (e.g., populations, infrastructure, or risk zones) rather than opaque index values, which is critical for explainable and decision-support-oriented applications.

In practical terms, this orchestration layer is where the pilot’s key AI Frontier Enablers converge: standardized actionability, trustworthy context, scale-aware execution, and machine-interpretable semantics.

3.2.  Model Context Protocol (MCP): The “Action Protocol”

A critical design choice in the pilot was the adoption of the Model Context Protocol (MCP). This protocol standardizes how AI agents interact with OGC API servers, transforming static data endpoints into a Self-Describing Infrastructure.

Enabler: Actionability / Tool-use interoperability. MCP turns APIs into callable tools the agent can safely and consistently execute.

3.3.  The Metadata Discovery Gap

While the Model Context Protocol (MCP) successfully standardizes the “Action” layer, the pilot identified a significant Semantic Gap in current OGC API – DGGS implementations.

Enabler: AI-ready semantics. Agentic autonomy depends not only on calling endpoints, but on understanding what the fields mean and how they were derived.

As noted by CS Group (D123), the lack of descriptive metadata regarding field types, unit semantics, and quantization methods represents a primary barrier to agentic autonomy.

Without “AI-Ready” metadata, an agent can discover that a collection exists but cannot independently determine if the data (e.g., a “population” field) represents an absolute count, a density index, or a temporal average. To achieve true “Generic Discovery,” infrastructure must move toward a Self-Describing model where the meaning and quality of data are machine-readable.

3.4.  Retrieval-Augmented Generation (RAG): The “Context Engine”

To prevent “AI Hallucinations,” the pilot implemented Retrieval-Augmented Generation (RAG) anchored in “Grid-Truth.”

Enabler: Trustworthy context / auditable grounding. DGGS provides stable identifiers (“spatial tokens”) that constrain generation to verifiable facts.

In this framework, the DGGS grid serves as the Spatial Tokenizer, providing a stable set of identifiers that the AI uses to access facts.

3.5.  Curing “Scale Blindness” through Progressive Refinement

One of the most significant findings of the pilot was the identification of “Scale Blindness” in general-purpose AI. Without a spatial intermediary, an AI might request a 1-meter resolution map of an entire country, inadvertently launching a “Resource Depletion Attack” on emergency servers.

Enabler: Scale-aware execution / safe-by-design efficiency. DGGS hierarchy allows the agent to reason across levels and “pay for resolution only when needed.”

The DGGS Hierarchy provided the solution.

3.6.  Semantic Reasoning and Cascading Risk Analysis

By integrating DGGS with Spatial Knowledge Graphs (SKGs), specifically demonstrated by TerraFrame, the pilot enabled AI to move beyond simple keyword matching to understand real-world relationships between objects.

Enabler: Semantic reasoning / impact propagation. SKGs let the agent infer dependencies and second-order effects, not just overlay layers.

3.7.  Participant Implementations (Intelligence Frontier)

The following contributors developed the agentic clients that define the Intelligence Frontier, each operationalizing one or more of the pilot’s core enablers (actionability, grounding, scale-awareness, semantics, and cascading reasoning).

4.1.  Overview: Reconciling Theory with Reality

The OGC DGGS Standard provides a powerful blueprint for global spatial analytics; however, operationalizing this framework in high-stakes disaster scenarios reveals critical “Implementation Gaps.” The pilot identified six technical frictions where theoretical standards meet the practical constraints of bandwidth, mathematical precision, and AI reasoning. By documenting and resolving these frictions, the pilot establishes a path toward Geospatial Grounding: ensuring that an autonomous agent receives a mathematically identical and scientifically traceable response from any server in a federated network, regardless of the underlying implementation.

4.2.  Friction 1: Geometric Alignment (Spherical vs. Ellipsoidal Models)

The Problem: A fundamental friction exists between widely used grid systems and standard geospatial reference frames. Grids like H3 were originally designed using authalic spherical models to simplify calculations (see also Annex Q), whereas modern remote sensing and positioning infrastructure rely on the WGS84 ellipsoidal model. When mapping high-resolution data onto these grids without proper correction, small mathematical deviations occur. In a disaster scenario, these errors can misalign a flood risk zone by several meters, potentially mapping a life-threatening hazard to the wrong physical property or infrastructure asset.

The Integration Fix:

Outcome: This mathematical bridge ensures that AI-generated risk maps remain spatially consistent with ellipsoidal geodetic reference frames used by modern positioning and remote sensing systems. By carefully reconciling spherical grid abstractions with ellipsoid-based coordinate systems, the pilot enabled accurate overlay of DGGS-derived analytics with legacy GIS infrastructure and high-precision GNSS observations.

4.3.  Friction 2: Sparse Data and Storage Bloat (The “Data Hole” Problem)

The Problem: High-resolution satellite data, such as RCM radar imagery, is frequently “sparse,” containing large empty gaps where the sensor did not pass or where no significant signal was detected. Traditional web formats often treat these empty spaces as “heavy” data, resulting in bloated, uncompressed files. During an active crisis, these oversized files lead to bandwidth saturation and slow map response times, making it difficult for responders to access critical information on mobile devices in areas with degraded network connectivity.

The Performance Fix:

Outcome: These optimizations allow for near-instant delivery of flood-risk summaries to the field. Eliminating the “sparse data penalty,” the pilot proved that DGGS can efficiently handle massive satellite archives while maintaining the high-speed transmission required for real-time emergency response.

4.4.  Friction 3: The Stacking Paradox (Non-Nested Hierarchies)

The Problem: In Aperture 7 grids, a parent hexagon does not perfectly contain its seven “logical” children. This lack of perfect nesting creates a “Stacking Paradox” where, at every level of refinement, some child cells extend outside the parent boundary while neighboring children from adjacent parents bleed into it. If a system only counts the logical 7 children during data aggregation, it inadvertently introduces a significant statistical error by ignoring the actual spatial overlap of the grid.

The Accuracy Fix:

Outcome: Accounting for the geometric reality of grid overlaps rather than just the logical hierarchy, the pilot ensured that risk statistics and population counts are calculated over the correct area. This eliminates the 6.5% error margin that would otherwise degrade the reliability of multi-scale modeling.

4.5.  Friction 4: Cross-Platform Integrity (Logic and Logic Drift)

The Problem: For disaster management tools to be effective, they must produce identical results across a federated ecosystem—from high-performance cloud servers to a responder’s field tablet. Historically, grid mathematics and Zone ID generation have been implemented inconsistently across different programming languages (e.g., Python, Java, and C++). These subtle differences in implementation lead to “logic drift,” where the same coordinate might resolve to two different grid cells depending on the software used, destroying the trust required for a Common Operating Picture.

The Interoperability Fix:

Outcome: Responders and decision-makers can trust that the high-speed grid data visualized in a web browser is mathematically identical to the data analyzed on a central server. This cross-platform integrity is essential for maintaining a single, auditable version of the truth during a distributed disaster response.

4.6.  Friction 5: Spatial Temporal Resolution and Range Queries

The Problem: While DGGS excels as a global multi-resolution index, localized disaster management requires sub-meter spatial detail and high-cadence temporal modeling. Moving from modest resolutions, such as 100-meter cells, to sub-meter modeling creates an “exponential explosion” in the number of grid zones. During pilot testing, it was found that a single request for a hexagonal parent zone at a relative depth of 8 can return approximately 5.7 million sub-zones. Disseminating raw data at this level of detail through traditional API responses is practically impossible, as payloads can exceed 100MB per tile, leading to bandwidth saturation and system timeouts during active crises. Another aspect is temporal resolution. Current DGGS implementations often lack native support for 4D range queries (XYZT). While CQL2 can filter by time attributes, parsing these irregular time-steps is computationally expensive when an AI agent needs to query specific slices of a river’s crest across thousands of increments, such as days, hours, or minutes.

The Scalability Fix:

Outcome: Given these adaptations, DGGS can be used to support the high spatial and temporal resolutions needed for localized flood risk assessment. By serving as an indexing layer for 4D data cubes, DGGS enables AI agents to discover and reason across high-resolution datasets without being restricted by API transport limits.

4.7.  Friction 6: The Interpretation Gap (Contextual Blindness)

The Problem: A significant hurdle identified during the pilot was the “Semantic Gap” between raw grid values and AI reasoning. While AI agents are proficient at retrieving numerical cell values, they suffer from “Contextual Blindness” regarding the underlying mathematical and scientific provenance of those numbers. For example, if an agent retrieves a value of “12.5,” it cannot natively distinguish if that represents an area-weighted Mean (flood intensity) or a cumulative Sum (total population). Furthermore, slight variations in how different quantization methods—such as K-Nearest Neighbor versus bilinear interpolation—associate data to zones can lead to inconsistent results. Without explicit machine-readable metadata regarding units and aggregation methods, AI agents risk applying incorrect scientific models, leading to “geospatial hallucinations” and unreliable insights.

The Provenance Fix:

Outcome: Making the grid values self-describing, the pilot ensured that AI-generated disaster insights are scientifically accurate and traceable. This metadata-heavy approach allows autonomous agents to safely perform multi-source integration, ensuring that all data used in a Common Operating Picture is “fit-for-purpose” and auditable.

4.8.  Summary of Implementation Challenges

The following table maps the identified frictions to the specific technical strategies deployed to resolve them:

5.1.  Overview of the Distributed Pilot Environment

The AI-DGGS Pilot established a live, federated environment connecting six data servers (The Backbone) and four AI-enabled clients (The Frontier). This section provides a summary of the implementation roles and outcomes for each participant. For detailed technical configurations and endpoint specifications, refer to the respective annexes of each participant.

5.2.  The AI-DGGS Pilot Hub

The central landing page provides a narrative walkthrough of the pilot’s mission, the “Discovery Gap” challenge, and the final results.

5.3.  The Server Backbone (DGGS APIs)

The following implementations provided the OGC API – DGGS infrastructure and raw data streams required for the flood risk scenarios.

5.3.3.  GeoInsight — The Performance Engineers (D122)

GeoInsight provided a high-concurrency, Rust-based implementation focused on cloud-native efficiency and the transformation of “Big Geodata” into machine-readable Spatial Tokens.

• Key Outcome: Championed the “Cloud Native Pointer” architecture, utilizing DuckDB and S3 for near-instant data retrieval, proving that massive datasets can be served without the overhead of upfront transformation storage.

• Website Link: GeoInsight Website Detail

• Full Technical Detail: See Annex I.

GeoInsight’s mission within the pilot was to unlock global-scale GeoAI by turning fragmented geospatial information into harmonized, AI-ready “digital fingerprints.” Their implementation developed a Spatial Tokenizer designed to produce analysis-ready data by partitioning the Earth into stable, hierarchical cells that act as spatial keys. By aggregating heterogeneous sources—such as satellite imagery, climate indicators, and infrastructure data—into these zones, the system transforms continuous geography into discrete Spatial Tokens that AI models can analyze more efficiently than traditional coordinates.

The implementation follows a grid-agnostic, “Any Data, Any Grid” philosophy. Built on a high-performance Rust backend, the server uses the GeoPlegma library for grid generation and DuckDB for managing metadata and lightweight analytical queries. This hybrid approach allows the API to federate data from diverse sources while maintaining consistent access through standardized OGC API – DGGS endpoints. During the pilot, GeoInsight demonstrated how to serve massive datasets without bloating the grid by pointing to optimized storage formats like Parquet and S3, ensuring that responders can access grounded facts in active crisis environments.

Figure 4 — GeoInsight Spatial Tokenizer: From Fragmented Data to Integrated Spatial Tokens

• Technical Highlights

  • Performance Engineering: Utilized Rust and DuckDB to achieve near-instant response times for on-the-fly quantization of Cloud Optimized GeoTIFFs (COGs).

  • Grid Agnostic: Supports consistent analysis across multiple DGGRSs including H3, ISEA3H, ISEA9R, IVEA3H, IVEA9R, RTEA9R, and IGEO7.

  • Scalable Backends: Validated a stable caching layer utilizing Parquet to reduce recomputation costs and enable the efficient re-use of AI-ready outputs.

5.3.4.  GeoLynx — The Open-Source Innovators (D121)

GeoLynx developed the core pydggsapi components, providing foundational tools for the Python data science community to interact with Discrete Global Grid Systems.

• Key Outcome: Demonstrated successful inter-DGGRS conversion between IGEO7 and H3 at runtime, proving that data storage can be decoupled from client-specific grid requirements.

• Website Link: GeoLynx Website Detail

• Full Technical Detail: See Annex J.

GeoLynx, in collaboration with the Landscape Geoinformatics Lab (University of Tartu) and CRIM, developed pydggsapi, an open-source Python-based web API designed to provide an easy-to-use discovery service for DGGS data. Built on the high-performance FastAPI framework, the implementation serves as a primary middleware for the Python geospatial ecosystem, wrapping complex grid libraries such as DGGRID and DGGAL into standardized OGC API endpoints.

The implementation champion’s a modular “Provider” architecture, allowing for a “plug-and-play” approach to different grid systems (H3, IGEO7, HEALPix, etc.) and storage backends. By supporting both database-driven (ClickHouse) and cloud-native file formats (Zarr, Parquet), GeoLynx demonstrated how large-scale research datasets can be made immediately analysis-ready. A unique feature of this implementation is the Mapbox Vector Tiles API, which allows for the seamless visualization of grid data in traditional GIS software like QGIS, bridging the gap between cell-based spatial tokens and standard mapping tools.

Figure 5 — GeoLynx pydggsapi: Modular Architecture for Grids and Storage

• Technical Highlights

  • Interoperability: Enabled AI clients to navigate hierarchies across diverse reference systems through a unified spatial language.

  • Scalable Backends: Validated the use of chunked, file-based storage (Zarr/Parquet) for high-performance access to sparse satellite data.

  • Grid Resampling: Successfully executed experimental on-the-fly conversion from IGEO7 to H3, allowing clients to request data in their preferred grid regardless of the native storage format.

5.3.6.  Safe Software — The Workflow Orchestrators (D106)

Safe Software utilized the FME Data Virtualization Platform to serve DGGS data via no-code automation, acting as the “universal translator” between legacy geospatial data and grid-native AI reasoning.

• Key Outcome: Validated that existing enterprise ETL platforms can be adapted to OGC DGGS standards without custom low-level coding.

• Website Link: Safe Website Detail

• Full Technical Detail: See Annex L.

Safe Software’s implementation demonstrates the feasibility of serving DGGS via no-code workflow orchestration. By leveraging the FME (Feature Manipulation Engine) platform and the DGGAL open-source library from Ecere, they created a suite of custom transformers that perform grid quantization, cell indexing, and spatiotemporal filtering. FME Data Virtualization allows for the rapid deployment of REST services such as OGC APIs by leveraging OpenAPI service descriptions. This architecture allows organizations to ingest high-volume datasets—such as the Manitoba DEM, climate model data cubes, and daily flood models—and expose them as compliant OGC API – DGGS endpoints with minimal integration friction. These custom transformers were published on FME Hub and are available to anyone who wants to work with DGGS from within FME workflows. This DGGAL based service includes support for: GNOSISGrid, ISEA9R, ISEA3H, IVEA9R, IVEA3H, RTEA9R, RTEA3H, rHEALPix grid reference systems.

The DGGS service is powered by FME Flow hosted on AWS, and supports the dynamic re-quantization of features into multiple resolutions. During the pilot, this capability was utilized to drive the Flood Impact Index (FII) and provide the AI-clients with ground truthed data streams. Through FME Flow, the implementation successfully delivered grid zone discovery, metadata access, and geometry delivery in DGGSJSON, GeoJSON and GeoTIFF formats, ensuring that the “Server Backbone” remains accessible to both human analysts and autonomous AI agents.

Figure 6 — FME Data Inspector Test Client viewing FME DGGS Service for Current Flood Level > 1 metre, Zoom Level 10

• Technical Highlights

  • Compliance: Full implementation of Draft OGC API – DGGS for zone discovery and data retrieval.

  • Interoperability:

    • Enabled AI clients to perform complex spatial/temporal and CQL2 attribute queries (e.g., filtering zones where flood depth > 1.5m).

    • Supported access to and quantization for a variety of source data streams including elevation, climate projections and flood model scenarios.

    • Supported AI clients such those from Hartis and Terraframe. Terraframe’s client leveraged Spatial Knowledge Graphs (SKG) which allowed it to identify cascading impacts where flooded zones compromised road or power networks. In this way the downstream effects could be assessed in terms of cumulative impacts.

  • Automation: Developed a repeatable pipeline that converts traditional vector and raster data into machine-readable Spatial Tokens on-the-fly.

5.4.  The Intelligence Frontier (AI Clients)

The following participants developed the agentic reasoning and visualization tools that consumed the DGGS data streams.

5.4.1.  Compusult — The UX Pioneers (D103)

Compusult developed the primary React-based chatbot, focusing on the “Chat-to-Map” user experience.

• Key Outcome: Successfully demonstrated natural-language geolocation and automated grid-cell rendering.

• Website Link: Compusult Website Detail

• Full Technical Detail: See Annex M.

For this pilot project, Compusult has developed an AI-enabled DGGS client to query and visualize data from OGC API – DGGS. The DGGS client is provided as a web-based application, and supports interoperability with independent DGGS endpoints. It demonstrates how DGGS, using OGC standards-based approaches, can support analysis of geospatial and statistical data to inform emergency management decision making.

Figure 7 — Compusult AI-Client Interface

The client implements a map viewer for visualization of geospatial data retrieved from DGGS API endpoints. The user interface itself is written using React, and the technology used for the map view is based upon the open-source JavaScript library, OpenLayers. The map view provides data visualization, situational awareness, and generation of a common operating picture. The client supports the integration of different forms of geospatial and statistical information using interoperable, OGC standards-based approaches.

The backend is composed of three services.

• Chat: An API used by the frontend chat interface for sending and receiving chat messages.

• LLM: An Instance of Ollama running the qwen3 LLM.

• Tools: An API used as an interface to the LLM and other external services such as the Nominatim geocoder, and the OGC API DGGS endpoints containing the desired data.

The Chat and Tool services are written using Python and use FastAPI as the web framework. The provided client implements a chat-based interface that uses AI/ML to generate DGGS-formatted API requests and display the results in the map view.

During this pilot, Compusult successfully developed a DGGS-aware GenAI chatbot prototype deployed in a microservices architecture.

Achieved functionality during this pilot included the following.

• Development of an LLM based chat API;

• Ability to use AI to generate DGGS zone queries and zone data queries from a user-entered natural language text query;

• Rendering of DGGS zone data in GeoTIFF and GeoJSON formats in a map view;

• Support for several different DGGRSes, including H3, HEALPix, and Icosahedral Equal-Area projections;

• Interoperability experiments with at least two other participants;

• Use of AI to identify applicable data collections and filter attributes in user-entered queries; and

• Ability to filter on queryable parameters and search results using OGC Common Query Language (CQL2) expressions.