Recebe um conjunto de pontos GPS levantados em WGS 84 e precisa de os sobrepor 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 impercetí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 utilizando transformações de datum e projeções cartográficas definidas matematicamente. Abaixo: o código para o fazer em JavaScript, Python e na linha de comandos, mais os erros que corrompem os seus dados silenciosamente.
O que é a conversão de coordenadas e quando é necessária?
A conversão de coordenadas reprojeta dados pontuais de um SRC para outro. É necessária sempre que combina datasets recolhidos em sistemas de coordenadas diferentes, visualiza dados GPS num 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 são frequentemente confundidas. A conversão de coordenadas altera 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 altera 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 se está a depurar problemas de precisão.
Os cinco cenários em que vai precisar de um conversor de coordenadas:
- Juntar datasets de SRC diferentes — um fornecedor entrega dados topográficos numa grelha nacional (digamos OSGB 1936, EPSG:27700) e precisa de os combinar com a sua baseline WGS 84.
- GPS para mapa web — a saída bruta do GPS é WGS 84 (graus), mas os mapas web renderizam em Web Mercator (metros). Todos os mapas baseados em tiles fazem esta conversão por baixo.
- Entregar dados topográficos no SRC exigido pelo cliente — o sistema CAD do cliente espera Lambert-93 (EPSG:2154); o seu equipamento de campo regista 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 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 pormenor a ter em atenção: EPSG:3857 corta em aproximadamente ±85,06° de latitude. A projeção de Mercator mapeia os polos para o infinito, pelo que coordenadas acima de 85°N ou abaixo de 85°S não podem ser representadas. Dados do Ártico e da Antártica requerem uma projeção estereográfica polar como EPSG:3413 (Norte) ou EPSG:3031 (Sul).
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 incorporados, precisa da definição do SRC (uma cadeia proj4 ou WKT). Bibliotecas como proj4js exigem que se registem definições de SRC personalizadas antes de as utilizar; pyproj já inclui a base de dados EPSG completa.
JavaScript (proj4js)
Proj4js só conhece EPSG:4326 e EPSG:3857 por defeito. Tudo o resto precisa de uma cadeia de definição, que 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 apanha muita gente: a cadeia de definição proj4 tem de corresponder exatamente. Uma vez passei uma hora a depurar um offset de 3 metros num dataset projetado em CGCS2000. O problema era que o ficheiro .prj que acompanhava o Shapefile usava uma parametrização de elipsoide ligeiramente diferente da listada no epsg.io. A solução foi copiar a cadeia proj4 diretamente do conteúdo do .prj usando gdalsrsinfo input.shp, em vez de procurar o código EPSG e presumir que a definição seria idêntica. Quando a precisão importa, derive sempre a definição dos dados de origem.
Python (pyproj)
Pyproj traz a base de dados PROJ completa, pelo que nunca precisa de registar 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 as 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 comandos (ogr2ogr)
Para reprojeção de ficheiros Shapefile, GeoJSON ou GeoPackage, ogr2ogr do GDAL é a ferramenta padrão. Trata da conversão em lote de datasets inteiros num ú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 ficheiro de entrada não tem metadados de SRC (sem ficheiro .prj ou informação de projeção incorporada). Se o SRC de origem já está definido no ficheiro, -t_srs sozinho é suficiente.
Converter 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 acrescenta um offset extra sobre o GCJ-02. Não são sistemas registados 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 utilizem um sistema de coordenadas encriptado. 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).
Que serviços usam que 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 intermédio 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 faixa errada de uma autoestrada. Nas cidades costeiras do leste como Xangai, o offset é menor (cerca de 200–300 metros) mas ainda demasiado grande para ignorar. A armadilha subtil é que o offset varia suavemente por todo o território, pelo que não o vai detetar verificando 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 para conversão em lote e deteçã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 presumir que todas as coordenadas em graus são WGS 84. Cada um produz resultados subtilmente errados que podem passar despercebidos até causarem problemas reais a jusante.
Seleção errada do SRC de origem
Se os seus dados de origem são NAD83 (EPSG:4269) mas indica 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 reparar 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 estrema 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 os seus pontos convertidos se espalham aleatoriamente pelo mapa mas na escala aproximadamente correta, provavelmente trocou lat e lon. O parâmetro always_xy=True do pyproj existe precisamente para evitar esta armadilha.
Usar Web Mercator para medições
EPSG:3857 é para visualização, não para cálculos. Calcular área em Web Mercator infla os resultados em latitudes elevadas: a Gronelâ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 grelha nacional) e depois meça.
Transformações de datum em falta
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 predefinida pode introduzir erros de vários metros. GDAL e pyproj tratam disto automaticamente quando ficheiros de grid shift estão disponíveis, mas vale a pena verificar o método de transformação utilizado.
Presumir 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 destes: parecem idênticos no formato mas usam datums diferentes. Verifique sempre os metadados de origem antes de converter.
Escolher 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 ficheiros, use ogr2ogr ou QGIS. Para pipelines programáticas, proj4js (JavaScript) ou pyproj (Python) integram-se diretamente no seu código. Para SRC chineses, a maioria das ferramentas internacionais fica aquém.
| Cenário | Melhor ferramenta | Porquê |
|---|---|---|
| Verificação rápida de um ponto | Conversor de coordenadas KunYu | No navegador, 6000+ EPSG, SRC chineses incluídos |
| Reprojeção de ficheiros (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 | Base de dados PROJ completa, 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 por defeito para qualquer operação repetível. Uma vez precisei de reprojetar mais de 200 ficheiros GeoJSON de um dataset municipal (todos numa projeção Lambert local) para WGS 84 para uma aplicação web. No QGIS, seriam 200 cliques manuais "Exportar → Guardar como → Definir SRC". Com ogr2ogr, bastou um ciclo shell de uma linha: for f in *.geojson; do ogr2ogr -t_srs EPSG:4326 out/"$f" "$f"; done — concluído em menos de um minuto. O QGIS é melhor quando precisa de verificar visualmente a reprojeção ou quando o SRC de origem não está incorporado no ficheiro e precisa de experimentar algumas opções interativamente.
Pesquisa EPSG
Pesquise e navegue pela base de dados de sistemas de referência de coordenadas EPSG.
Try it nowPerguntas frequentes
Como converter EPSG:4326 para UTM?
Primeiro, determine em que zona UTM as 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 altera a projeção cartográfica permanecendo no mesmo datum (ex.: WGS 84 geográfico para WGS 84 / UTM). A transformação de coordenadas altera 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 sobretudo ao depurar problemas de precisão.
Porque é que as 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: é 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 semelhantes. Verifique sempre 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 registo e sem que os seus dados saiam do seu dispositivo. Para conversão em lote de ficheiros Shapefile ou GeoJSON, use a ferramenta format converter ou ogr2ogr na linha de comandos.
proj4js é o mesmo que PROJ?
Não. PROJ é uma biblioteca C/C++ de transformação de coordenadas mantida pela comunidade OSGeo, com uma base de dados de mais de 10.000 definições de SRC e suporte para transformações de datum baseadas em grelhas. Proj4js é um port JavaScript que implementa os mesmos algoritmos centrais mas inclui apenas EPSG:4326 e EPSG:3857 por defeito: todas as outras definições de SRC precisam de ser registadas manualmente.
O que reter
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 ao nível de ficheiro, use ogr2ogr. Para código de aplicação, integre proj4js ou pyproj. E se não sabe que código EPSG precisa, comece por Códigos EPSG explicados ou pesquise diretamente com a ferramenta EPSG Search.