Vous recevez un jeu de points GPS levés en WGS 84 et devez les superposer sur un plan de site projeté en UTM Zone 50N. Vous collez les coordonnées, et les points se retrouvent au milieu de l'océan, à des milliers de kilomètres de leur position réelle. Les chiffres se ressemblent assez pour paraître crédibles, mais les systèmes de coordonnées sont fondamentalement incompatibles sans conversion. Convertir des coordonnées entre systèmes EPSG est l'une des opérations SIG les plus courantes, et une erreur produit des écarts allant de l'invisible (quelques mètres) au catastrophique (un autre continent).
La conversion de coordonnées EPSG transforme les coordonnées ponctuelles d'un système de référence à un autre en appliquant des transformations de datum et des projections cartographiques définies mathématiquement. Ci-dessous : le code pour le faire en JavaScript, Python et en ligne de commande, plus les erreurs qui corrompent silencieusement vos données.
Qu'est-ce que la conversion de coordonnées et quand en avez-vous besoin ?
La conversion de coordonnées reprojette les données ponctuelles d'un SRC vers un autre. Vous en avez besoin chaque fois que vous combinez des jeux de données collectés dans des systèmes de coordonnées différents, affichez des données GPS sur une carte web, convertissez entre coordonnées géographiques (degrés) et projetées (mètres), ou travaillez avec les systèmes de coordonnées décalés de la Chine comme GCJ-02 et BD-09.
Deux opérations sont souvent confondues. La conversion de coordonnées change la projection cartographique tout en restant sur le même datum, par exemple convertir les coordonnées géographiques WGS 84 (EPSG:4326) en WGS 84 / UTM Zone 50N (EPSG:32650). La transformation de coordonnées change le datum lui-même. Convertir NAD27 en WGS 84 implique des paramètres de modèle physique car les deux datums définissent la forme de la Terre différemment. La plupart des bibliothèques SIG gèrent les deux de manière automatique, mais la distinction compte lorsque vous déboguez des problèmes de précision.
Les cinq scénarios où vous aurez besoin d'un convertisseur de coordonnées :
- Fusionner des jeux de données provenant de SRC différents : un prestataire livre des données de levé dans un système national (par exemple OSGB 1936, EPSG:27700) et vous devez les combiner avec votre référentiel WGS 84.
- GPS vers carte web : la sortie GPS brute est en WGS 84 (degrés), mais les cartes web affichent en Web Mercator (mètres). Chaque carte tuilée effectue cette conversion en arrière-plan.
- Livrer des données de levé dans le SRC exigé par le client : le système CAO du client attend du Lambert-93 (EPSG:2154) ; votre équipement de terrain enregistre en WGS 84.
- Travailler avec les cartes chinoises : Amap, Tencent Maps et Baidu Maps utilisent chacun des SRC décalés propriétaires (GCJ-02 et BD-09) qui ne sont pas interchangeables avec WGS 84.
- Conversions entre zones UTM : un projet s'étend sur deux zones UTM, et vous avez besoin d'un seul SRC projeté pour des calculs cohérents de distance et de surface.
Comment convertir EPSG:4326 en EPSG:3857
Pour convertir EPSG:4326 (WGS 84, degrés) en EPSG:3857 (Web Mercator, mètres), appliquez la formule de projection Mercator. En JavaScript, utilisez proj4("EPSG:4326", "EPSG:3857", [lng, lat]). En Python, utilisez Transformer.from_crs("EPSG:4326", "EPSG:3857", always_xy=True). La conversion transforme longitude/latitude en abscisse/ordonnée en mètres.
Avec Pékin comme exemple :
// JavaScript — proj4js
import proj4 from "proj4";
const [easting, northing] = proj4(
"EPSG:4326",
"EPSG:3857",
[116.4074, 39.9042] // Beijing (lng, lat)
);
console.log(easting, northing);
// → 12958175.0, 4852834.1
# Python — pyproj
from pyproj import Transformer
transformer = Transformer.from_crs("EPSG:4326", "EPSG:3857", always_xy=True)
easting, northing = transformer.transform(116.4074, 39.9042)
print(easting, northing)
# → 12958175.0, 4852834.1
L'entrée est deux petits nombres (degrés). La sortie est deux grands nombres (mètres depuis l'origine à 0°N, 0°E). C'est normal : Web Mercator mesure la distance depuis l'intersection de l'équateur et du méridien de Greenwich.
Un point à surveiller : EPSG:3857 coupe à environ ±85,06° de latitude. La projection de Mercator projette les pôles à l'infini, donc les coordonnées au-delà de 85°N ou en dessous de 85°S ne peuvent pas être représentées. Les données arctiques et antarctiques nécessitent une projection stéréographique polaire comme EPSG:3413 (Nord) ou EPSG:3031 (Sud).
Vous pouvez vérifier n'importe quelle conversion instantanément dans le convertisseur de coordonnées de KunYu : collez les coordonnées, sélectionnez le SRC source et cible, et obtenez les résultats sans rien installer.
Convertir entre deux codes EPSG quelconques
Le même schéma fonctionne pour n'importe quelle paire EPSG. Pour les codes non intégrés, vous avez besoin de la définition du SRC (une chaîne proj4 ou WKT). Les bibliothèques comme proj4js exigent d'enregistrer les définitions de SRC personnalisées avant de les utiliser ; pyproj intègre la base de données EPSG complète.
JavaScript (proj4js)
Proj4js ne connaît que EPSG:4326 et EPSG:3857 par défaut. Tout le reste nécessite une chaîne de définition, que vous pouvez trouver sur epsg.io.
import proj4 from "proj4";
// Register Lambert-93 (France) — definition from epsg.io/2154
proj4.defs(
"EPSG:2154",
"+proj=lcc +lat_1=49 +lat_2=44 +lat_0=46.5 +lon_0=3 " +
"+x_0=700000 +y_0=6600000 +ellps=GRS80 +units=m +no_defs"
);
// WGS 84 → Lambert-93
const [x, y] = proj4("EPSG:4326", "EPSG:2154", [2.3522, 48.8566]);
console.log(x, y);
// → 652469.5, 6862035.9 (Paris in Lambert-93 meters)
Un piège classique : la chaîne de définition proj4 doit correspondre exactement. J'ai passé une heure à déboguer un décalage de 3 mètres sur un jeu de données projeté en CGCS2000 : le fichier .prj livré avec le Shapefile utilisait une paramétrisation d'ellipsoïde légèrement différente de celle listée sur epsg.io. La solution a été de copier la chaîne proj4 directement depuis le contenu du .prj avec gdalsrsinfo input.shp plutôt que de chercher le code EPSG en supposant que la définition correspondrait. Quand la précision compte, dérivez toujours la définition depuis les données source elles-mêmes.
Python (pyproj)
Pyproj intègre la base de données PROJ complète, vous n'avez donc jamais besoin d'enregistrer des définitions manuellement. Le paramètre critique est always_xy=True : sans lui, pyproj suit l'ordre des axes standard EPSG (latitude en premier pour les SRC géographiques), ce qui inverse vos coordonnées silencieusement.
from pyproj import Transformer
# pyproj knows all EPSG codes — no manual registration
transformer = Transformer.from_crs("EPSG:4326", "EPSG:2154", always_xy=True)
x, y = transformer.transform(2.3522, 48.8566)
print(x, y)
# → 652469.5, 6862035.9
Ligne de commande (ogr2ogr)
Pour la reprojection de fichiers Shapefiles, GeoJSON ou GeoPackage, ogr2ogr de GDAL est l'outil standard. Il gère la conversion par lots de jeux de données entiers en une seule commande.
# Reproject a GeoJSON from WGS 84 to UTM Zone 50N
ogr2ogr -t_srs EPSG:32650 output.geojson input.geojson
# Reproject a Shapefile from OSGB 1936 to WGS 84
ogr2ogr -s_srs EPSG:27700 -t_srs EPSG:4326 output.shp input.shp
Utilisez -s_srs pour spécifier explicitement le SRC source lorsque le fichier d'entrée ne contient pas de métadonnées SRC (pas de fichier .prj ni d'information de projection intégrée). Si le SRC source est déjà défini dans le fichier, -t_srs seul suffit.
Convertir les coordonnées chinoises (WGS 84, GCJ-02, BD-09)
La Chine impose des décalages de coordonnées sur tous les services cartographiques publics. GCJ-02 (« coordonnées Mars ») décale les points WGS 84 de 100 à 700 mètres à l'aide d'un algorithme non linéaire basé sur l'ellipsoïde de Krasovsky 1940. BD-09 ajoute un décalage supplémentaire par-dessus GCJ-02. Ce ne sont pas des systèmes enregistrés EPSG, et les outils standards comme proj4 et pyproj ne peuvent pas les convertir : il faut des algorithmes de décalage spécifiques.
Ces décalages existent parce que la réglementation chinoise en matière de cartographie exige que toutes les cartes numériques accessibles au public utilisent un système de coordonnées chiffré. La transformation directe (WGS 84 → GCJ-02) est une formule déterministe. La transformation inverse (GCJ-02 → WGS 84) n'a pas de solution analytique et nécessite une approximation itérative, typiquement 10 itérations pour atteindre une précision sub-métrique (~0,1 m).
Quels services utilisent quel système :
| Service cartographique | Système de coordonnées | Décalage par rapport à WGS 84 |
|---|---|---|
| Google Maps (Chine) | GCJ-02 | 100–700 m |
| Amap (Gaode) | GCJ-02 | 100–700 m |
| Tencent Maps | GCJ-02 | 100–700 m |
| Apple Maps (Chine) | GCJ-02 | 100–700 m |
| Baidu Maps | BD-09 | 100–700 m + décalage supplémentaire |
| OpenStreetMap | WGS 84 | Aucun |
La chaîne de conversion est : WGS 84 ↔ GCJ-02 ↔ BD-09. Convertir directement entre WGS 84 et BD-09 sans l'étape intermédiaire GCJ-02 produit des résultats incorrects. Le convertisseur de coordonnées de KunYu implémente la chaîne complète avec des algorithmes inverses itératifs, ce que la plupart des outils SIG internationaux ne prennent pas en charge.
D'expérience, le décalage est le plus prononcé dans l'ouest de la Chine : près d'Urumqi, j'ai constaté des écarts dépassant 600 mètres, suffisants pour placer un point d'intérêt de l'autre côté d'une rivière ou du mauvais côté d'une autoroute. Dans les villes côtières de l'est comme Shanghai, le décalage est plus faible (environ 200–300 mètres) mais reste bien trop important pour être ignoré. Le piège subtil, c'est que le décalage varie de manière continue sur l'ensemble du territoire : une conversion qui « semble correcte » à Pékin peut être nettement fausse à Chengdu.
Convertisseur de coordonnées
Convertir les coordonnées entre les systèmes EPSG avec traitement par lots et détection intelligente.
Try it nowCinq erreurs courantes de conversion de coordonnées
Les erreurs de conversion les plus fréquentes sont : sélectionner le mauvais SRC source, confondre l'ordre des axes, utiliser Web Mercator pour des mesures, ignorer les transformations de datum et supposer que toutes les coordonnées en degrés sont en WGS 84. Chacune produit des résultats subtilement erronés qui peuvent passer inaperçus jusqu'à causer de vrais problèmes en aval.
Mauvaise sélection du SRC source
Si vos données source sont en NAD83 (EPSG:4269) mais que vous indiquez au convertisseur qu'elles sont en WGS 84 (EPSG:4326), la différence n'est que de ~1–2 mètres dans la majeure partie de l'Amérique du Nord. Facile à manquer en test, significatif pour du travail de précision topographique. Confondre NAD27 avec WGS 84 est pire : des décalages de 10 à 200 mètres selon la localisation, assez pour placer un bâtiment du mauvais côté d'une limite parcellaire.
Confusion sur l'ordre des axes (lat/lon vs lon/lat)
La définition formelle d'EPSG:4326 est latitude en premier (lat, lng). Mais GeoJSON, proj4js, le constructeur L.latlng() de Leaflet (malgré le nom), et la plupart des bibliothèques de cartographie web attendent longitude en premier (lng, lat). Si vos points convertis se dispersent aléatoirement sur la carte mais à une échelle globalement correcte, vous avez probablement inversé lat et lon. Le paramètre always_xy=True de pyproj existe précisément pour éviter ce piège.
Utiliser Web Mercator pour les mesures
EPSG:3857 sert à l'affichage, pas au calcul. Calculer une surface en Web Mercator gonfle les résultats aux latitudes élevées : le Groenland apparaît 14 fois plus grand qu'il ne l'est réellement. Pour les calculs de distance et de surface, convertissez d'abord vers un SRC projeté local (une zone UTM ou un système national), puis mesurez.
Transformations de datum manquantes
Convertir entre SRC qui utilisent des datums différents (par exemple ED50 vers ETRS89 en Europe) nécessite une transformation de datum avec des paramètres spécifiques. Utiliser une transformation générique ou par défaut peut introduire des erreurs de plusieurs mètres. GDAL et pyproj gèrent cela automatiquement lorsque les fichiers de grille sont disponibles, mais vous devez vérifier la méthode de transformation utilisée.
Supposer que toutes les coordonnées en degrés sont en WGS 84
De nombreux SRC géographiques utilisent les degrés : EPSG:4326 (WGS 84), EPSG:4269 (NAD83), EPSG:4490 (CGCS2000), EPSG:4612 (JGD2000). Un point à 139.6917, 35.6895 pourrait être n'importe lequel d'entre eux : le format est identique mais les datums diffèrent. Vérifiez toujours les métadonnées source avant de convertir.
Choisir le bon outil de conversion de coordonnées
Pour les conversions ponctuelles ou en petit lot, les outils en ligne sont les plus rapides : aucune installation, pas de code. Pour la reprojection de fichiers, utilisez ogr2ogr ou QGIS. Pour les pipelines programmatiques, proj4js (JavaScript) ou pyproj (Python) s'intègrent directement dans votre code. Pour les SRC chinois, la plupart des outils internationaux ne suffisent pas.
| Scénario | Meilleur outil | Pourquoi |
|---|---|---|
| Vérification rapide d'un point | Convertisseur de coordonnées KunYu | Dans le navigateur, 6000+ EPSG, SRC chinois inclus |
| Reprojection de fichiers (SHP/GeoJSON) | ogr2ogr (GDAL) | Tous formats, traitement par lots, scriptable |
| Projet QGIS | Outil Reprojeter la couche | Flux de travail graphique, préserve attributs et styles |
| Application web JavaScript | proj4js | Côté client, ~100 Ko, pas de serveur nécessaire |
| Pipeline de données Python | pyproj | Base PROJ complète, compatible NumPy |
| SRC chinois (GCJ-02/BD-09) | Convertisseur de coordonnées KunYu | Algorithmes de décalage intégrés absents de la plupart des outils |
Pour ma part, je choisis ogr2ogr par défaut pour tout ce qui est répétitif. J'ai dû une fois reprojeter plus de 200 fichiers GeoJSON d'un jeu de données municipal (tous en projection Lambert locale) vers WGS 84 pour une application web. Dans QGIS, cela représente 200 clics manuels « Exporter → Enregistrer sous → Définir le SRC ». Avec ogr2ogr, c'est une boucle shell d'une ligne : for f in *.geojson; do ogr2ogr -t_srs EPSG:4326 out/"$f" "$f"; done : terminé en moins d'une minute. QGIS reste préférable quand vous devez vérifier visuellement la reprojection ou quand le SRC source n'est pas intégré au fichier et que vous devez tester plusieurs options de façon interactive.
Recherche EPSG
Rechercher et parcourir la base de données des systèmes de référence de coordonnées EPSG.
Try it nowFAQ
Comment convertir EPSG:4326 en UTM ?
Déterminez d'abord dans quelle zone UTM se trouvent vos coordonnées : zone = floor((longitude + 180) / 6) + 1. Convertissez ensuite en utilisant le code EPSG correspondant : EPSG:326xx pour l'hémisphère Nord, EPSG:327xx pour l'hémisphère Sud, où xx est le numéro de zone. Par exemple, Pékin à 116,4°E se situe en UTM Zone 50N, soit EPSG:32650.
Quelle est la différence entre conversion de coordonnées et transformation de coordonnées ?
La conversion de coordonnées change la projection cartographique tout en restant sur le même datum (ex. WGS 84 géographique vers WGS 84 / UTM). La transformation de coordonnées change le datum lui-même (ex. NAD27 vers WGS 84), ce qui implique des paramètres de modèle physique. Les outils SIG comme pyproj et GDAL gèrent les deux de manière automatique : la distinction importe principalement lors du débogage de problèmes de précision.
Pourquoi mes coordonnées converties sont-elles décalées de centaines de mètres ?
La cause la plus fréquente est un mauvais SRC source. En Chine, mélanger WGS 84 et GCJ-02 produit des décalages de 100 à 700 mètres : c'est par conception, pas un bug. Hors de Chine, confondre NAD27 avec WGS 84 ou utiliser des paramètres de transformation de datum incorrects produit des erreurs similaires. Vérifiez toujours votre SRC source avant de convertir.
Puis-je convertir des coordonnées en masse sans coder ?
Oui. Le convertisseur de coordonnées de KunYu accepte plusieurs coordonnées (une par ligne) pour la conversion par lots directement dans le navigateur, sans inscription et vos données ne quittent jamais votre appareil. Pour la conversion en masse de Shapefiles ou GeoJSON à partir de fichiers, utilisez le convertisseur de format ou ogr2ogr en ligne de commande.
Est-ce que proj4js est la même chose que PROJ ?
Non. PROJ est une bibliothèque C/C++ de transformation de coordonnées maintenue par la communauté OSGeo, avec une base de données de plus de 10 000 définitions SRC et la prise en charge des transformations de datum par grille. Proj4js est un portage JavaScript qui implémente les mêmes algorithmes fondamentaux mais n'inclut que EPSG:4326 et EPSG:3857 par défaut : toutes les autres définitions SRC doivent être enregistrées manuellement.
Ce qu'il faut retenir
Le schéma est toujours le même : identifiez votre SRC source, identifiez votre SRC cible, appliquez la conversion. Pour des vérifications rapides, utilisez un convertisseur en ligne. Pour la reprojection de fichiers, optez pour ogr2ogr. Pour le code applicatif, intégrez proj4js ou pyproj. Et si vous ne savez pas quel code EPSG utiliser, commencez par Les codes EPSG expliqués ou cherchez directement avec l'outil Recherche EPSG.