Cartographie SIG : l'impact des données en temps réel

Cartographie SIG: l’impact des données en temps réel

Ce délai est rarement visible à l’écran. Il devient pourtant déterminant dès qu’une donnée doit servir à implanter, alerter, suivre un engin ou déclencher une intervention.

La cartographie SIG dynamique ne remplace pas la cartographie classique. Elle change son régime de fonctionnement. Une couche n’est plus une photographie contrôlée à une date donnée: elle devient un flux de positions, d’observations et d’états dont la qualité varie à chaque événement. Le système d’information géographique doit alors gérer trois contraintes simultanées: la cohérence spatiale, la cohérence temporelle et la traçabilité de la source.

Le point dur n’est pas l’affichage d’un point mobile. C’est la capacité à décider si ce point est exploitable.

Un flux temps réel n’est pas un simple fond de carte qui bouge

Les données géospatiales temps réel sont émises par des capteurs, des récepteurs GNSS, des véhicules, des équipements connectés ou des applications terrain. Elles deviennent disponibles peu après leur collecte. Cette définition impose une nuance: « peu après » ne signifie ni immédiat ni constant.

Dans une exploitation topographique ou SIG, la chaîne minimale comprend:

• une acquisition avec une position, une date, une heure, un identifiant et des attributs;
• une transmission par réseau cellulaire, radio, Wi-Fi ou liaison spécialisée;
• une ingestion dans une plateforme de traitement;
• une normalisation des coordonnées, de l’horodatage et du schéma attributaire;
• une analyse spatiale ou métier;
• une diffusion dans une couche web, une application terrain ou un tableau de bord.

Chaque maillon peut dégrader le résultat. Une antenne mal dégagée produit du multipath. Un récepteur GNSS bascule de solution fixée à flottante. Une application stocke une date locale sans fuseau explicite. Une passerelle MQTT conserve un événement en attente. Un moteur SIG interprète la coordonnée dans le mauvais système de référence. La carte continue pourtant d’afficher un point. C’est précisément le problème.

Une donnée temps réel ne vaut pas par sa vitesse d’affichage. Elle vaut par la conservation de son horodatage, de son identifiant et de son niveau de qualité.

L’évolution de la cartographie numérique pousse donc les logiciels SIG à traiter la donnée comme un objet mesuré, non comme une simple géométrie. Une position doit être accompagnée de ses conditions d’acquisition: méthode de positionnement, âge des corrections, précision estimée, état de la solution, référentiel de coordonnées et éventuellement orientation inertielle.

Sans ces attributs, la dynamique masque l’incertitude au lieu de la mesurer.

Architecture des flux: streaming et interrogation périodique ne répondent pas au même besoin

Un logiciel de cartographie SIG peut alimenter une couche de deux manières. La première consiste à maintenir une connexion active et à traiter les événements dès leur émission. C’est le streaming. La seconde consiste à interroger une source à échéance fixe. C’est l’interrogation périodique.

Les deux mécanismes sont souvent confondus parce qu’ils produisent une carte animée. Leur comportement réseau, leur charge de traitement et leur tolérance aux coupures sont pourtant différents.

Dans les plateformes capables de gérer ces flux, une interrogation peut être réglée, par exemple, à 10 secondes ou à une minute. Une récurrence comprise entre 10 et 30 secondes, sur une valeur facteur de 60, convient à certains traitements réguliers. Ce n’est pas une recommandation universelle. C’est une base de paramétrage à confronter au terrain.

Interroger toutes les 10 secondes une source dont le capteur transmet toutes les 15 secondes ne crée pas plus de précision. Cela génère des requêtes redondantes, des doublons potentiels et une charge inutile. À l’inverse, interroger chaque minute un dispositif qui doit signaler une sortie de zone dans les vingt secondes rend l’alerte opérationnellement inutilisable.

Le bon intervalle se calcule à partir de la dynamique du phénomène. Un engin roulant à vitesse élevée, un chantier avec zones de sécurité mobiles et une surveillance de réseau nécessitent des fenêtres courtes. Un suivi d’état d’ouvrage ou de qualité de l’air peut tolérer une cadence plus large, à condition que la date de mesure reste intacte.

Il faut séparer quatre temps:

1. L’heure de mesure: celle à laquelle le capteur ou le récepteur produit l’observation.

2. L’heure d’émission: celle à laquelle l’équipement tente de transmettre cette observation.

3. L’heure de réception: celle à laquelle la plateforme reçoit le message.

4. L’heure d’affichage: celle à laquelle l’utilisateur voit la mise à jour.

Confondre ces temps fausse toute analyse de déplacement, de vitesse ou de réaction. Un véhicule peut apparaître à l’écran à 10 h 02 avec une position mesurée à 10 h 00. La géométrie est correcte. Son usage pour une décision immédiate ne l’est plus.

L’interopérabilité se joue dans le modèle de données, pas dans l’export

La promesse d’un système d’information géographique interopérable est souvent réduite à la lecture d’un fichier. C’est insuffisant. Lire un GeoJSON, un CSV ou un Shapefile ne garantit ni l’interprétation correcte des coordonnées, ni la conservation des attributs de qualité, ni la synchronisation fiable des mises à jour.

Les plateformes de traitement temps réel peuvent ingérer des données via HTTP, Kafka, MQTT, RabbitMQ, gRPC, WebSocket ou des services cloud. Elles peuvent manipuler du JSON, du GeoJSON, de l’Esri JSON, du CSV délimité, du GeoRSS, du Shapefile ou du Parquet selon la source. Cette diversité est utile. Elle ne corrige pas d’elle-même un schéma mal conçu.

Trois erreurs sont récurrentes:

• transmettre des coordonnées sans déclarer le système de référence;
• utiliser un champ texte libre pour l’horodatage;
• faire varier les noms, unités ou types d’attributs selon les équipements.

Un capteur qui envoie une température, une position et une date peut sembler trivial à intégrer. Dès qu’il faut comparer des capteurs de générations différentes, reconstruire une trajectoire ou calculer une alerte géographique, les simplifications initiales remontent à la surface.

L’OGC SensorThings API répond à une partie de cette difficulté. Sa composante « Sensing » normalise la représentation et la récupération des observations ainsi que de leurs métadonnées pour des systèmes de capteurs hétérogènes. Ce cadre est pertinent lorsque le SIG doit relier un objet observé, un capteur, une propriété mesurée, une localisation et une série temporelle.

Il ne remplace pas une gouvernance de données. Il impose au contraire de la formaliser.

OGC API - Features répond à un autre besoin: créer, modifier et interroger des entités spatiales sur le Web. Sa partie centrale définit des capacités minimales et reste limitée à l’accès en lecture. C’est adapté à la diffusion structurée de couches géographiques. Ce n’est pas un mécanisme complet de pilotage de télémétrie ni une garantie de synchronisation terrain.

Un standard expose une donnée. Il ne compense ni un mauvais référentiel, ni un horodatage ambigu, ni une géométrie acquise sous multipath.

Dans une chaîne de traitement de données GNSS, la séparation des responsabilités doit rester nette. Le protocole transporte. L’API structure l’accès. Le SIG analyse. Le métier décide. Mélanger ces niveaux produit des architectures impossibles à maintenir.

La précision GNSS reste une condition physique

La cartographie SIG en temps réel peut représenter une précision apparente très élevée. Un point placé avec six décimales n’est pas nécessairement un point fiable. L’interface n’améliore ni la géométrie de constellation, ni le dégagement du ciel, ni la stabilité du centrage forcé sur une canne topographique.

La précision dépend notamment:

• du récepteur et de ses capacités multiconstellations;
• de la méthode de positionnement utilisée;
• de la disponibilité et de l’âge des corrections;
• de la qualité de l’antenne et de son installation;
• de l’environnement, notamment bâti, végétal, parois rocheuses et surfaces réfléchissantes;
• du référentiel de coordonnées et du modèle de transformation appliqué;
• de la durée d’observation et des filtres embarqués.

Les services temps réel de l’International GNSS Service diffusent des produits précis incluant des corrections d’orbite et d’horloge, ainsi que des biais de code et de phase. Ces éléments peuvent être employés dans des applications temps réel à la place de produits ultra-rapides. Ils constituent une brique de correction, pas une garantie automatique de résultat centimétrique.

Le seuil de qualité utile doit être défini par l’opération. Pour un inventaire de mobilier urbain, une position dégradée peut rester acceptable si elle est identifiée comme telle. Pour l’implantation d’un axe, le contrôle d’un récolement ou l’actualisation d’une limite foncière, le même niveau de qualité est insuffisant.

Le logiciel doit donc filtrer avant de publier. Une règle minimale consiste à ne pas traiter toutes les positions de la même manière. Il faut pouvoir distinguer:

• une mesure recevable pour visualisation;
• une mesure recevable pour analyse de tendance;
• une mesure recevable pour édition d’une géométrie de référence;
• une mesure à rejeter ou à conserver uniquement pour diagnostic.

Cette distinction est rarement visible dans les démonstrations. Elle est décisive en production. Une trace GNSS doit conserver les sauts de position, les pertes de correction, les ruptures de communication et les changements d’état. Lisser systématiquement une trajectoire peut améliorer l’esthétique de la carte. Cela peut aussi effacer un défaut de mesure utile au contrôle.

Le Track ID est le verrou de la continuité

Une plateforme temps réel ne suit pas des points. Elle suit des objets. Le lien entre les événements successifs repose sur un identifiant de suivi, souvent désigné comme Track ID.

Cet identifiant doit être unique et stable: numéro de véhicule, identifiant d’équipement, code de capteur, référence d’actif. Une plaque d’immatriculation peut jouer ce rôle pour un camion; un numéro de vol pour un aéronef. Dans une application de collecte SIG, l’identifiant de l’objet métier est préférable à un identifiant généré à chaque session.

Le défaut classique est simple: chaque message reçoit un nouvel identifiant technique. Le système voit alors une succession de points indépendants. Il ne peut plus calculer correctement une vitesse, une durée d’arrêt, une entrée en zone ou une trajectoire. À l’inverse, un identifiant réutilisé pour deux objets crée des croisements de parcours et des alertes absurdes.

Le Track ID doit être contrôlé dès l’ingestion:

1. Unicité: un même identifiant ne désigne qu’un seul objet actif dans le périmètre opérationnel.

2. Stabilité: il ne change pas après une reconnexion, un redémarrage ou un changement de réseau.

3. Traçabilité: son lien avec l’actif réel est documenté dans le référentiel métier.

4. Ordre temporel: les événements doivent conserver leur horodatage de mesure, y compris s’ils arrivent en retard.

5. Gestion des doublons: une même observation retransmise ne doit pas créer un déplacement fictif.

Ce verrou est particulièrement important lorsque plusieurs sources remontent dans le même logiciel SIG: application mobile, boîtier embarqué, station de surveillance et import différé. Une couche dynamique sans discipline d’identification devient rapidement une collection de géométries impossibles à auditer.

Le hors connexion ne suspend pas la gouvernance

Le terrain ne garantit pas une couverture réseau continue. Tranchée, zone boisée, sous-sol, emprise ferroviaire, façade dense ou chantier isolé: l’application de collecte doit pouvoir continuer à fonctionner sans connexion. Cette capacité ne signifie pas que toutes les données sont disponibles localement.

Seules les couches configurées pour la synchronisation hors connexion peuvent être téléchargées, modifiées et mises à jour au retour du réseau. La synchronisation renvoie les modifications locales vers la couche web et récupère les évolutions faites par d’autres éditeurs dans l’emprise téléchargée.

Cette mécanique a une limite nette: le conflit.

Sur des données de référencement linéaire, une réplication locale et la synchronisation doivent être activées. Certains modes de synchronisation directe vers la version par défaut ne permettent ni revue ni résolution de conflit. La dernière modification appliquée est alors conservée. Ce comportement est techniquement cohérent. Il est dangereux si l’équipe pense bénéficier d’une fusion intelligente.

Une opération terrain robuste doit donc définir ce qui peut être modifié hors ligne. Les géométries de référence, les tronçons structurants et les attributs réglementaires ne se gèrent pas comme une observation ponctuelle de maintenance.

Le découpage peut être strict:

• les équipes terrain créent des constats, photos, points de contrôle et mesures;
• les géométries de référence restent sous validation d’un responsable de données;
• les attributs sensibles passent par une règle de révision;
• chaque synchronisation génère un journal exploitable pour l’audit.

La synchronisation n’est pas un bouton de confort. C’est une opération de versionnement distribuée. Elle doit être testée avec des modifications concurrentes, des géométries déplacées, des suppressions et des retours réseau partiels. Sans test de stress, la première collision de versions se produit en production.

La performance utile se mesure à la décision, pas au débit brut

La latence acceptable n’a pas de valeur universelle. Elle dépend du phénomène observé, de la vitesse de déplacement, de la densité d’événements, de la capacité réseau et du traitement effectué. Affirmer qu’un système est « temps réel » sans mesurer cette chaîne ne signifie rien.

La métrique opérationnelle doit être calculée entre l’heure de mesure et l’heure à laquelle la donnée devient exploitable dans la couche cible. Ensuite seulement, il faut distinguer les délais:

• délai de transmission;
• délai d’attente dans la file de messages;
• délai de traitement géospatial;
• délai d’écriture dans le stockage;
• délai de rendu côté client.

Cette décomposition évite le mauvais diagnostic. Une carte lente n’est pas nécessairement un problème de logiciel de cartographie SIG. Le goulot peut venir d’un débit mobile insuffisant, d’un flux mal indexé, d’une géométrie inutilement complexe ou d’une analyse lancée sur chaque événement sans filtrage préalable.

Les tests doivent pousser le système hors de son régime nominal: perte puis reprise de réseau, événements désordonnés, doublons, volume concentré, changement de système de coordonnées, positions GNSS dégradées, modification concurrente en mode hors ligne. Un flux qui fonctionne avec trois capteurs sur un réseau stable ne valide aucune architecture.

Le verdict est binaire. Si la plateforme conserve l’identifiant, l’horodatage, le référentiel, l’état de qualité GNSS et la règle de synchronisation, la cartographie dynamique devient exploitable. Si elle se contente d’animer des symboles sur une carte, elle produit une visualisation. Pas une donnée de levé, pas une donnée de décision, pas une chaîne SIG fiable.