Du chat à la carte : comment DGGS et l’IA agentique transforment les données géographiques en bases de décision vérifiables.

Contexte : Pourquoi « GeoAI » échoue en l’absence de normes

Quand on parle aujourd'hui d'« IA + géospatial », beaucoup pensent d'abord à un chatbot capable de « décrire » des cartes. En pratique, cependant, les applications concrètes échouent rarement par manque de modèles – mais plutôt en raison de un manque d'interopérabilité, de traçabilité et de lisibilité par machine:

• Les données sont réparties entre différents services et formats.
• Les requêtes ne sont souvent pas « compatibles avec l'IA » (trop peu de métadonnées, trop peu de garde-fous, coûts/granularité imprécis).
• Les résultats sont difficiles se reproduire or audit – notamment dans les situations de crise où la confiance, la provenance, le contrôle d’accès et le contexte sont essentiels.

L'OGC Projet pilote AI-DGGS pour la gestion des catastrophes a abordé précisément cette question : non pas « l’IA comme démonstration », mais L'IA comme orchestrateur pour des géoservices interopérables – avec un accent particulier sur normes, faisabilité et frictions concrètes.

Ce que nous avons construit et démontré dans le pilote

Dans le projet pilote, nous avons utilisé DGGS (Systèmes de grilles mondiales discrètes) comme un « langage spatial » commun pour référencer et analyser de manière cohérente des données hétérogènes sur les catastrophes.

Idée centrale

Les cellules DGGS sont à l'IA géospatiale ce que les jetons sont au langage : stable, hiérarchique, lisible par machineCela facilite l'agrégation, les analyses multi-résolution et l'interaction de différentes sources de données.

Architecture en une phrase

Nous avons interconnecté plusieurs serveurs de données DGGS indépendants et plusieurs clients d'IA indépendants de manière à ce qu'ils se comportent comme un moteur d'analyse interopérable – complété par un Imagerie opératoire commune (COP) couche de contexte, de confiance et de partage de « ce qui s'applique, quand et à qui ».

Ce qui fonctionnait ensemble de manière interopérable (niveau élevé)

• Plusieurs implémentations DGGS/DGGRS (y compris H3, A5, diverses variantes ISEA, etc.)
• Implémentations multi-serveurs (différentes piles/fournisseurs)
• Flux de travail multi-clients IA/agents (requêtes basées sur des outils plutôt que sur des « coordonnées hallucinées »)
• Développement ultérieur du contexte COP/OWS en tant que mécanisme de transfert pour l'évaluation de la situation + sécurité/confiance/provenance

Pourquoi est-ce important ?

Parce que cela montre que le « raisonnement en IA » dans le domaine géospatial ne se développe pas principalement par l'entraînement des modèles, mais par… des interfaces standardisées de type outil, des métadonnées lisibles par machine et des chaînes de services reproductibles.

Les principaux constats : quatre points de friction que nous devons aborder spécifiquement

1. Frictions d'alignement géométrique : Différences de référence/modèle (H3 orthollique vs. WGS84)
   Un problème pratique majeur était le alignement géométrique Entre les systèmes largement utilisés, notamment lorsqu'un système DGGS (par exemple, basé sur des hypothèses orthorhombiques/sphériques) rencontre le système WGS84/ellipsoïdal, cela pose problème. En pratique, si les réponses du serveur ne décrivent pas clairement les paramètres sous-jacents, les clients doivent effectuer des calculs inverses, et c'est là que le bât blesse.Emporter: Nous avons besoin pratiques exemplaires claires et paramétrisation non ambiguë de sorte que « également nommé » signifie réellement « égal ».
2. Frictions liées aux performances et à la rareté des données : les données d’observation de la Terre à haute résolution sont souvent « rares ».
   Les procédures de gestion des catastrophes utilisent souvent des données de capteurs à haute résolution – et ces données sont clairseméDe vastes zones sans mesures, des lacunes spatiales et temporelles, et des géométries de passage variables constituent le problème principal. Il ne s'agit pas d'un cas marginal, mais de la norme. En pratique, cela se traduit par le scénario suivant : un flux de travail automatisé n'exécute pas une simple requête, mais procède de manière itérative : il demande d'abord des données sur l'étendue des inondations, puis des données démographiques, ensuite des données d'infrastructure, puis des données à plus haute résolution, et enfin des données provenant de différents moments. Cela génère rapidement des centaines, voire des milliers, d'appels API, souvent par petites tuiles. Les conséquences sont une accumulation de latences, l'activation des limitations de débit et une multiplication des tentatives, jusqu'à ce que l'agent soit bloqué dans une boucle « récupération → attente → nouvelle tentative » et ne puisse plus obtenir de résultat stable. De plus, un volume excessif de données est souvent transféré lorsque le client ne peut pas spécifier précisément la résolution requise, la zone d'investigation exacte ou les attributs appropriés. Au lieu de statistiques agrégées, des quantités inutilement importantes de données brutes sont chargées, ce qui rend les coûts de réseau et de stockage prépondérants. Le problème classique des lacunes dans les données d'observation de la Terre et les données de catastrophes complique encore la situation : les nuages, les orbites des satellites ou l'absence d'horodatage créent des « trous de données ». Si le flux de travail ne détecte pas ces lacunes, il interroge des zones vides, interprète à tort les données manquantes comme « absence d'événement » ou réessaie avec des paramètres différents. Cela entraîne des E/S supplémentaires, une qualité de résultat inférieure et un signal globalement moins exploitable. Dans le cadre du projet pilote, nous avons donc spécifiquement discuté et expérimenté avec encodages optimisés (par exemple, représentations cellulaires compactes, backends efficaces, chemins Parquet pour les données éparses).Emporter: Les flux de travail d'IA ne disparaissent pas à cause du modèle, mais à cause des entrées/sorties. Des réponses standardisées doivent être mises en place. compatible avec la parcimonie et soucieux de la bande passanteEn d'autres termes, le goulot d'étranglement n'est souvent pas l'inférence du modèle, mais plutôt le fait que le flux de travail devient trop lent, trop coûteux ou trop instable parce qu'il doit déplacer trop de données ou des données trop volumineuses sur le réseau/stockage – et rencontre constamment une couverture manquante/incohérente (rareté, « trous dans les données »). 
3. « Paradoxe de l’empilement » / friction topologique : sous-zones et chevauchements à certaines ouvertures
   Dans les systèmes DGGS/DGGRS, on suppose souvent implicitement qu'une zone de niveau L est complètement et disjointement partitionnée par ses sous-zones de niveau L+1 (par exemple, « ouverture-7 ⇒ 7 enfants »). En pratique, cependant, cette hypothèse peut s'avérer erronée : selon la conception de la grille, sa paramétrisation et les cas particuliers géométriques, les « sous-zones » peuvent être définies comme un recouvrement topologique (cellules qui intersectent/chevauchent la zone parente) plutôt que comme des décompositions exactes et non chevauchantes. Il en résulte des situations où un nombre de candidats significativement plus élevé que prévu est renvoyé, et ces candidats se chevauchent spatialement. Recommandation pour les développeurs : les clients ne doivent donc pas dériver les sous-zones via des cardinalités fixes ou une simple arithmétique d'identifiants, mais via des opérations et une sémantique clairement définies.
   • Distinguer explicitement entre partition (disjointe, exacte) et couverture (chevauchements possibles).
   • Effectuez les agrégations de manière à ce que les chevauchements n'entraînent pas de double comptage (par exemple, via des règles de pondération/d'intersection définies ou des points de terminaison d'agrégation côté serveur).
   • et des tests de conformité d'utilisation/de complément qui révèlent précisément ces cas limites (chevauchements, cas limites).

   Emporter: Une véritable interopérabilité exige non seulement des identifiants, mais aussi règles de topologie et d'alignement qui sont réalisables et testables.

4. Conflit entre registre et métadonnées : même étiquette, paramètres différents
   Un schéma récurrent : les étiquettes peuvent sembler similaires d’une bibliothèque à l’autre, mais différer dans les détails (paramètres, hypothèses de date, variantes d’identifiants/schémas d’indexation). De plus, identifiants de zone sont parfois différentes même si elles font référence aux « mêmes cellules ».Emporter: Nous avons besoin d'un Registre officiel OGC DGGS/DGGRS qui décrit clairement les paramètres, distingue clairement les variantes et fournit des références croisées. 

Préparation à l'IA : ce que les normes OGC doivent désormais fournir

Le projet pilote a démontré que « compatible avec l’IA » ne signifie pas « interface de chat », mais plutôt une interface et un écosystème permettant une utilisation fiable par des agents — avec une sémantique claire, des contraintes lisibles par machine et des résultats reproductibles.

La préparation à l'IA nécessite :

1. Capacité d'outillage : Les points de terminaison doivent être décrits de manière à permettre aux agents de les utiliser de façon fiable.
2. Métadonnées lisibles par machine : Données interrogeables, limites, indicateurs de coûts, incertitudes, résolution/granularité.
3. Garde-corps : Protection contre la surcharge de données, le choix d'une résolution incorrecte et les coûts incontrôlés.
4. Reproductibilité: Les requêtes et les résultats doivent être reproductibles – notamment pour les évaluations de situation.
5. Confiance et sécurité : Contexte, identité, provenance, politiques d'accès.

Le débat sur le développement ultérieur du contexte OWS était particulièrement pertinent ici : le contexte OWS peut servir de base au transfert d’un image opératoire commune entre les organisations, mais il doit être mis à jour pour répondre aux exigences actuelles (services/flux de travail, événements dynamiques, sécurité/classification, pipelines IA-RAG/agents).

Points de référence et faisabilité : pourquoi le « choix DGGRS » n’est pas neutre

J'ai mis en évidence un point important et pratique lors de la mise en œuvre des différentes implémentations DGGRS : implémentations DGGRS Nous ne se comporter à l'identique En termes de performances et d'efficacité, des points de référence et des optimisations (notamment en matière de format et de compression) ont été abordés lors du projet pilote ; il a notamment été souligné que les performances des différents systèmes peuvent varier considérablement selon les opérations.

Emporter: L'interopérabilité ne signifie pas que tout est aussi rapide, mais les normes devraient permettre de rendre capacités, coûts prévus et options appropriées transparent.

Feuille de route : Six étapes concrètes tirées du projet pilote

Des tâches de normalisation et communautaires très spécifiques peuvent être déduites du projet pilote :

1. Registre OGC DGGS/DGGRSParamétrage, références de dates, schémas d'indexation, références croisées.
2. H3 Meilleures pratiques: des directives claires sur l'interprétation du modèle/des données et les attentes en matière d'alignement.
3. Mécanismes de requête améliorés: requêtes plus claires, modèles plus robustes pour la délimitation/la sélection/l'agrégation ; « rampe » optionnelle pour les clients non-DGGS (par exemple, requête géométrique prioritaire qui se résout en DGGS côté serveur).
4. Le quadrillage temporel comme sujet de premier ordreDGGS ne se limite pas à « l’espace » ; une catastrophe est toujours espace + temps.
5. Opérationnalisation de COP + Confiance/Provenance (IPT): Développer davantage le contexte OWS en un conteneur d'image de situation lisible par machine incluant la sécurité/politique/accès/provenance.
6. Extensions analytiques: un catalogue clair des analyses qui devraient être disponibles de manière standardisée « cellule par cellule » (agrégation, statistiques zonales, indices, etc.).

Invitation : Comment vous pouvez contribuer en tant que développeur ou membre

Nous souhaitons partager les résultats du projet pilote avec la communauté et les transformer en éléments constitutifs prioritaires et applicables.

Si vous êtes membre de l'OGC :

• Impliquez-vous dans le Discussion maintenant sur le registre/les meilleures pratiques/les interrogations.
• Partagez les « frictions » réelles rencontrées lors de votre implémentation (y compris des captures d'écran/des benchmarks, si possible).

Si vous êtes un implémenteur :

• Comparez votre paramétrage avec celui d'autres bibliothèques/serveurs.
• Donnez votre avis sur : « De quelles métadonnées un agent a-t-il réellement besoin ? »

Si vous contribuez à l'élaboration des normes :

• Contribuez à définir des tests de conformité qui révèlent précisément ces frictions.

Conclusion : « Friction réelle, solution réelle »

Le projet pilote a démontré que nous sommes sur le point de faire passer l'« IA pour les données géospatiales » du stade de démonstration à la réalité. pratique fiable et interopérable—mais seulement si nous normalisons les véritables frictions : enregistrement, alignement, encodages compatibles avec la parcimonie, métadonnées lisibles par machine, confiance/contexte.

Voici la véritable opportunité : Les normes rendent l'IA responsable.

Si vous souhaitez travailler sur les registres/meilleures pratiques, l'évolution du contexte COP/OWS ou les métadonnées prêtes pour l'IA : Contactez-nous

Annexe A

DGGS vs DGGRS

Un DGGRS (Discrete Global Grid Reference System) est un système de référence spatiale complet et opérationnel combinant trois composantes :

1. DGGH (Hiérarchie de la grille globale discrète) : La tessellation hiérarchique de la surface terrestre en zones à des niveaux de raffinement successifs
2. ZIRS (Zone Identifier Reference System) : un système permettant de nommer et d'adresser chaque zone de manière unique.
3. Ordre déterministe des sous-zones : une séquence standardisée pour organiser les zones enfants au sein des zones parents, permettant un encodage de données optimisé.

En substance, un DGGRS est un système prêt à l'emploi pour référencer et organiser des données géospatiales sur une grille mondiale, tandis qu'un DGGS est le cadre logiciel intégré plus large qui peut implémenter un ou plusieurs DGGRS ainsi que des fonctions de quantification, des capacités de requête et des outils d'interopérabilité.