Você recebe um conjunto de pontos GPS levantados em WGS 84 e precisa sobrepô-los a um plano de obra projetado em UTM Zone 50N. Cola as coordenadas e os pontos caem no meio do oceano, a milhares de quilômetros da posição correta. Os números são parecidos o suficiente para parecerem plausíveis, mas os dois sistemas de coordenadas são fundamentalmente incompatíveis sem conversão. Converter coordenadas entre sistemas EPSG é uma das operações GIS mais comuns, e errar produz resultados que vão do imperceptível (poucos metros) ao catastrófico (um continente diferente).
A conversão de coordenadas EPSG transforma coordenadas de pontos de um sistema de referência para outro usando transformações de datum e projeções cartográficas definidas matematicamente. Abaixo: o código para fazer isso em JavaScript, Python e na linha de comando, mais os erros que corrompem seus dados silenciosamente.
O que é conversão de coordenadas e quando você precisa?
A conversão de coordenadas reprojeta dados pontuais de um SRC para outro. Você precisa dela sempre que combina datasets coletados em sistemas de coordenadas diferentes, exibe dados GPS em um mapa web, converte entre coordenadas geográficas (graus) e projetadas (metros), ou trabalha com os sistemas de coordenadas chineses com offset como GCJ-02 e BD-09.
Duas operações costumam ser confundidas. A conversão de coordenadas muda a projeção cartográfica permanecendo no mesmo datum, por exemplo convertendo coordenadas geográficas WGS 84 (EPSG:4326) para WGS 84 / UTM Zone 50N (EPSG:32650). A transformação de coordenadas muda o datum em si. Converter NAD27 para WGS 84 exige parâmetros de modelo físico porque os dois datums definem a forma da Terra de maneira diferente. A maioria das bibliotecas GIS lida com ambas de forma transparente, mas a distinção importa quando você está depurando problemas de precisão.
Os cinco cenários em que você vai precisar de um conversor de coordenadas:
- Unir datasets de SRC diferentes — um fornecedor entrega dados topográficos em uma grade nacional (digamos OSGB 1936, EPSG:27700) e você precisa combiná-los com sua baseline WGS 84.
- GPS para mapa web — a saída bruta do GPS é WGS 84 (graus), mas mapas web renderizam em Web Mercator (metros). Todo mapa baseado em tiles faz essa conversão por baixo dos panos.
- Entregar dados topográficos no SRC exigido pelo cliente — o sistema CAD do cliente espera Lambert-93 (EPSG:2154); seu equipamento de campo registra em WGS 84.
- Trabalhar com mapas chineses — Amap, Tencent Maps e Baidu Maps usam, cada um, SRC proprietários com offset (GCJ-02 e BD-09) que não são intercambiáveis com WGS 84.
- Conversões entre zonas UTM — um projeto abrange duas zonas UTM e você precisa de um único SRC projetado para cálculos consistentes de distância e área.
Como converter EPSG:4326 para EPSG:3857
Para converter de EPSG:4326 (WGS 84, graus) para EPSG:3857 (Web Mercator, metros), aplique a fórmula da projeção de Mercator. Em JavaScript, use proj4("EPSG:4326", "EPSG:3857", [lng, lat]). Em Python, use Transformer.from_crs("EPSG:4326", "EPSG:3857", always_xy=True). A conversão mapeia longitude/latitude para easting/northing em metros.
Usando Pequim como exemplo:
// 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
A entrada são dois números pequenos (graus). A saída são dois números grandes (metros a partir da origem em 0°N, 0°E). É o comportamento esperado: Web Mercator mede a distância a partir da interseção do equador com o meridiano de Greenwich.
Um detalhe para ficar atento: EPSG:3857 corta em aproximadamente ±85,06° de latitude. A projeção de Mercator mapeia os polos para o infinito, então coordenadas acima de 85°N ou abaixo de 85°S não podem ser representadas. Dados do Ártico e da Antártica exigem uma projeção estereográfica polar como EPSG:3413 (Norte) ou EPSG:3031 (Sul).
Você pode verificar qualquer conversão instantaneamente no conversor de coordenadas do KunYu: cole as coordenadas, selecione SRC de origem e destino, e obtenha o resultado sem instalar nada.
Conversão entre dois códigos EPSG quaisquer
O mesmo padrão funciona para qualquer par EPSG. Para códigos que não vêm embutidos, você precisa da definição do SRC (uma string proj4 ou WKT). Bibliotecas como proj4js exigem que você registre definições de SRC customizadas antes de usá-las; pyproj já inclui o banco de dados EPSG completo.
JavaScript (proj4js)
Proj4js conhece apenas EPSG:4326 e EPSG:3857 de fábrica. Todo o resto precisa de uma string de definição, que você pode consultar em 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)
Um ponto que pega muita gente: a string de definição proj4 precisa bater exatamente. Uma vez passei uma hora depurando um offset de 3 metros em um dataset projetado em CGCS2000. O problema era que o arquivo .prj que veio com o Shapefile usava uma parametrização de elipsoide ligeiramente diferente da listada no epsg.io. A solução foi copiar a string proj4 diretamente do conteúdo do .prj usando gdalsrsinfo input.shp, em vez de buscar o código EPSG e assumir que a definição seria idêntica. Quando a precisão importa, sempre derive a definição dos dados de origem.
Python (pyproj)
Pyproj traz o banco de dados PROJ completo, então você nunca precisa registrar definições manualmente. O parâmetro fundamental é always_xy=True: sem ele, pyproj segue a ordem dos eixos padrão EPSG (latitude primeiro para SRC geográficos), o que troca suas coordenadas silenciosamente.
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
Linha de comando (ogr2ogr)
Para reprojeção de arquivos Shapefile, GeoJSON ou GeoPackage, ogr2ogr do GDAL é a ferramenta padrão. Ele lida com conversão em lote de datasets inteiros em um único 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
Use -s_srs para especificar o SRC de origem explicitamente quando o arquivo de entrada não tem metadados de SRC (sem arquivo .prj ou informação de projeção embutida). Se o SRC de origem já está definido no arquivo, -t_srs sozinho é suficiente.
Convertendo coordenadas chinesas (WGS 84, GCJ-02, BD-09)
A China exige offsets de coordenadas em todos os serviços cartográficos públicos. GCJ-02 ("Coordenadas de Marte") desloca pontos WGS 84 em 100–700 metros usando um algoritmo não linear baseado no elipsoide de Krasovsky 1940. BD-09 adiciona um offset extra sobre o GCJ-02. Não são sistemas registrados no EPSG, e ferramentas padrão como proj4 e pyproj não conseguem convertê-los: são necessários algoritmos de offset dedicados.
Os offsets existem porque a legislação topográfica chinesa exige que todos os mapas digitais públicos usem um sistema de coordenadas criptografado. A transformação direta (WGS 84 → GCJ-02) é uma fórmula determinística. A inversa (GCJ-02 → WGS 84) não tem solução em forma fechada e exige aproximação iterativa, tipicamente 10 iterações para atingir precisão sub-métrica (~0,1 m).
Quais serviços usam qual sistema:
| Serviço de mapas | Sistema de coordenadas | Offset em relação ao 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 + offset adicional |
| OpenStreetMap | WGS 84 | Nenhum |
A cadeia de conversão é: WGS 84 ↔ GCJ-02 ↔ BD-09. Converter diretamente entre WGS 84 e BD-09 sem o passo intermediário GCJ-02 produz resultados incorretos. O conversor de coordenadas do KunYu implementa a cadeia completa com algoritmos inversos iterativos, algo que a maioria das ferramentas GIS internacionais não suporta.
Pela minha experiência, o offset é pior no oeste da China: perto de Urumqi vi deslocamentos superiores a 600 metros, suficientes para colocar um ponto de interesse do outro lado de um rio ou na pista errada de uma rodovia. Nas cidades costeiras do leste como Xangai, o offset é menor (cerca de 200–300 metros) mas ainda grande demais para ignorar. A armadilha sutil é que o offset varia suavemente por todo o território, então você não vai pegá-lo conferindo um único local: uma conversão que "parece certa" em Pequim pode estar visivelmente errada em Chengdu.
Conversor de Coordenadas
Converta coordenadas entre sistemas EPSG com suporte em lote e detecção inteligente.
Try it nowCinco erros comuns na conversão de coordenadas
Os erros mais frequentes na conversão de coordenadas são: selecionar o SRC de origem errado, confundir a ordem dos eixos, usar Web Mercator para medições, ignorar transformações de datum e assumir que todas as coordenadas em graus são WGS 84. Cada um produz resultados sutilmente errados que podem passar despercebidos até causarem problemas reais adiante.
Seleção errada do SRC de origem
Se seus dados de origem são NAD83 (EPSG:4269) mas você diz ao conversor que são WGS 84 (EPSG:4326), a diferença é de apenas ~1–2 metros na maior parte da América do Norte: fácil de não perceber nos testes, significativo para trabalho topográfico de precisão. Confundir NAD27 com WGS 84 é pior: offsets de 10–200 metros dependendo da localização, suficientes para colocar um edifício no lado errado de uma divisa de propriedade.
Confusão na ordem dos eixos (lat/lon vs lon/lat)
A definição formal de EPSG:4326 é latitude primeiro (lat, lng). Mas GeoJSON, proj4js, o construtor L.latlng() do Leaflet (apesar do nome) e a maioria das bibliotecas de web mapping esperam longitude primeiro (lng, lat). Se seus pontos convertidos se espalham aleatoriamente pelo mapa mas na escala aproximadamente correta, provavelmente você trocou lat e lon. O parâmetro always_xy=True do pyproj existe exatamente para evitar essa armadilha.
Usar Web Mercator para medições
EPSG:3857 é para exibição, não para cálculos. Calcular área em Web Mercator infla os resultados em latitudes elevadas: a Groenlândia aparece 14 vezes maior do que realmente é. Para cálculos de distância e área, converta primeiro para um SRC projetado local (uma zona UTM ou grade nacional) e depois meça.
Transformações de datum faltando
Converter entre SRC que usam datums diferentes, por exemplo ED50 para ETRS89 na Europa, requer uma transformação de datum com parâmetros específicos. Usar uma transformação genérica ou padrão pode introduzir erros de vários metros. GDAL e pyproj tratam disso automaticamente quando arquivos de grid shift estão disponíveis, mas vale verificar o método de transformação utilizado.
Assumir que todas as coordenadas em graus são WGS 84
Muitos SRC geográficos usam graus: EPSG:4326 (WGS 84), EPSG:4269 (NAD83), EPSG:4490 (CGCS2000), EPSG:4612 (JGD2000). Um ponto em 139.6917, 35.6895 pode ser qualquer um desses: parecem idênticos no formato mas usam datums diferentes. Sempre verifique os metadados de origem antes de converter.
Escolhendo a ferramenta certa para conversão de coordenadas
Para conversões avulsas ou de pequenos lotes, ferramentas no navegador são as mais rápidas: sem instalação, sem código. Para reprojeção de arquivos, use ogr2ogr ou QGIS. Para pipelines programáticos, proj4js (JavaScript) ou pyproj (Python) se integram diretamente ao seu código. Para SRC chineses, a maioria das ferramentas internacionais fica aquém.
| Cenário | Melhor ferramenta | Por quê |
|---|---|---|
| Verificação rápida de um ponto | Conversor de coordenadas KunYu | No navegador, 6000+ EPSG, SRC chineses incluídos |
| Reprojeção de arquivos (SHP/GeoJSON) | ogr2ogr (GDAL) | Qualquer formato, processamento em lote, scriptável |
| Projeto QGIS | Ferramenta Reprojetar Camada | Fluxo de trabalho GUI, preserva atributos e estilos |
| Web app JavaScript | proj4js | Lado do cliente, ~100KB, sem servidor |
| Pipeline de dados Python | pyproj | Banco de dados PROJ completo, compatível com NumPy |
| SRC chineses (GCJ-02/BD-09) | Conversor de coordenadas KunYu | Algoritmos de offset integrados que a maioria das ferramentas não tem |
No meu dia a dia, uso ogr2ogr como padrão para qualquer operação repetível. Uma vez precisei reprojetar mais de 200 arquivos GeoJSON de um dataset municipal (todos em uma projeção Lambert local) para WGS 84 para uma aplicação web. No QGIS, seriam 200 cliques manuais "Exportar → Salvar como → Definir SRC". Com ogr2ogr, bastou um loop shell de uma linha: for f in *.geojson; do ogr2ogr -t_srs EPSG:4326 out/"$f" "$f"; done — pronto em menos de um minuto. O QGIS é melhor quando você precisa verificar visualmente a reprojeção ou quando o SRC de origem não está embutido no arquivo e você precisa testar algumas opções interativamente.
Busca EPSG
Pesquise e navegue pelo banco de dados de sistemas de referência de coordenadas EPSG.
Try it nowPerguntas frequentes
Como converter EPSG:4326 para UTM?
Primeiro, determine em qual zona UTM suas coordenadas se encontram: zona = floor((longitude + 180) / 6) + 1. Depois converta usando o código EPSG correspondente: EPSG:326xx para o Hemisfério Norte, EPSG:327xx para o Hemisfério Sul, onde xx é o número da zona. Por exemplo, Pequim a 116,4°E cai na UTM Zone 50N, que é EPSG:32650.
Qual é a diferença entre conversão e transformação de coordenadas?
A conversão de coordenadas muda a projeção cartográfica permanecendo no mesmo datum (ex.: WGS 84 geográfico para WGS 84 / UTM). A transformação de coordenadas muda o datum em si (ex.: NAD27 para WGS 84), o que envolve parâmetros de modelo físico. Ferramentas GIS como pyproj e GDAL lidam com ambas de forma transparente; a distinção importa principalmente ao depurar problemas de precisão.
Por que minhas coordenadas convertidas estão deslocadas centenas de metros?
A causa mais comum é um SRC de origem errado. Na China, misturar WGS 84 com GCJ-02 produz offsets de 100–700 metros: isso é intencional, não é um bug. Fora da China, confundir NAD27 com WGS 84 ou usar parâmetros de transformação de datum incorretos produz erros similares. Sempre verifique o SRC de origem antes de converter.
Posso converter coordenadas em lote sem programar?
Sim. O conversor de coordenadas do KunYu aceita múltiplas coordenadas (uma por linha) para conversão em lote diretamente no navegador, sem cadastro e sem que seus dados saiam do seu dispositivo. Para conversão em lote de arquivos Shapefile ou GeoJSON, use a ferramenta format converter ou ogr2ogr na linha de comando.
proj4js é o mesmo que PROJ?
Não. PROJ é uma biblioteca C/C++ de transformação de coordenadas mantida pela comunidade OSGeo, com um banco de dados de mais de 10.000 definições de SRC e suporte para transformações de datum baseadas em grids. Proj4js é um port JavaScript que implementa os mesmos algoritmos centrais mas inclui apenas EPSG:4326 e EPSG:3857 por padrão: todas as outras definições de SRC precisam ser registradas manualmente.
O que levar daqui
O padrão é sempre o mesmo: identifique o SRC de origem, identifique o SRC de destino, aplique a conversão. Para verificações rápidas, use um conversor online. Para reprojeção no nível de arquivo, use ogr2ogr. Para código de aplicação, integre proj4js ou pyproj. E se não sabe qual código EPSG precisa, comece por Códigos EPSG explicados ou pesquise diretamente com a ferramenta EPSG Search.