SIG terrain : contrôler les coordonnées avant l’import dans QGIS ou PostGIS

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

Un fichier terrain peut passer les contrôles de format et placer tous ses points au mauvais endroit. Vérifier les axes, le système de référence et l’emprise évite de transformer une erreur d’import en donnée de production.

Voici un protocole reproductible pour une livraison CSV de points terrain. Il associe vérification du contrat de données, filtrage simple en Python et préparation de l’import dans QGIS ou PostGIS. Les données sont fictives. Cette méthode de fond ne constitue pas une annonce de nouvelle version logicielle.

Commencer par le contrat de livraison

Demandez au producteur le système de référence complet, l’ordre des colonnes, les unités, le séparateur décimal et la méthode de collecte. Ajoutez un identifiant stable, la date du relevé et, lorsqu’elle existe, une indication documentée de sa qualité. Deux nombres nommés X et Y ne suffisent pas à identifier un système de coordonnées.

Conservez le fichier reçu et ses valeurs brutes. Travaillez dans une table de préparation distincte, avec un statut par ligne et un motif de rejet. Cette séparation permet de retrouver ce qui a été reçu, normalisé, corrigé puis accepté, au lieu de transformer un fichier source jusqu’à perdre la trace des décisions.

Deux valeurs plausibles peuvent former un point faux

Prenons le couple fictif longitude −9,2 et latitude 32,3. Si les colonnes sont permutées, on obtient longitude 32,3 et latitude −9,2. Ces deux couples respectent les bornes mondiales des coordonnées géographiques, mais désignent des lieux très différents. Un test limité à ces bornes ne détectera donc pas l’erreur.

La FAQ officielle de PROJ, documentation 9.9.0 consultée, rappelle que l’ordre des axes dépend de la définition du système et de l’interface utilisée. EPSG:4326 définit notamment la latitude avant la longitude, alors que de nombreux usages SIG manipulent des couples X/Y longitude/latitude. Il faut documenter la convention attendue par chaque outil ; le seul code EPSG ne décrit pas à lui seul l’ordre des colonnes d’un CSV.

Un filtre Python qui signale sans corriger

Le script suivant utilise uniquement la bibliothèque standard Python 3. Il attend des nombres décimaux avec un point et une livraison dont le contrat annonce longitude puis latitude en degrés WGS 84. La zone rectangulaire est volontairement pédagogique : elle ne représente aucune limite officielle de Safi ou d’un service gestionnaire.

from math import isfinite

# Zone pédagogique fictive, pas une limite administrative.
ZONE = (-10.0, 31.0, -8.0, 33.0)  # ouest, sud, est, nord

def controle(lon_brute, lat_brute):
    try:
        lon, lat = float(lon_brute), float(lat_brute)
    except (TypeError, ValueError, OverflowError):
        return "FORMAT_A_REVOIR"
    if not (isfinite(lon) and isfinite(lat)):
        return "FORMAT_A_REVOIR"
    if not (-180 <= lon <= 180 and -90 <= lat <= 90):
        return "HORS_DOMAINE"
    ouest, sud, est, nord = ZONE
    if not (ouest <= lon <= est and sud <= lat <= nord):
        return "HORS_ZONE_A_REVOIR"
    return "COHERENT_AVEC_ZONE"

print(controle("-9.2", "32.3"))  # COHERENT_AVEC_ZONE
print(controle("32.3", "-9.2"))  # HORS_ZONE_A_REVOIR
print(controle("NaN", "32.3"))   # FORMAT_A_REVOIR

Le statut COHERENT_AVEC_ZONE indique uniquement que le point passe ce filtre. Un relevé peut encore être décalé dans le rectangle, mal identifié ou insuffisamment précis. Inversement, un point hors zone peut être légitime si la mission déborde le périmètre prévu. Le programme classe les lignes pour examen ; il ne permute jamais les colonnes et ne remplace aucune coordonnée.

Une virgule décimale sera ici refusée. Si le contrat prévoit ce format, définissez une normalisation explicite avant le contrôle et conservez la valeur initiale. Un remplacement global dans un CSV peut également toucher le séparateur de champs : il faut analyser le fichier selon son format, plutôt que modifier indistinctement tous les caractères.

Attribuer un système ne transforme pas les nombres

La distinction est explicite dans la documentation PostGIS 3.5 de ST_SetSRID : cette fonction attribue un identifiant de système à une géométrie, sans transformer ses coordonnées. Elle convient lorsque le système source est connu et que l’on construit la géométrie correspondante. L’utiliser pour faire disparaître un décalage revient à changer une étiquette sans établir la bonne interprétation.

À l’inverse, ST_Transform calcule des coordonnées dans un système cible à partir de la référence source. L’exemple ci-dessous part d’un point WGS 84 connu et produit une représentation Web Mercator. Il ne faut pas le réutiliser en déclarant 4326 à une source dont le système est inconnu.

-- Exemple fictif, à lire dans un environnement PostGIS 3.5.
-- La source est ici connue : longitude/latitude WGS 84.
SELECT ST_AsText(
  ST_Transform(
    ST_SetSRID(ST_Point(-9.2, 32.3), 4326),
    3857
  )
);

La transformation demande une installation PostGIS disposant de PROJ. Relevez les versions avec PostGIS_Full_Version() dans votre environnement de test. La destination 3857 sert ici à illustrer une transformation pour l’affichage ; le choix d’une projection adaptée aux mesures et aux analyses métier doit être traité séparément.

Vérifier aussi les paramètres dans QGIS

Dans QGIS 3.44, l’import de texte délimité permet de choisir le délimiteur, le séparateur décimal, les champs X/Y et le système de référence de la géométrie. Vérifiez ces paramètres dans l’aperçu avant d’ajouter la couche. Dans notre contrat pédagogique, X reçoit la longitude et Y la latitude ; cette convention ne doit pas être généralisée à toute livraison.

Contrôlez ensuite plusieurs points répartis sur la zone avec une référence dont la qualité est connue. Une superposition visuellement satisfaisante sur un fond de carte ne remplace pas cette vérification. Conservez aussi les identifiants comme du texte lorsque les zéros initiaux ont un sens : la qualité des coordonnées ne corrige pas une association erronée entre un point et sa fiche.

Établir une décision d’import traçable

Le bilan utile distingue les lignes reçues, illisibles, hors domaine, hors zone et cohérentes avec le périmètre de contrôle. Ajoutez les cas dont le système source reste à confirmer. Ces catégories doivent correspondre à des règles écrites et à une décision identifiable : acceptation, retour au producteur ou vérification terrain.

Avant chaque modification du script ou des paramètres d’import, rejouez un petit lot conservé contenant un point cohérent, une permutation, une valeur absente et un nombre non fini. Faites vérifier que les statuts attendus restent inchangés. Ce contrôle limité ne certifie pas l’exactitude géodésique du lot ; il protège contre la réapparition d’erreurs déjà identifiées.

Une fois les coordonnées interprétées et contrôlées, les vérifications de géométrie, de connectivité et d’attributs prennent le relais. Pour replacer ces étapes dans une démarche métier, voir aussi les données de réseaux et le travail de terrain à Safi.

Références et portée

Sources primaires consultées le 4 novembre 2026 : PROJ, FAQ, documentation 9.9.0 ; PostGIS 3.5, ST_SetSRID et ST_Transform ; QGIS 3.44, importation de texte délimité. Ce sont des références techniques de fond, pas des publications d’actualité datées de cette semaine. Aucun relevé réel, résultat d’audit ou taux d’erreur mesuré n’est présenté.