Guia prático para lidar com travessas e logradouros em cidades brasileiras
Ao cadastrar um endereço ou buscar uma localidade qualquer em ferramentas de geolocalização, você vai se deparar frequentemente com o termo "travessa". Travessa do Rio é um exemplo comum de logradouro que aparece em múltiplas cidades, desde o interior de Minas até bairros residenciais de São Paulo e Rio de Janeiro. O problema é que a maioria dos sistemas de busca simplesmente não prioriza esses endereços secundários, e aí começa a dor de cabeça.
Como identificar travessa do rio e logradouros similares
Travessa é um tipo de rua de pequeno porte, geralmente perpendicular a uma via principal, e que muitas vezes não recebe o mesmo tratamento nos bancos de dados oficiais de endereço. No Brasil, os prefeitos municipais e os Correios tratam travessas como logradouros válidos, mas os cadastros digitais muitas vezes ficam desatualizados. Eu já passei por isso na prática: tentava localizar um endereço num bairro novo de Contagem (MG) que tinha uma travessa do rio, e o Google Maps simplesmente não exibia o nome. O CEP estava correto, a rua principal também, mas a travessa em si era invisível. O que funcionou foi cruzar dados de três fontes: o site da prefeitura com a lista oficial de logradouros atualizada, o sistema dos Correios para confirmar o CEP, e o OpenStreetMap como fonte alternativa. O OSM costuma ter contribuições mais recentes de moradores locais que ainda não apareceram nos serviços comerciais.
Se você está construindo um sistema de validação de endereços, não confie apenas no Google Places. Ele tem cobertura irregular para logradouros secundários. A Abep (Associação Brasileira de Empresas de Correios e Telégrafos) mantém uma base que é mais confiável para travessas, mas ela é proprietária e não gratuita. Para projetos pequenos, o Idealização (service de geocoding brasileiro) ou o OpenCargas têm resultados melhores para esse tipo de via.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Pitfalls comuns ao trabalhar com esse tipo de logradouro
Vários desenvolvedores cometem o mesmo erro: tratam travessa como sinônimo de rua e aplicam a mesma lógica de normalização. Isso gera problemas porque travessas frequentemente não têm numeração pari/impar bem definida, especialmente em loteamentos mais antigos. Já vi cases em que o script de parseamento de endereço descartava um endereço completo porque o número não seguia o padrão esperado. Outro ponto que ninguém alerta é a variação de nomenclatura. Uma mesma travessa pode ser registrada como "Travessa do Rio", "Tr. do Rio", "Tv. Rio do" em bases diferentes. O sistema precisa aceitar todas as variações e mapeá-las para a forma canônica antes de fazer qualquer consulta.
Dica técnica: implemente um normalizador que padronize abreviações antes de cruzar com qualquer base. Isso elimina boa parte dos falsos negativos que aparecem em testes de integração.
Quando o endereço simplesmente não existe nas bases oficiais
É importante ser direto sobre isso: às vezes a travessa existe fisicamente, foi aberta por ocupação espontânea ou por um loteamento irregular, e nunca foi registrada oficialmente. Nesse caso, nenhum serviço de geocoding vai encontrar. Já tive que lidar com isso num projeto de logística urbana onde uma travessa em Recife não constava em nenhuma base, mas era utilizada por motoristas de app e entregadores locais. A solução foi criar um mapeamento manual via crowdsourcing e alimentar o sistema com dados validados por operadores de campo. Se o seu cenário envolve entregas ou coleta de dados de campo, considere usar o OSM como camada adicional. O aplicativo das ruas (Street View) do Google também ajuda, mas só cobre grandes centros. Para cidades do interior, o Maps do OSM costuma ter dados mais recentes porque a comunidade local mantém ativa a edição.
Não existe solução perfeita para esse problema. O melhor que você pode fazer é combinar pelo menos duas fontes de dados, implementar normalização agressiva de nomes de logradouros, e ter um fallback humano para casos que as máquinas não resolvem. O resto é ajuste iterativo conforme os dados vão sendo validados no campo.
