Recibes un conjunto de puntos GPS en WGS 84 y necesitas superponerlos sobre un plano de obra proyectado en UTM Zone 50N. Pegas las coordenadas y los puntos caen en medio del océano, a miles de kilómetros de donde deberían estar. Los números se parecen lo suficiente como para casi fiarte, pero los sistemas de coordenadas son incompatibles sin conversión. Convertir coordenadas entre sistemas EPSG es una de las operaciones GIS más frecuentes, y hacerlo mal produce errores que van desde imperceptibles (unos metros) hasta catastróficos (otro continente).
La conversión de coordenadas EPSG transforma puntos de un sistema de referencia de coordenadas a otro mediante transformaciones de datum y proyecciones cartográficas definidas matemáticamente. A continuación: el código para hacerlo en JavaScript, Python y línea de comandos, más los errores que corrompen tus datos en silencio.
¿Qué es la conversión de coordenadas y cuándo la necesitas?
La conversión de coordenadas reproyecta datos puntuales de un CRS a otro. La necesitas cuando combinas conjuntos de datos capturados en distintos sistemas de coordenadas, muestras datos GPS en un mapa web, conviertes entre coordenadas geográficas (grados) y proyectadas (metros), o trabajas con los sistemas de coordenadas desplazados de China como GCJ-02 y BD-09.
Dos operaciones que se confunden a menudo. La conversión de coordenadas cambia la proyección cartográfica manteniéndose en el mismo datum, por ejemplo pasar de WGS 84 geográfico (EPSG:4326) a WGS 84 / UTM Zone 50N (EPSG:32650). La transformación de coordenadas cambia el datum en sí. Convertir NAD27 a WGS 84 requiere parámetros de un modelo físico porque ambos datums definen la forma de la Tierra de manera diferente. La mayoría de las bibliotecas GIS gestionan ambas de forma transparente, pero la distinción importa cuando estás depurando problemas de precisión.
Los cinco escenarios en los que necesitarás un conversor de coordenadas:
- Fusionar datasets de distintos CRS — un contratista entrega datos topográficos en una cuadrícula nacional (por ejemplo OSGB 1936, EPSG:27700) y necesitas combinarlos con tu base en WGS 84.
- GPS a mapa web — la salida cruda del GPS es WGS 84 (grados), pero los mapas web renderizan en Web Mercator (metros). Cada mapa de teselas hace esta conversión internamente.
- Entregar datos topográficos en el CRS requerido por el cliente — el sistema CAD del cliente espera Lambert-93 (EPSG:2154); vuestro equipo de campo registra en WGS 84.
- Trabajar con mapas de China — Amap, Tencent Maps y Baidu Maps usan CRS desplazados propietarios (GCJ-02 y BD-09) que no son intercambiables con WGS 84.
- Conversiones entre zonas UTM — un proyecto abarca dos zonas UTM y necesitas un único CRS proyectado para cálculos consistentes de distancia y superficie.
Cómo convertir EPSG:4326 a EPSG:3857
Para convertir de EPSG:4326 (WGS 84, grados) a EPSG:3857 (Web Mercator, metros), se aplica la fórmula de proyección Mercator. En JavaScript, usa proj4("EPSG:4326", "EPSG:3857", [lng, lat]). En Python, usa Transformer.from_crs("EPSG:4326", "EPSG:3857", always_xy=True). La conversión transforma longitud/latitud a easting/northing en metros.
Usando Pekín como ejemplo:
// 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
La entrada son dos números pequeños (grados). La salida son dos números grandes (metros desde el origen en 0°N, 0°E). Esto es esperable: Web Mercator mide la distancia desde la intersección del ecuador con el meridiano de Greenwich.
Un detalle a tener en cuenta: EPSG:3857 recorta en aproximadamente ±85,06° de latitud. La proyección Mercator lleva los polos al infinito, así que las coordenadas por encima de 85°N o por debajo de 85°S no se pueden representar. Los datos del Ártico y la Antártida requieren una proyección estereográfica polar como EPSG:3413 (Norte) o EPSG:3031 (Sur).
Podéis verificar cualquier conversión al instante en el conversor de coordenadas de KunYu: pegad las coordenadas, seleccionad CRS de origen y destino, y obtened el resultado sin instalar nada.
Convertir entre dos códigos EPSG cualesquiera
El mismo patrón funciona para cualquier par EPSG. Para códigos que no vienen preconfigurados, necesitas la definición del CRS (una cadena proj4 o WKT). Bibliotecas como proj4js requieren registrar las definiciones de CRS manualmente antes de usarlas; pyproj incluye la base de datos EPSG completa de serie.
JavaScript (proj4js)
Proj4js solo conoce EPSG:4326 y EPSG:3857 de serie. Todo lo demás necesita una cadena de definición, que podéis buscar en 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)
Algo que pilla desprevenidos a muchos: la cadena de definición proj4 tiene que coincidir exactamente. Una vez pasé una hora depurando un desplazamiento de 3 metros en un dataset proyectado con CGCS2000; resultó que el archivo .prj incluido con el Shapefile usaba una parametrización del elipsoide ligeramente distinta a la que listaba epsg.io. La solución fue copiar la cadena proj4 directamente del contenido del .prj usando gdalsrsinfo input.shp, en lugar de buscar el código EPSG y asumir que la definición coincidiría. Cuando la precisión importa, derivad siempre la definición a partir de los propios datos de origen.
Python (pyproj)
Pyproj incluye la base de datos completa de PROJ, así que nunca necesitas registrar definiciones manualmente. El parámetro crítico es always_xy=True: sin él, pyproj sigue el orden de ejes estándar EPSG (latitud primero para CRS geográficos), lo que intercambia las coordenadas en silencio.
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
Línea de comandos (ogr2ogr)
Para reproyección de archivos Shapefile, GeoJSON o GeoPackage, ogr2ogr de GDAL es la herramienta estándar. Gestiona la conversión por lotes de datasets completos en 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
Usad -s_srs para especificar el CRS de origen explícitamente cuando el archivo de entrada carece de metadatos de CRS (sin archivo .prj o sin información de proyección incrustada). Si el CRS de origen ya está definido en el archivo, -t_srs solo es suficiente.
Conversión de coordenadas de China (WGS 84, GCJ-02, BD-09)
China obliga a aplicar desplazamientos de coordenadas en todos los servicios de mapas públicos. GCJ-02 ("Coordenadas de Marte") desplaza los puntos WGS 84 entre 100 y 700 metros mediante un algoritmo no lineal basado en el elipsoide de Krasovsky 1940. BD-09 añade un desplazamiento adicional sobre GCJ-02. No son sistemas registrados en EPSG, y las herramientas estándar como proj4 y pyproj no pueden convertirlos: se necesitan algoritmos de offset específicos.
Los desplazamientos existen porque la normativa topográfica china exige que todos los mapas digitales públicos usen un sistema de coordenadas cifrado. La transformación directa (WGS 84 → GCJ-02) es una fórmula determinista. La inversa (GCJ-02 → WGS 84) no tiene solución analítica y requiere aproximación iterativa, típicamente 10 iteraciones para alcanzar precisión submétrica (~0,1 m).
Qué servicios usan cada sistema:
| Servicio de mapas | Sistema de coordenadas | Desplazamiento respecto a WGS 84 |
|---|---|---|
| Google Maps (China) | GCJ-02 | 100–700 m |
| Amap (Gaode) | GCJ-02 | 100–700 m |
| Tencent Maps | GCJ-02 | 100–700 m |
| Apple Maps (China) | GCJ-02 | 100–700 m |
| Baidu Maps | BD-09 | 100–700 m + desplazamiento adicional |
| OpenStreetMap | WGS 84 | Ninguno |
La cadena de conversión es: WGS 84 ↔ GCJ-02 ↔ BD-09. Convertir directamente entre WGS 84 y BD-09 sin el paso intermedio por GCJ-02 produce resultados incorrectos. El conversor de coordenadas de KunYu implementa la cadena completa con algoritmos inversos iterativos, algo que la mayoría de herramientas GIS internacionales no soportan.
En mi experiencia, el desplazamiento es peor en el oeste de China: cerca de Urumqi he visto desviaciones superiores a 600 metros, suficiente para colocar un punto de interés al otro lado de un río o en el lado equivocado de una autovía. En ciudades costeras del este como Shanghái el desplazamiento es menor (unos 200–300 metros) pero sigue siendo demasiado grande para ignorarlo. La trampa sutil es que el desplazamiento varía de forma suave por todo el país, así que no lo detectaréis comprobando un solo punto: una conversión que "parece correcta" en Pekín puede ser notablemente errónea en Chengdu.
Conversor de Coordenadas
Convierte coordenadas entre sistemas EPSG con soporte por lotes y detección inteligente.
Try it nowCinco errores frecuentes en la conversión de coordenadas
Los errores de conversión de coordenadas más frecuentes son: seleccionar el CRS de origen incorrecto, confundir el orden de los ejes, usar Web Mercator para mediciones, ignorar las transformaciones de datum y asumir que todas las coordenadas en grados son WGS 84. Cada uno produce resultados sutilmente incorrectos que pueden pasar desapercibidos hasta causar problemas reales.
Selección incorrecta del CRS de origen
Si vuestros datos de origen son NAD83 (EPSG:4269) pero le decís al conversor que son WGS 84 (EPSG:4326), la diferencia es solo de ~1–2 metros en la mayor parte de Norteamérica: fácil de pasar por alto en pruebas, significativa para trabajo topográfico de precisión. Confundir NAD27 con WGS 84 es peor: desplazamientos de 10 a 200 metros según la ubicación, suficiente para colocar un edificio al otro lado de un linde de parcela.
Confusión en el orden de los ejes (lat/lon vs lon/lat)
La definición formal de EPSG:4326 es latitud primero (lat, lng). Pero GeoJSON, proj4js, el constructor L.latlng() de Leaflet (a pesar del nombre) y la mayoría de bibliotecas de mapas web esperan longitud primero (lng, lat). Si los puntos convertidos se dispersan aleatoriamente por el mapa pero a una escala aproximadamente correcta, probablemente habéis intercambiado lat y lon. El parámetro always_xy=True de pyproj existe específicamente para evitar esta trampa.
Usar Web Mercator para mediciones
EPSG:3857 es para visualización, no para cálculos. Calcular superficies en Web Mercator infla los resultados en latitudes altas: Groenlandia aparece 14 veces más grande de lo que realmente es. Para cálculos de distancia y superficie, convertid primero a un CRS proyectado local (una zona UTM o una cuadrícula nacional) y luego medid.
Transformaciones de datum omitidas
Convertir entre CRS que usan datums diferentes, por ejemplo ED50 a ETRS89 en Europa, requiere una transformación de datum con parámetros específicos. Usar una transformación genérica o por defecto puede introducir errores de varios metros. GDAL y pyproj lo gestionan automáticamente cuando hay archivos de rejilla disponibles, pero conviene verificar el método de transformación utilizado.
Asumir que todas las coordenadas en grados son WGS 84
Muchos CRS geográficos usan grados: EPSG:4326 (WGS 84), EPSG:4269 (NAD83), EPSG:4490 (CGCS2000), EPSG:4612 (JGD2000). Un punto en 139.6917, 35.6895 podría ser cualquiera de ellos: tienen un formato idéntico pero usan datums diferentes. Comprobad siempre los metadatos del origen antes de convertir.
Elegir la herramienta adecuada para la conversión de coordenadas
Para conversiones puntuales o de pequeños lotes, las herramientas en el navegador son las más rápidas: sin instalación, sin código. Para reproyectar archivos, usad ogr2ogr o QGIS. Para pipelines programáticos, proj4js (JavaScript) o pyproj (Python) se integran directamente en vuestro código. Para CRS de China, la mayoría de herramientas internacionales se quedan cortas.
| Escenario | Mejor herramienta | Por qué |
|---|---|---|
| Verificación rápida de un punto | Conversor de coordenadas de KunYu | En el navegador, 6000+ EPSG, CRS de China incluidos |
| Reproyección de archivos (SHP/GeoJSON) | ogr2ogr (GDAL) | Cualquier formato, procesamiento por lotes, scriptable |
| Proyecto QGIS | Herramienta Reproyectar Capa | Flujo GUI, conserva atributos y estilos |
| Aplicación web JavaScript | proj4js | Del lado del cliente, ~100 KB, sin servidor |
| Pipeline de datos Python | pyproj | Base de datos PROJ completa, compatible con NumPy |
| CRS de China (GCJ-02/BD-09) | Conversor de coordenadas de KunYu | Algoritmos de offset integrados que la mayoría no tiene |
Personalmente, recurro a ogr2ogr para cualquier tarea repetible. Una vez tuve que reproyectar más de 200 archivos GeoJSON de un dataset municipal (todos en una proyección Lambert local) a WGS 84 para una aplicación web. En QGIS, eso son 200 clics manuales de "Exportar → Guardar como → Definir CRS". Con ogr2ogr fue un bucle de una línea: for f in *.geojson; do ogr2ogr -t_srs EPSG:4326 out/"$f" "$f"; done, listo en menos de un minuto. QGIS es mejor cuando necesitas verificar visualmente la reproyección o cuando el CRS de origen no está incrustado en el archivo y tienes que probar varias opciones de forma interactiva.
Búsqueda EPSG
Busca y explora la base de datos de sistemas de referencia de coordenadas EPSG.
Try it nowPreguntas frecuentes
¿Cómo convierto EPSG:4326 a UTM?
Primero, determinad en qué zona UTM caen vuestras coordenadas: zone = floor((longitude + 180) / 6) + 1. Luego convertid usando el código EPSG correspondiente: EPSG:326xx para el hemisferio norte, EPSG:327xx para el hemisferio sur, donde xx es el número de zona. Por ejemplo, Pekín a 116,4°E cae en UTM Zone 50N, que es EPSG:32650.
¿Cuál es la diferencia entre conversión y transformación de coordenadas?
La conversión de coordenadas cambia la proyección cartográfica manteniéndose en el mismo datum (ej. WGS 84 geográfico a WGS 84 / UTM). La transformación de coordenadas cambia el datum en sí (ej. NAD27 a WGS 84), lo que implica parámetros de un modelo físico. Herramientas GIS como pyproj y GDAL gestionan ambas de forma transparente; la distinción importa principalmente al depurar problemas de precisión.
¿Por qué mis coordenadas convertidas están desplazadas cientos de metros?
La causa más habitual es un CRS de origen incorrecto. En China, mezclar WGS 84 con GCJ-02 produce desplazamientos de 100–700 metros (es así por diseño, no es un bug). Fuera de China, confundir NAD27 con WGS 84 o usar parámetros de transformación de datum incorrectos produce errores similares. Verificad siempre el CRS de origen antes de convertir.
¿Puedo convertir coordenadas en lote sin programar?
Sí. El conversor de coordenadas de KunYu acepta múltiples coordenadas (una por línea) para conversión por lotes directamente en el navegador, sin registro y sin que vuestros datos salgan del dispositivo. Para conversión masiva basada en archivos Shapefile o GeoJSON, usad el conversor de formatos o ogr2ogr en línea de comandos.
¿Es proj4js lo mismo que PROJ?
No. PROJ es una biblioteca de transformación de coordenadas en C/C++ mantenida por la comunidad OSGeo, con una base de datos de más de 10.000 definiciones de CRS y soporte para transformaciones de datum basadas en rejillas. Proj4js es un port a JavaScript que implementa los mismos algoritmos básicos pero solo incluye EPSG:4326 y EPSG:3857 por defecto; el resto de definiciones de CRS deben registrarse manualmente.
Qué recordar
El patrón es siempre el mismo: identifica tu CRS de origen, identifica tu CRS de destino, aplica la conversión. Para verificaciones rápidas, usa un conversor online. Para reproyección a nivel de archivo, recurre a ogr2ogr. Para código de aplicación, integra proj4js o pyproj. Y si no tienes claro qué código EPSG necesitas, empieza por Códigos EPSG explicados o busca directamente con la herramienta EPSG Search.