Geocodificação na prática
A maioria das pessoas acha que transformar um endereço em coordenadas é só digitar uma rua num site e pronto. O real é que o processo, chamado geocodificação reversa ou direta, envolve APIs de provedores como Google, OpenStreetMap (Nominatim), Mapbox ou Here. A diferença entre eles não é só preço, mas a qualidade dos dados, a tolerância a endereços malformados e a velocidade de resposta. Eu já perdi meia hora num sábado porque um loteamento novo não estava cadastrado em nenhuma base, e o "endereço" que o cliente passou era só o nome do bairro.
Como saber a latitude e longitude de um endereço
Se você precisa fazer isso de forma simples e sem gastar nada no início, o Nominatim do OpenStreetMap costuma ser o caminho mais direto. Ele é público, não exige cartão de crédito e responde com JSON. A desvantagem imediata é que ele não foi feito para alta carga, então se você rodar muitas requisições seguidas, recebe erro 429 e precisa esperar. Eu uso um cabeçalho simples com um email de contato e um delay de 1,1 segundos entre chamadas; isso mantém a conta estável na maioria dos projetos pequenos. Para quem já tem uma conta Google, a API de Geocoding é mais rápida e devolve resultados mais consistentes em endereços urbanos, mas custa dinheiro por requisição após a cota gratuita e exige cobrança habilitada. Mapbox e Here são alternativas decentes com tiers generosos, mas exigem token e validação de plano. Se o seu projeto é só testar um ou dois endereços, fica no Nominatim. Se vai processar milhares de linhas num script, use Google ou Mapbox com cache local.
O fluxo técnico básico é um GET para o endpoint com parâmetros como address, city, state, country e, quando possível, postalcode. Quanto mais campos estruturados você passar, menor a ambiguidade. Receber a resposta em graus decimais, com latitude e longitude, é o padrão. Eu costumo normalizar para WGS84 e arredondar para seis casas decimais, que dá uma precisão na faixa de centímetros em linha reta; para logística urbana, três ou quatro casas já bastam e reduzem ruído de endereços imprecisos. Um detalhe que todo mundo esquece é o sistema de referências. A grande maioria dos serviços devolve WGS84, mas se você for colocar esses dados num shapefile antigo ou num GPS mais velho configurado em outros datum, precisa fazer a transformação. Eu vi um projeto de entrega falhar porque o time assumiu que -23.55, -46.63 era universal, sem notar que a base interna do banco usava um datum diferente e gerava deslocamentos de alguns metros. Verifique o SRID antes de confiar no número.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outro ponto prático é a fuzzy match. Endereços brasileiros às vezes chegam abreviados, sem CEP, ou com o nome da rua levemente errado. O Nominatim tende a devolver o "best guess" com um place_id e um tipo de resultado que indica se é um house number, um street ou um suburb. Eu filtro por type para excluir resultados genéricos de bairro quando preciso de precisão de rota, senão o motorista chega no quartiere errado. Também ignoro resultados com confiança muito baixa, senão você gasta tempo conferindo pontos no meio de um lote vago. Se você quer automação rápida, pode montar um script simples em Python com a biblioteca requests ou usar geopy, que abstrai o Nominatim e outras fontes em poucas linhas. Um exemplo mínimo seria chamar o endpoint com o endereço formatado, tratar o primeiro item da lista e salvar lat/lon. Para batches maiores, coloque um loop com try/except, retry exponencial e cache em disco para não repetir requisições idênticas. Isso costuma cortar o tempo de processamento de horas para minutos, dependendo do volume e da taxa de erro dos endereços.
Também existe a opção de usar ferramentas visuais, como abrir o Google Maps, clicar com o botão direito num ponto e copiar as coordenadas, ou usar extensões de navegador que exibem a latitude e longitude ao passar o mouse. Funciona para conferência pontual, mas não escala. Eu uso esse método só para validar um resultado suspeito ou para dar uma olhada rápida antes de rodar o script em lote. Há ainda a questão dos dados offline. Em alguns cenários de campo, você não tem internet e precisa de coordenadas de endereços conhecidos. Aí a solução costuma ser baixar um dump do Nominatim ou usar bases como o OpenAddresses, que agregam fontes abertas. Eu baixei um dump regional uma vez para um projeto de saúde pública; levou horas para importar e gerou uns 2 GB de JSON, mas resolveu a dependência de API durante uma emergência de rede. O downside é a manutenção: endereços mudam, loteamentos novos aparecem e a base fica desatualizada em poucos meses.
Outra armadilha comum é a confusão entre geocodificação direta e reversa. Direta transforma endereço em coordenadas; reversa faz o oposto, coordenadas em endereço. Muitos scripts que encontram pela web misturam os endpoints e dão erro 400 só porque o campo passou errado. Eu já depurei isso à noite porque o log só mostrava "Bad Request" sem detalhe útil; a solução foi checar o schema do Nominatim e ajustar os parâmetros para o formato esperado. Se o seu caso é alto volume com precisão crítica, considere pagar uma API comercial e usar geocodificação em lote com suporte a CSV. Eles costumam oferecer melhorias de deduplicação, matching de faixas numéricas e atualizações frequentes. O custo pode ser significativo, mas evita o trabalho manual de limpeza de resultados. Para pequenos projetos e testes, o Nominatim ou a versão gratuita do Google com cota controlada ainda são suficientes.
Por fim, anote sempre a fonte e a data da resposta. Coordenadas não são eternas; uma obra nova ou um renomeação de rua pode invalidar um ponto que parecia correto. Eu manter um registro simples com timestamp, provider e hash do endereço consultado; isso ajuda a reproduzir resultados e a detectar drift quando uma nova consulta devolve algo diferente do mesmo endereço. Sem esse rastreamento, você acaba corrigindo problemas que na verdade são apenas mudanças nos dados.
