SIG : une géométrie valide ne garantit pas un réseau connecté

Article d’archive. Texte préparé le 31 octobre 2026, mis en ligne le 7 novembre 2026.

Deux conduites peuvent être valides au sens géométrique sans partager de nœud. Pour savoir si un réseau est exploitable, testez les raccords, les distances et les exceptions métier séparément.

Pour fiabiliser des données de réseau, il faut séparer trois examens : la forme de chaque objet, ses relations avec les autres objets et sa cohérence métier. Ce guide propose une méthode de travail avec un petit exemple fictif. Il s’appuie sur le manuel officiel de PostGIS 3.5 et sur des références officielles consultées le 31 octobre 2026. Il ne présente pas ces fonctions anciennes comme une nouveauté.

Trois contrôles qui ne se remplacent pas

Selon la documentation de ST_IsValid, cette fonction vérifie la validité géométrique en deux dimensions selon les règles OGC. Même lorsque l’objet contient des coordonnées supplémentaires, ce test reste en 2D. Un résultat positif ne certifie donc ni la connexion à un autre tronçon, ni l’altitude réelle d’une conduite, ni l’exactitude d’un relevé.

La simplicité géométrique constitue encore un autre examen : ST_IsSimple recherche notamment les auto-intersections ou auto-contacts problématiques. Ces propriétés décrivent la géométrie. Elles ne suffisent pas à affirmer qu’un segment correspond au bon équipement ou que son extrémité rejoint le bon nœud.

Le contrôle topologique entre objets pose une question différente : quelles extrémités doivent être raccordées, quels croisements doivent rester indépendants et quelles interruptions sont admises ? Le contrôle métier examine ensuite les identifiants, le type de réseau, les attributs et les informations terrain qui justifient ces relations.

Un écart discret, deux géométries valides

Prenons deux tronçons fictifs. Le premier va de (0, 0) à (10, 0). Le second commence en (10,2 ; 0) et finit en (20, 0). Ils sont rectilignes et séparés par 0,2 unité. À une petite échelle d’affichage, l’espace peut devenir difficile à distinguer. Cela ne le transforme pas en connexion.

Le script suivant est destiné à une base de test disposant déjà de PostGIS. Il crée uniquement une table temporaire et termine par une annulation de transaction. Les coordonnées utilisent un repère local fictif, sans localisation géographique ; nous supposons, pour cet exercice seulement, qu’une unité représente un mètre. Le SQL repose sur les signatures documentées, mais n’a pas été exécuté ici dans une instance PostGIS.

-- Base de test avec PostGIS déjà installé.
-- Coordonnées fictives : SRID 0, une unité supposée égale à un mètre.
-- Ne pas utiliser ces coordonnées comme une localisation réelle.
BEGIN;

CREATE TEMP TABLE qa_demo (
  id integer PRIMARY KEY,
  geom geometry(LineString)
);

INSERT INTO qa_demo VALUES
  (1, ST_GeomFromText('LINESTRING(0 0,10 0)', 0)),
  (2, ST_GeomFromText('LINESTRING(10.2 0,20 0)', 0));

SELECT id, ST_IsValid(geom) AS valide,
       ST_IsSimple(geom) AS simple
FROM qa_demo ORDER BY id;

SELECT
  ST_Distance(ST_EndPoint(a.geom), ST_StartPoint(b.geom)) AS ecart,
  ST_DWithin(ST_EndPoint(a.geom), ST_StartPoint(b.geom), 0.25)
    AS candidat_a_verifier
FROM qa_demo a
JOIN qa_demo b ON a.id = 1 AND b.id = 2;

ROLLBACK;

Les résultats attendus sont deux objets valides et simples, puis un écart proche de 0,2 et un indicateur de proximité vrai pour le seuil de 0,25. L’affichage numérique exact peut varier selon la représentation flottante. Cette proximité désigne un cas à vérifier : elle ne démontre pas qu’un raccord existe.

Choisir une tolérance qui a un sens

Pour le type geometry, ST_DWithin exprime la distance dans les unités du système de coordonnées et suppose des géométries dans le même référentiel. Un seuil de 0,25 n’a donc pas le même sens dans une couche en mètres et dans une couche en degrés. Dans un projet réel, vérifiez le système, les unités et leur adéquation aux mesures locales avant de rechercher les anomalies.

La précision de la source doit également guider le choix. Un relevé approximatif, un plan numérisé et une mesure de précision ne justifient pas les mêmes décisions. Le seuil de l’exemple est pédagogique ; il ne constitue pas une norme applicable à tous les réseaux. Documentez plutôt la raison du seuil retenu et ce qui doit arriver aux cas détectés.

Passer du cas simple à un audit de réseau

Dans l’exemple, nous comparons volontairement la fin du premier tronçon au début du second. Cette simplification suppose une orientation connue. Pour un inventaire réel de LineString, extrayez les deux extrémités de chaque objet, conservez son identifiant et examinez les voisins dans la tolérance choisie. Les objets multiparties nécessitent un traitement distinct de leurs composantes.

Ajoutez ensuite les règles du métier. Deux segments proches peuvent appartenir à des réseaux différents ou traverser le même emplacement sans jonction. À l’inverse, une extrémité isolée peut être normale : branchement terminal, limite du périmètre étudié ou équipement encore non relevé. Classez ces situations avant de transformer une liste de candidats en liste d’erreurs.

Une fiche d’anomalie utile conserve les objets concernés, l’écart mesuré, la règle déclenchée, la source et une décision : à examiner, confirmé, exception justifiée ou corrigé. La personne qui reprend le dossier doit pouvoir comprendre pourquoi le cas a été signalé et ce qui a motivé sa résolution.

Corriger sans déplacer le problème

Le rapprochement automatique des sommets peut être utile, mais la documentation de ST_Snap précise que le résultat peut perdre sa simplicité ou sa validité. L’outil utilise aussi des heuristiques : certains rapprochements possibles peuvent être omis. Il faut donc contrôler le résultat, plutôt que considérer la tolérance comme une garantie de correction.

Travaillez sur une copie identifiée, comparez les géométries avant et après, puis rejouez les contrôles géométriques, topologiques et attributaires. Si le raccord dépend d’une information absente du dossier, prévoyez une validation terrain. Déplacer un sommet pour fermer visuellement un vide ne fournit pas cette preuve.

Produire un bilan que l’équipe peut utiliser

Le livrable peut rester simple : nombre d’objets examinés, anomalies par règle, exceptions documentées, corrections validées et cas nécessitant une vérification complémentaire. Gardez avec ce bilan la date des données, les versions de PostGIS et GEOS et les paramètres utilisés, afin de comparer les prochains audits.

Une base fiable ne se résume pas à un compteur d’erreurs nul. Elle permet de distinguer ce qui est contrôlé, ce qui reste incertain et ce qui a été confirmé. Pour un réseau exploité sur le terrain, cette distinction rend la carte plus utile qu’une correction automatique dont personne ne peut expliquer les conséquences.

Références et portée

PostGIS 3.5 — ST_IsValid ; PostGIS 3.5 — ST_DWithin ; ST_IsSimple ; ST_Snap. Documentation officielle consultée le 31 octobre 2026, sans date de publication récente établie pour ces pages. La méthode d’audit et les données d’exemple constituent une proposition pédagogique, pas une étude de performance ni une description d’un réseau réel.

Dans les archives Geekkech. SIG à Safi : une bonne carte commence par une donnée que l’on peut vérifier.