Ricevi un set di punti GPS rilevati in WGS 84 e devi sovrapporli a un piano di sito proiettato in UTM Zone 50N. Incolli le coordinate e i punti finiscono in mezzo all'oceano, a migliaia di chilometri dalla posizione corretta. I numeri sembrano abbastanza simili da sembrare plausibili, ma i due sistemi di coordinate sono fondamentalmente incompatibili senza conversione. Convertire coordinate tra sistemi EPSG è una delle operazioni GIS più frequenti, e sbagliare produce errori che vanno dall'impercettibile (pochi metri) al catastrofico (un continente diverso).
La conversione di coordinate EPSG trasforma le coordinate puntuali da un sistema di riferimento a un altro utilizzando trasformazioni di datum e proiezioni cartografiche definite matematicamente. Di seguito: il codice per farlo in JavaScript, Python e dalla riga di comando, più gli errori che corrompono silenziosamente i tuoi dati.
Cos'è la conversione di coordinate e quando serve?
La conversione di coordinate riproietta i dati puntuali da un CRS a un altro. Serve ogni volta che combini dataset raccolti in sistemi di coordinate diversi, visualizzi dati GPS su una mappa web, converti tra coordinate geografiche (gradi) e proiettate (metri), o lavori con i sistemi di coordinate cinesi con offset come GCJ-02 e BD-09.
Due operazioni vengono spesso confuse. La conversione di coordinate cambia la proiezione cartografica restando sullo stesso datum, ad esempio convertendo coordinate geografiche WGS 84 (EPSG:4326) in WGS 84 / UTM Zone 50N (EPSG:32650). La trasformazione di coordinate cambia il datum stesso. Convertire NAD27 in WGS 84 richiede parametri di modello fisico perché i due datum definiscono la forma della Terra in modo diverso. La maggior parte delle librerie GIS gestisce entrambe le operazioni in modo trasparente, ma la distinzione conta quando stai facendo debug di problemi di precisione.
I cinque scenari in cui ti serve un convertitore di coordinate:
- Unire dataset da CRS diversi — un fornitore consegna dati topografici in una griglia nazionale (per esempio OSGB 1936, EPSG:27700) e devi combinarli con la tua baseline WGS 84.
- GPS su mappa web — l'output GPS grezzo è WGS 84 (gradi), ma le mappe web renderizzano in Web Mercator (metri). Ogni mappa a tile fa questa conversione sotto il cofano.
- Consegnare dati topografici nel CRS richiesto dal cliente — il sistema CAD del cliente si aspetta Lambert-93 (EPSG:2154); la tua strumentazione di campo registra in WGS 84.
- Lavorare con mappe cinesi — Amap, Tencent Maps e Baidu Maps usano ciascuno CRS proprietari con offset (GCJ-02 e BD-09) non intercambiabili con WGS 84.
- Conversioni tra zone UTM — un progetto si estende su due zone UTM e serve un unico CRS proiettato per calcoli coerenti di distanza e area.
Come convertire EPSG:4326 in EPSG:3857
Per convertire da EPSG:4326 (WGS 84, gradi) a EPSG:3857 (Web Mercator, metri), si applica la formula della proiezione di Mercatore. In JavaScript, usa proj4("EPSG:4326", "EPSG:3857", [lng, lat]). In Python, usa Transformer.from_crs("EPSG:4326", "EPSG:3857", always_xy=True). La conversione mappa longitudine/latitudine in easting/northing in metri.
Usando Pechino come esempio:
// 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'input è composto da due numeri piccoli (gradi). L'output è composto da due numeri grandi (metri dall'origine a 0°N, 0°E). È il comportamento atteso: Web Mercator misura la distanza dall'intersezione tra l'equatore e il meridiano di Greenwich.
Un dettaglio da tenere a mente: EPSG:3857 tronca a circa ±85,06° di latitudine. La proiezione di Mercatore mappa i poli all'infinito, quindi le coordinate sopra 85°N o sotto 85°S non possono essere rappresentate. Per dati artici e antartici serve una proiezione stereografica polare come EPSG:3413 (Nord) o EPSG:3031 (Sud).
Puoi verificare qualsiasi conversione al volo con il convertitore di coordinate di KunYu: incolla le coordinate, seleziona CRS sorgente e destinazione, e ottieni il risultato senza installare nulla.
Conversione tra due codici EPSG qualsiasi
Lo stesso schema funziona per qualsiasi coppia EPSG. Per i codici non inclusi di default, serve la definizione del CRS (una stringa proj4 o WKT). Librerie come proj4js richiedono di registrare le definizioni CRS personalizzate prima dell'uso; pyproj include l'intero database EPSG di serie.
JavaScript (proj4js)
Proj4js conosce solo EPSG:4326 e EPSG:3857 di base. Tutto il resto richiede una stringa di definizione, che puoi cercare su 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 punto che crea confusione: la stringa di definizione proj4 deve corrispondere esattamente. Una volta ho passato un'ora a fare debug di un offset di 3 metri in un dataset proiettato CGCS2000. Il problema era che il file .prj fornito con lo Shapefile usava una parametrizzazione dell'ellissoide leggermente diversa da quella riportata su epsg.io. La soluzione è stata copiare la stringa proj4 direttamente dal contenuto del .prj usando gdalsrsinfo input.shp, invece di cercare il codice EPSG e dare per scontato che la definizione corrispondesse. Quando la precisione conta, ricava sempre la definizione dai dati sorgente.
Python (pyproj)
Pyproj include l'intero database PROJ, quindi non serve mai registrare definizioni manualmente. Il parametro fondamentale è always_xy=True: senza di esso, pyproj segue l'ordine degli assi standard EPSG (latitudine per prima nei CRS geografici), il che scambia le coordinate silenziosamente.
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
Riga di comando (ogr2ogr)
Per la riproiezione di file Shapefile, GeoJSON o GeoPackage, ogr2ogr di GDAL è lo strumento standard. Gestisce la conversione batch di interi dataset in un solo comando.
# 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
Usa -s_srs per specificare il CRS sorgente esplicitamente quando il file di input non contiene metadati CRS (nessun file .prj o informazioni di proiezione incorporate). Se il CRS sorgente è già definito nel file, -t_srs da solo è sufficiente.
Convertire coordinate cinesi (WGS 84, GCJ-02, BD-09)
La Cina impone offset sulle coordinate in tutti i servizi cartografici pubblici. GCJ-02 ("Coordinate di Marte") sposta i punti WGS 84 di 100–700 metri usando un algoritmo non lineare basato sull'ellissoide di Krasovsky 1940. BD-09 aggiunge un ulteriore offset sopra GCJ-02. Non sono sistemi registrati EPSG, e gli strumenti standard come proj4 e pyproj non possono convertirli: servono algoritmi di offset dedicati.
Gli offset esistono perché la normativa topografica cinese impone che tutte le mappe digitali pubblicamente disponibili utilizzino un sistema di coordinate crittografato. La trasformazione diretta (WGS 84 → GCJ-02) è una formula deterministica. L'inversa (GCJ-02 → WGS 84) non ha soluzione in forma chiusa e richiede un'approssimazione iterativa, tipicamente 10 iterazioni per raggiungere una precisione sub-metrica (~0,1 m).
Quali servizi usano quale sistema:
| Servizio cartografico | Sistema di coordinate | Offset da WGS 84 |
|---|---|---|
| Google Maps (Cina) | GCJ-02 | 100–700 m |
| Amap (Gaode) | GCJ-02 | 100–700 m |
| Tencent Maps | GCJ-02 | 100–700 m |
| Apple Maps (Cina) | GCJ-02 | 100–700 m |
| Baidu Maps | BD-09 | 100–700 m + offset aggiuntivo |
| OpenStreetMap | WGS 84 | Nessuno |
La catena di conversione è: WGS 84 ↔ GCJ-02 ↔ BD-09. Convertire direttamente tra WGS 84 e BD-09 senza il passaggio intermedio GCJ-02 produce risultati errati. Il convertitore di coordinate di KunYu implementa la catena completa con algoritmi inversi iterativi, cosa che la maggior parte degli strumenti GIS internazionali non supporta.
Nella mia esperienza, l'offset è peggiore nella Cina occidentale: vicino a Urumqi ho visto scostamenti superiori a 600 metri, sufficienti a posizionare un punto di interesse dall'altra parte di un fiume o sul lato sbagliato di un'autostrada. Nelle città costiere orientali come Shanghai l'offset è minore (circa 200–300 metri) ma comunque troppo grande per essere ignorato. La trappola sottile è che l'offset varia in modo graduale su tutto il territorio, quindi non lo intercetti controllando un singolo punto: una conversione che "sembra corretta" a Pechino può essere visibilmente sbagliata a Chengdu.
Convertitore Coordinate
Converti coordinate tra sistemi EPSG con supporto batch e rilevamento intelligente.
Try it nowCinque errori comuni nella conversione di coordinate
Gli errori più frequenti nella conversione di coordinate sono: selezionare il CRS sorgente sbagliato, confondere l'ordine degli assi, usare Web Mercator per le misurazioni, ignorare le trasformazioni di datum e assumere che tutte le coordinate in gradi siano WGS 84. Ognuno produce risultati sottilmente sbagliati che possono passare inosservati fino a causare problemi reali a valle.
Selezione errata del CRS sorgente
Se i tuoi dati sorgente sono NAD83 (EPSG:4269) ma indichi al convertitore che sono WGS 84 (EPSG:4326), la differenza è solo di ~1–2 metri nella maggior parte del Nord America: facile da non notare nei test, significativa per lavori topografici di precisione. Confondere NAD27 con WGS 84 è peggio: offset di 10–200 metri a seconda della posizione, sufficienti a posizionare un edificio sul lato sbagliato di un confine di proprietà.
Confusione nell'ordine degli assi (lat/lon vs lon/lat)
La definizione formale di EPSG:4326 è latitudine per prima (lat, lng). Ma GeoJSON, proj4js, il costruttore L.latlng() di Leaflet (nonostante il nome) e la maggior parte delle librerie di web mapping si aspettano longitudine per prima (lng, lat). Se i punti convertiti si distribuiscono casualmente sulla mappa ma alla scala approssimativamente corretta, probabilmente hai scambiato lat e lon. Il parametro always_xy=True di pyproj esiste proprio per evitare questa trappola.
Usare Web Mercator per le misurazioni
EPSG:3857 è per la visualizzazione, non per il calcolo. Calcolare l'area in Web Mercator gonfia i risultati alle latitudini elevate: la Groenlandia appare 14 volte più grande di quanto sia realmente. Per calcoli di distanza e area, converti prima in un CRS proiettato locale (una zona UTM o una griglia nazionale) e poi misura.
Trasformazioni di datum mancanti
Convertire tra CRS che usano datum diversi, ad esempio da ED50 a ETRS89 in Europa, richiede una trasformazione di datum con parametri specifici. Usare una trasformazione generica o predefinita può introdurre errori di diversi metri. GDAL e pyproj gestiscono questo automaticamente quando i file di grid shift sono disponibili, ma è bene verificare il metodo di trasformazione utilizzato.
Assumere che tutte le coordinate in gradi siano WGS 84
Molti CRS geografici usano gradi: EPSG:4326 (WGS 84), EPSG:4269 (NAD83), EPSG:4490 (CGCS2000), EPSG:4612 (JGD2000). Un punto a 139.6917, 35.6895 potrebbe essere uno qualsiasi di questi: hanno lo stesso formato ma usano datum diversi. Controlla sempre i metadati sorgente prima di convertire.
Scegliere lo strumento giusto per la conversione di coordinate
Per conversioni singole o di piccoli lotti, gli strumenti nel browser sono i più rapidi: niente installazione, niente codice. Per la riproiezione di file, usa ogr2ogr o QGIS. Per pipeline programmatiche, proj4js (JavaScript) o pyproj (Python) si integrano direttamente nel codice. Per i CRS cinesi, la maggior parte degli strumenti internazionali non basta.
| Scenario | Strumento migliore | Perché |
|---|---|---|
| Verifica rapida di un singolo punto | Convertitore di coordinate KunYu | Nel browser, 6000+ EPSG, CRS cinesi inclusi |
| Riproiezione di file (SHP/GeoJSON) | ogr2ogr (GDAL) | Qualsiasi formato, elaborazione batch, scriptabile |
| Progetto QGIS | Strumento Riproietta Layer | Flusso di lavoro GUI, preserva attributi e stili |
| Web app JavaScript | proj4js | Lato client, ~100KB, nessun server necessario |
| Pipeline dati Python | pyproj | Database PROJ completo, compatibile con NumPy |
| CRS cinesi (GCJ-02/BD-09) | Convertitore di coordinate KunYu | Algoritmi di offset integrati che la maggior parte degli strumenti non ha |
Personalmente, uso ogr2ogr per default per qualsiasi operazione ripetibile. Una volta ho dovuto riproiettare oltre 200 file GeoJSON da un dataset municipale (tutti in una proiezione Lambert locale) a WGS 84 per un'applicazione web. In QGIS, sarebbero stati 200 clic manuali "Esporta → Salva come → Imposta CRS". Con ogr2ogr, è bastato un ciclo shell su una riga: for f in *.geojson; do ogr2ogr -t_srs EPSG:4326 out/"$f" "$f"; done — finito in meno di un minuto. QGIS è meglio quando devi verificare visivamente la riproiezione o quando il CRS sorgente non è incorporato nel file e devi provare qualche opzione in modo interattivo.
FAQ
Come converto EPSG:4326 in UTM?
Per prima cosa, determina in quale zona UTM cadono le tue coordinate: zona = floor((longitudine + 180) / 6) + 1. Poi converti usando il codice EPSG corrispondente: EPSG:326xx per l'emisfero Nord, EPSG:327xx per l'emisfero Sud, dove xx è il numero della zona. Ad esempio, Pechino a 116,4°E cade nella UTM Zone 50N, che è EPSG:32650.
Qual è la differenza tra conversione e trasformazione di coordinate?
La conversione di coordinate cambia la proiezione cartografica restando sullo stesso datum (es. WGS 84 geografico a WGS 84 / UTM). La trasformazione di coordinate cambia il datum stesso (es. NAD27 a WGS 84), operazione che richiede parametri di modello fisico. Strumenti GIS come pyproj e GDAL gestiscono entrambe in modo trasparente; la distinzione conta soprattutto per il debug di problemi di precisione.
Perché le mie coordinate convertite sono sfasate di centinaia di metri?
La causa più comune è un CRS sorgente errato. In Cina, confondere WGS 84 con GCJ-02 produce offset di 100–700 metri: è un comportamento voluto, non un bug. Al di fuori della Cina, confondere NAD27 con WGS 84 o usare parametri di trasformazione datum errati produce errori analoghi. Verifica sempre il CRS sorgente prima di convertire.
Posso convertire coordinate in blocco senza programmare?
Sì. Il convertitore di coordinate di KunYu accetta coordinate multiple (una per riga) per la conversione batch direttamente nel browser, senza registrazione e senza che i dati lascino il tuo dispositivo. Per la conversione in blocco di file Shapefile o GeoJSON, usa lo strumento format converter o ogr2ogr dalla riga di comando.
proj4js è lo stesso di PROJ?
No. PROJ è una libreria C/C++ per la trasformazione di coordinate mantenuta dalla comunità OSGeo, con un database di oltre 10.000 definizioni CRS e supporto per trasformazioni datum basate su griglie. Proj4js è un porting JavaScript che implementa gli stessi algoritmi core ma include solo EPSG:4326 e EPSG:3857 di default: tutte le altre definizioni CRS vanno registrate manualmente.
Da ricordare
Lo schema è sempre lo stesso: identifica il CRS sorgente, identifica il CRS di destinazione, applica la conversione. Per verifiche rapide, usa un convertitore online. Per la riproiezione a livello di file, scegli ogr2ogr. Per il codice applicativo, integra proj4js o pyproj. E se non sai quale codice EPSG ti serve, parti da Codici EPSG spiegati o cerca direttamente con lo strumento EPSG Search.