Réponse courte

Un code EPSG est un entier court qui pointe vers un système de coordonnées de référence (SCR) précis dans le EPSG Geodetic Parameter Dataset, un registre public maintenu par l'IOGP. Au lieu de décrire un datum, un ellipsoïde, des unités et une projection à la main, vous citez un nombre — EPSG:4326 pour WGS84 lon/lat, EPSG:3857 pour le Web Mercator, EPSG:32631 pour la zone UTM 31N — et tout logiciel conforme résout la définition complète. Le code est le raccourci sans ambiguïté qui permet à deux systèmes de s'accorder sur ce que signifie exactement une paire de coordonnées.

Ce que contient réellement le registre

« EPSG » signifie European Petroleum Survey Group, le groupe qui a créé le jeu de données ; il est aujourd'hui géré par l'International Association of Oil & Gas Producers (IOGP). Le registre est plus large que les seuls systèmes de coordonnées. Il attribue des codes à plusieurs types d'objets :

  • Systèmes de coordonnées de référence (p. ex. 4326, 32631), les entrées que la plupart des gens désignent par « code EPSG ».
  • Datums (p. ex. 6326 pour WGS84), qui fixent le modèle et l'orientation de la Terre.
  • Ellipsoïdes (p. ex. 7030 pour l'ellipsoïde WGS84, un sphéroïde dérivé de GRS80), la forme mathématique.
  • Opérations / transformations de coordonnées (p. ex. les décalages de datum entre NAD27 et NAD83), les recettes pour passer d'un système à l'autre.

Ainsi, lorsqu'un logiciel résout EPSG:32631, il ne lit pas seulement « UTM 31N » ; il déroule une chaîne : un SCR projeté, bâti sur le SCR géographique WGS84, sur le datum WGS84, sur un ellipsoïde défini, avec une projection Transverse Mercator paramétrée sur un méridien central de 3°E, un false easting de 500 000 m, et des unités en mètres. Le code comprime tout cela en cinq chiffres.

Codes géographiques vs projetés

La propriété la plus importante d'un SCR — et celle qui piège tout le monde — est de savoir s'il est géographique ou projeté.

Un SCR géographique comme EPSG:4326 (WGS84) exprime la position en longitude et latitude, en degrés, sur un ellipsoïde. Les degrés sont angulaires, pas métriques, et leur taille au sol varie : un degré de latitude vaut environ 111 km partout, mais un degré de longitude rétrécit d'environ 111 km à l'équateur jusqu'à 0 aux pôles. Vous ne pouvez pas mesurer de façon fiable une distance ou une surface directement dans un SCR géographique.

Un SCR projeté comme EPSG:32631 (UTM 31N) aplatit l'ellipsoïde sur un plan et exprime la position en mètres (easting, northing). Distance et surface deviennent alors de simples calculs euclidiens, exacts dans la zone de validité de la projection. L'UTM maintient la déformation sous environ 0,1 % près du méridien central d'une zone, ce qui en fait l'outil de référence pour la mesure régionale.

La règle qui en découle : stockez et échangez en SCR géographique si vous voulez, mais transformez vers un SCR projeté adapté avant de mesurer quoi que ce soit.

L'astuce de numérotation UTM

Les codes UTM suivent un schéma qui vaut la peine d'être mémorisé car il évite des recherches constantes. Le monde est divisé en 60 zones UTM, chacune large de 6 degrés de longitude. Pour WGS84 :

  • Hémisphère nord : EPSG = 32600 + zone, donc la zone 31N est 32631.
  • Hémisphère sud : EPSG = 32700 + zone, donc la zone 56S est 32756.

Pour trouver la zone à partir d'une longitude : zone = floor((lon + 180) / 6) + 1. Londres, vers 0°W, est en zone 30 → EPSG:32630. Singapour, près de 104°E, est en zone 48N → EPSG:32648. Sydney, près de 151°E, hémisphère sud, est en zone 56S → EPSG:32756. (Notez que tout ceci suppose le datum WGS84 ; les grilles nationales sur d'autres datums ont des codes entièrement distincts, p. ex. EPSG:27700 pour le British National Grid sur OSGB36.)

Exemple détaillé : assigner vs reprojeter

Vous recevez survey.shp. Le fichier s'ouvre mais s'affiche au mauvais endroit. Deux corrections très différentes existent, et choisir la mauvaise corrompt les données.

D'abord, diagnostiquez en regardant les valeurs de coordonnées, pas le nom de fichier. Ouvrez la table attributaire ou lancez ogrinfo -al -so survey.shp. Si les eastings tournent autour de 450 000 et les northings autour de 5 400 000, ce sont des mètres : des données de type UTM. Si les valeurs ressemblent à 2.35 et 48.85, ce sont des degrés : lon/lat.

Cas A : métadonnées absentes, coordonnées correctes. Les chiffres sont de vrais mètres UTM 31N mais le .prj est absent, donc le logiciel ne suppose rien par défaut. Vous assignez (définissez) le SCR ; cela ne modifie aucune coordonnée :

# GDAL : définir le SCR sans déplacer aucune coordonnée
ogr2ogr -a_srs EPSG:32631 survey_defined.shp survey.shp
-- Équivalent PostGIS : apposer le bon SRID sur une géométrie non estampillée
UPDATE survey SET geom = ST_SetSRID(geom, 32631);

Cas B : coordonnées dans un SCR, vous en voulez un autre. Les données sont correctement définies en UTM 31N mais votre projet est en WGS84. Vous reprojetez (transformez) ; cela recalcule chaque coordonnée :

# GDAL : transformer du SCR source vers le SCR cible
ogr2ogr -t_srs EPSG:4326 survey_wgs84.shp survey.shp
-- Équivalent PostGIS
SELECT id, ST_Transform(geom, 4326) AS geom FROM survey;

L'erreur fatale consiste à utiliser l'assignation du Cas A pour « corriger » un problème de Cas B : apposer EPSG:4326 sur des données réellement en mètres UTM laisse 450 000 à la place d'une longitude, expédiant chaque entité au large des côtes d'Afrique de l'Ouest.

Codes à mémoriser

Une poignée de codes couvrent la majeure partie du travail quotidien, et les reconnaître au premier coup d'œil évite beaucoup de confusion :

  • EPSG:4326 — WGS84 géographique (degrés lon/lat). La lingua franca de l'échange de données, du GPS et du GeoJSON. Pas pour la mesure.
  • EPSG:3857 — Web Mercator (mètres). La projection de presque tous les fonds de carte web (tuiles Google, OSM, Esri). Excellent pour l'affichage, gravement déformé pour les surfaces ; à éviter pour l'analyse.
  • EPSG:4979 / EPSG:4978 — variantes WGS84 géographique 3D et géocentrique (ECEF), rencontrées en GNSS et en géodésie.
  • EPSG:326## / 327## — zones UTM nord / sud sur WGS84, le standard du travail métrique régional.
  • Grilles nationales — EPSG:27700 (British National Grid), EPSG:2154 (RGF93 Lambert-93, France), EPSG:25832 (ETRS89 / UTM 32N, une grande partie de l'Europe), EPSG:5070 (NAD83 Conus Albers, équivalence de surface à l'échelle nationale aux États-Unis). Ces SCR reposent sur des datums régionaux, pas sur WGS84, donc passer de l'un à l'autre peut impliquer un décalage de datum.

Le point du datum est facile à manquer et coûteux à rater : deux SCR peuvent tous deux être « UTM 32N » mais sur des datums différents (WGS84 vs ETRS89 vs NAD83), et l'écart entre eux peut atteindre un mètre ou plus, ce qui compte pour des travaux de précision topographique. Le code EPSG désambiguïse exactement lequel vous visez, et le registre détient aussi la transformation entre eux.

Pièges courants et leurs causes

  • Mesurer en EPSG:4326. Distances et surfaces ressortent en non-sens fondé sur les degrés parce que les unités sont angulaires. Transformez d'abord vers l'UTM.
  • Utiliser EPSG:3857 (Web Mercator) pour l'analyse. Familier d'après les fonds de carte, mais sa déformation de surface croît énormément avec la latitude (le Groenland paraît plus grand que l'Afrique). Bien pour l'affichage, faux pour la mesure.
  • Assigner alors qu'il faut transformer. Change l'étiquette, pas les chiffres, et déplace silencieusement les données. Voir Cas A vs B ci-dessus.
  • Ignorer l'aire d'utilisation. Chaque SCR projeté a une étendue valide ; UTM 31N n'a aucun sens pour des données au Japon. Vérifiez l'emprise, p. ex. sur epsg.io.
  • Supposer que tout « WGS84 » est une seule chose. EPSG:4326 a des réalisations et des ensembles de datums ; pour le travail sub-métrique, la réalisation précise et toute transformation de datum comptent.
  • Oublier le SCR vertical. L'altitude a son propre datum et ses propres unités (p. ex. EGM2008, NAVD88) ; un code EPSG horizontal ne dit rien de la hauteur.

QA et validation

  • Après avoir défini ou transformé, superposez la couche sur une référence de confiance (un fond de carte national, un point de calage connu) et confirmez qu'elle atterrit où elle doit.
  • Mesurez une distance ou une surface connue dans le SCR de travail et comparez à une valeur publiée ; une grosse erreur signifie que le SCR est faux, pas la géométrie.
  • Inspectez les plages de coordonnées au regard des unités attendues du SCR avant de faire confiance aux métadonnées.
  • Notez le SCR source, le SCR de traitement et le SCR de sortie, ainsi que toute transformation de datum utilisée, dans les notes du projet ; epsg.io et projinfo EPSG:32631 (de PROJ) donnent la définition de référence.

Le point de vue Bathyl

Nous traitons le code EPSG comme un contrat, pas comme une étiquette : chaque couche qui entre dans un projet porte un code vérifié, et nous distinguons « définir le SCR » de « transformer le SCR » à chaque import, car les confondre est la source discrète de la plupart des données mal placées. Une chaîne de SCR documentée de la source à la sortie est ce qui permet à un second analyste de reproduire une mesure sans deviner.

Pour aller plus loin

Sources