Réponse courte

Quand des couches ne s'alignent pas, la cause est presque toujours un problème de système de coordonnées de référence (SCR), et il n'y en a que quelques variantes : un SCR manquant (pas de .prj/pas de SRID déclaré), un mauvais SCR déclaré (les métadonnées disent une chose, les coordonnées en disent une autre), une différence de datum (même projection, datum géodésique différent, d'où un décalage de plusieurs dizaines de mètres) ou un problème d'ordre des axes (lat/long inversés). Chacun a une correction différente, le premier travail est donc d'identifier la défaillance, pas de commencer à pousser les couches.

Le piège est que la reprojection à la volée dans QGIS ou ArcGIS peut faire afficher les couches ensemble même quand l'une est mal étiquetée, masquant l'erreur jusqu'à ce que vous mesuriez, découpiez ou exécutiez une analyse de terrain et obteniez de mauvais chiffres.

Diagnostiquer en lisant les coordonnées, pas la carte

Désactivez le fond de carte et regardez les emprises brutes. Dans QGIS, Propriétés de la couche → Information affiche l'emprise dans le SCR propre de la couche. Indices révélateurs :

  • Des coordonnées autour de (7.1, 43.6) sont géographiques (degrés, WGS84 / EPSG:4326).
  • Des coordonnées autour de (320000, 4760000) sont projetées (mètres, par ex. UTM).
  • Des coordonnées autour de (792000, 1843000) pourraient être une grille nationale (Lambert, State Plane, British National Grid).

Si une couche affiche des degrés et une autre des mètres, les deux peuvent quand même être correctes à condition que le SCR déclaré de chacune corresponde à ses chiffres. Le défaut d'alignement apparaît quand les chiffres d'une couche appartiennent à un SCR mais que ses métadonnées en revendiquent un autre.

Un tri rapide :

ogrinfo -so -al layer.shp | grep -A3 -i "PROJCRS\|GEOGCRS\|Extent"
gdalsrsinfo layer.shp        # quel SCR est déclaré

Pour un shapefile, vérifiez que .prj existe ; s'il est absent, la couche n'a aucun SCR et le logiciel devine.

Cas 1 — SCR manquant (pas de .prj)

Un shapefile sans .prj n'a aucun SCR déclaré. Le logiciel se rabat sur le SCR du projet ou sur « inconnu », les coordonnées brutes sont donc interprétées dans le mauvais système et la couche saute. La correction est d'attribuer le vrai SCR source de la couche, que vous déterminez à partir du fournisseur de données, de l'ordre de grandeur des coordonnées ou d'un point de repère connu, et non par tâtonnement.

Dans QGIS, utilisez Vecteur → Gestion des données → Attribuer une projection (ou définissez le SCR de la couche et réexportez). Avec GDAL :

ogr2ogr -a_srs EPSG:27700 fixed.shp broken.shp   # -a_srs attribue, aucun changement de coordonnées

-a_srs n'écrit que l'étiquette ; il ne déplace pas les coordonnées. C'est exactement ce que vous voulez quand la géométrie est déjà correcte.

Cas 2 — Mauvais SCR déclaré

Ici le .prj existe mais est faux (résultat fréquent de quelqu'un attribuant un SCR pour « corriger » un problème d'affichage). Le symptôme est une couche cohérente en interne mais décalée ou déformée par rapport à tout le reste. La correction est le même -a_srs / Attribuer une projection, mais vers le bon SCR source. Si vous avez déjà exporté avec la mauvaise étiquette figée, vous devrez peut-être attribuer la bonne étiquette puis vérifier contre un point de contrôle.

La règle qui prévient l'essentiel de ce désordre : attribuer vs reprojeter.

  • Attribuer (-a_srs, Attribuer une projection) : coordonnées déjà correctes, métadonnées manquantes/fausses → réétiqueter seulement.
  • Reprojeter (-t_srs, Reprojeter la couche, ST_Transform) : métadonnées correctes, vous avez besoin de coordonnées différentes → transformer.

Attribuer quand il faudrait reprojeter est l'erreur la plus destructrice à elle seule, car elle indique au logiciel que les mètres sont des degrés (ou inversement) et les données atterrissent sur le mauvais continent.

Cas 3 — Décalage de datum

Deux SCR peuvent utiliser la même projection mais des datums différents, de sorte que des points au sol identiques ont des coordonnées légèrement différentes. Couples classiques : NAD27 vs NAD83 (jusqu'à ~100 m dans certaines régions d'Amérique du Nord), ED50 vs ETRS89/WGS84 en Europe (souvent 50–200 m), ou d'anciens datums nationaux face à leurs remplaçants modernes. Les couches s'affichent « presque » alignées, décalées d'un vecteur constant.

La correction est une véritable transformation de datum, que PROJ gère. Reprojetez avec le bon pipeline de transformation plutôt qu'un réétiquetage à projection identique :

gdalwarp -s_srs EPSG:4267 -t_srs EPSG:4326 in.tif out.tif   # NAD27 -> WGS84
ogr2ogr -t_srs EPSG:4258 -s_srs EPSG:4230 out.shp in.shp     # ED50 -> ETRS89

Quand une grande précision compte, préférez la transformation officielle par grille de décalage (par ex. grilles NTv2) à un Helmert à 3 paramètres ; PROJ utilisera la grille si elle est installée. Dans QGIS, la boîte de dialogue de transformation vous laisse choisir l'opération précise et indique sa précision attendue.

Cas 4 — Ordre des axes

Certaines autorités définissent EPSG:4326 comme latitude-puis-longitude. Quelques outils le lisent longitude d'abord. Le symptôme est des données retournées le long de la diagonale ou situées dans le mauvais hémisphère. La correction est de forcer l'interprétation des axes, par ex. le comportement OAMS_TRADITIONAL_GIS_ORDER de GDAL, ou de définir -t_srs "EPSG:4326" de façon cohérente et de vérifier si votre outil respecte l'ordre des axes de l'autorité. Cela mord le plus souvent avec WFS/GML et certains allers-retours en WKT.

Parcours de diagnostic concret

Un projet comporte : une emprise en British National Grid (EPSG:27700, coords ~530000, 180000), une couche géologique publique en WGS84 (coords ~-0.1, 51.5), un shapefile de levé sans .prj, et un fond OSM en Web Mercator (EPSG:3857). À l'écran ils se superposent grossièrement grâce à la reprojection à la volée, mais une mesure de distance est fausse.

  1. L'emprise et la géologie vont bien : le SCR déclaré correspond à leurs chiffres.
  2. Le shapefile de levé n'a pas de .prj. Ses coordonnées sont ~530000, 180000, c'est donc du BNG ; attribuez EPSG:27700 (-a_srs EPSG:27700).
  3. Pour toute mesure, surface, tampon ou découpe de MNT, reprojetez les couches de travail dans le SCR projeté de la zone (EPSG:27700 ici), jamais dans la vue WGS84 ou 3857.
  4. Consignez la chaîne : SCR source → SCR de traitement (27700) → SCR de sortie.

Pourquoi Web Mercator ne sert pas à la mesure

EPSG:3857 (Web Mercator) est un SCR d'affichage. Son facteur d'échelle croît avec la latitude, les distances et surfaces sont donc déformées, fortement aux hautes latitudes. La reprojection à la volée vers 3857 fait paraître les couches alignées, mais un tampon ou une surface calculés là sont faux. Reprojetez vers une projection équivalente en surface ou une UTM/projection nationale locale pour tout calcul, puis revenez à 3857 seulement pour l'affichage web.

Pièges fréquents et leurs causes

  • Mesurer en Web Mercator parce que c'est le SCR par défaut du fond de carte, ce qui le fait paraître canonique. Ce n'est pas la vérité métrique.
  • Attribuer un SCR pour forcer une couche à se déplacer, ce qui corrompt définitivement les métadonnées.
  • Tampons ou calcul de surface sur des degrés, qui produit des absurdités en « degrés carrés ».
  • Ignorer les unités/datum verticaux quand l'altitude est en jeu (pieds vs mètres, hauteurs orthométriques vs ellipsoïdales) — l'horizontal peut s'aligner tandis que les altitudes sont fausses.
  • Sauter la transformation de datum parce que les couches paraissent assez proches.

Contrôle qualité et validation

Avant d'exporter une carte ou une analyse : confirmez que le SCR déclaré de chaque couche correspond aux ordres de grandeur de ses coordonnées ; vérifiez l'alignement contre une référence fiable (un carrefour routier connu, une borne géodésique) plutôt qu'en jugeant à l'œil le fond de carte ; mesurez une distance connue pour confirmer que le SCR de travail est métrique et correct ; et notez les SCR source, de traitement et de sortie ainsi que la transformation utilisée. Pour les travaux sensibles au datum, notez la précision annoncée de la transformation.

Le point de vue Bathyl

Nous traitons la chaîne de SCR comme un livrable à part entière : SCR source, décision attribuer-ou-reprojeter, transformation de datum et SCR de sortie, le tout documenté pour qu'un autre analyste puisse auditer la géométrie. Une carte qui s'aligne à l'écran mais sans logique de coordonnées consignée n'est pas un travail terminé.

À lire aussi

Sources