A decisão de qual provedor de mapas usar em um app de transporte regional costuma ser tomada no início do projeto, com o critério do que é mais rápido de integrar ou mais barato no tier gratuito. O que essa decisão raramente considera é que o mapa não é o fundo visual da tela do passageiro — é o motor que calcula os ETAs antes de aceitar a corrida, traça a rota do motorista da posição atual até a origem, geocodifica os endereços que os usuários escrevem de formas que poucas vezes coincidem com a nomenclatura oficial, e determina se o motorista em uma zona de baixa conectividade consegue navegar sem internet. Em operações de 300 a 700 corridas diárias em cidades médias do México ou da Colômbia, o provedor errado gera problemas que não têm nome no dashboard mas têm custo: tempos de espera reais mais altos que os ETAs prometidos, solicitações que nunca encontram o motorista, e corridas fracassadas em bairros onde o geocodificador não tem dados suficientes.

Este artigo é para operadores que estão escolhendo o seu stack de mapas antes do lançamento, ou que já têm um ativo e estão avaliando se o custo mensal ou os problemas operacionais justificam uma migração. Os três provedores com maior adoção em plataformas de ride-hailing regional — Google Maps Platform, HERE Maps e Mapbox — diferem em preço em escala, na profundidade de cobertura em cidades secundárias da América Latina, nas capacidades offline que cada SDK expõe, e em quão bem cada um interpreta as formas como os passageiros regionais realmente escrevem os seus endereços. A escolha correta não é a mesma para todos os casos: depende do volume atual, das cidades específicas onde a plataforma opera, e de se os requisitos do motorista e do passageiro apontam para o mesmo provedor ou para dois distintos.

Os três provedores de mapas e em que eles se diferenciam

O Google Maps Platform domina o mercado de aplicativos de consumo por razões concretas: tem a maior densidade de dados em quase qualquer cidade da América Latina, incluindo municípios de segundo e terceiro nível onde os outros dois provedores têm lacunas no mapa. A sua base de dados de lugares, restrições de circulação e ruas novas se atualiza com maior frequência, e o geocodificador consegue interpretar referências a estabelecimentos conhecidos que os usuários regionais usam como referência de endereço — não só o número da rua, mas o OXXO da esquina ou o mercado central. A desvantagem é estrutural: o Google Maps Platform cobra por cada chamada à API, sem um modelo de preço plano, e os custos crescem de forma não linear conforme a operação escala. Em uma plataforma que usa roteamento, geocodificação, rastreamento em tempo real e matrizes de distância simultaneamente, esse modelo pode gerar faturas que o operador não antecipou quando fez as projeções iniciais com o volume de uma operação pequena.

O HERE Maps tem uma origem distinta: nasceu como tecnologia de navegação para a indústria automotiva e durante anos foi o provedor de dados de mapas que as montadoras usavam nos seus sistemas de navegação integrados. Isso lhe dá uma força específica no contexto de ride-hailing: dados de tráfego em tempo real de alta precisão, mapas projetados para navegação veicular com suporte sólido de rotas offline, e um modelo de preços que em volumes médios pode ser entre 30% e 50% mais barato que o Google Maps Platform. As fraquezas estão na familiaridade do SDK para equipes técnicas que aprenderam com o Google, e em cidades pequenas e periféricas da América Latina onde a cobertura de ruas é menos densa e a geocodificação de endereços informais gera mais erros que o concorrente principal.

O Mapbox é o provedor com o modelo mais aberto: constrói a sua cobertura sobre o OpenStreetMap, a base de dados geográfica colaborativa que qualquer pessoa pode editar, e adiciona por cima dados comerciais próprios e ferramentas de design que nenhum dos outros dois oferece no mesmo grau. O seu SDK é o mais personalizável — permite modificar o estilo visual do mapa, integrar dados próprios e construir componentes de navegação com um nível de controle que Google e HERE não expõem. O preço é competitivo: o tier gratuito é generoso e o custo por chamada nas categorias de mapa base e rastreamento em tempo real é menor que nos outros dois. A limitação principal na América Latina é a dependência do OpenStreetMap: em cidades médias do México, Colômbia, Peru e Bolívia onde a comunidade de contribuidores ativos é pequena, os dados de ruas podem estar incompletos ou desatualizados em bairros novos, condomínios fechados e zonas periféricas onde uma parte significativa da demanda de táxi acontece.

O custo real das chamadas à API em uma operação de 400 corridas diárias

A comparação de preços entre provedores só é útil se for calculada sobre as chamadas reais que uma corrida gera, não sobre o preço de tabela de uma única API. Uma corrida em um app de táxi gera em média entre 8 e 14 chamadas à API de mapas: geocodificação do endereço de origem, geocodificação de destino, cálculo de ETA antes da atribuição, roteamento do motorista até o passageiro, roteamento do trajeto, atualizações de posição em tempo real durante o percurso, e em algumas implementações o recálculo da tarifa final com a rota realmente percorrida. Para uma operação de 400 corridas diárias com 10 a 12 chamadas por corrida, isso representa entre 120,000 e 145,000 chamadas mensais — volume suficiente para que a diferença entre provedores seja relevante na estrutura de custos.

Por que a cobertura offline importa mais na América Latina que na Europa ou nos Estados Unidos

Os benchmarks de desempenho de provedores de mapas são publicados principalmente para mercados onde a cobertura de celular em zonas urbanas é quase universal. Em cidades médias da América Latina, a conectividade do motorista no trabalho real é diferente: há bairros periféricos, estradas de acesso a condomínios novos e zonas industriais onde o sinal 4G é inconsistente e o motorista perde a rota se o SDK não conseguir operar sem conexão. O problema não é exclusivo de cidades pequenas — acontece em cidades de 300,000 ou 500,000 habitantes com desenvolvimento periférico recente onde a infraestrutura de telecomunicações ainda não alcança a densidade que a cobertura no mapa do operador sugere. Nessas zonas, um SDK que precisa de conexão contínua para atualizar a rota deixa o motorista sem navegação funcional justamente no trajeto que mais incerteza gera para o passageiro.

A capacidade offline dos três provedores é notavelmente distinta. O HERE Maps tem a funcionalidade offline mais madura, resultado direto da sua história em navegação automotiva: permite baixar pacotes de mapas por região e calcular rotas completas sem conexão ativa. O SDK do Google Maps para iOS e Android pode operar parcialmente offline em áreas previamente baixadas, mas com limitações no recálculo dinâmico de rotas quando o motorista se desvia do trajeto original. O Mapbox permite baixar áreas específicas de mapa base, mas as capacidades de navegação turn-by-turn offline são mais variáveis dependendo de como o SDK é implementado e quais componentes são ativados. Para operadores em cidades onde a conectividade do motorista é um fator real, a avaliação de capacidades offline não é uma funcionalidade secundária — é um dos três critérios principais da decisão junto ao preço e à cobertura de ruas.

Geocodificação de endereços informais: o diferenciador que não aparece em nenhum benchmark

Uma das diferenças menos documentadas entre provedores de mapas, e uma das mais relevantes para operações na América Latina, é quão bem cada geocodificador funciona quando o usuário escreve um endereço da forma como realmente o conhece. No México, na Colômbia e em grande parte da América Latina, muitos endereços não têm número de rua formal ou o número não coincide com a base de dados oficial: o passageiro escreve 'em frente ao OXXO na avenida Insurgentes', 'a meia quadra do mercado Juárez' ou simplesmente o nome do bairro com uma rua próxima de referência. O geocodificador que gera as coordenadas mais precisas para esse tipo de entrada é o que reduz os erros de embarque — motoristas que esperam no número de rua errado, passageiros que veem o pin na calçada errada — que são a segunda causa mais frequente de cancelamentos depois dos tempos de espera prolongados. O Google Maps tem vantagem estrutural nesse ponto pela profundidade da sua base de dados de lugares: o geocodificador consegue interpretar referências a estabelecimentos conhecidos e gerar coordenadas úteis mesmo para entradas muito informais. O HERE funciona bem em endereços formais mas o seu desempenho com referências informais em cidades secundárias é menos consistente. O Mapbox depende da densidade de dados do OpenStreetMap na área, com resultados mais variáveis em cidades com baixa atividade de contribuidores.

O SDK do motorista e o do passageiro têm requisitos distintos

Um erro frequente ao escolher o provedor de mapas é aplicar os mesmos critérios de avaliação ao SDK que o motorista usa e ao que o passageiro usa. As prioridades são distintas porque os casos de uso são distintos. O SDK do passageiro precisa principalmente de um mapa visual limpo, autocompletar de endereços preciso e rastreamento fluido da posição do motorista em tempo real — os três pontos fortes do Google Maps Platform. O SDK do motorista precisa principalmente de navegação turn-by-turn confiável com GPS snapping sobre a rua correta, capacidade de funcionamento com conectividade intermitente, e recálculo de rota rápido quando há desvios — os pontos onde o HERE Maps tem vantagem histórica. Alguns operadores regionais resolvem essa diferença de requisitos usando provedores distintos para cada app: Google Maps para o app do passageiro onde a experiência visual e a geocodificação são prioritárias, e HERE Maps ou uma implementação offline do Mapbox para o app do motorista onde a navegação sem conexão é mais relevante. Essa estratégia tem um custo de integração adicional mas elimina o comprometimento de usar um único provedor que não é o mais adequado para nenhum dos dois aplicativos. A decisão vale a pena avaliar quando a operação ultrapassa as 200 corridas diárias e os problemas de navegação ou geocodificação começam a aparecer de forma repetida no mesmo tipo de corrida.

Quando migrar de provedor e quando o custo da mudança não vale a pena

Para operações com menos de 200 corridas diárias, o custo da API de mapas raramente representa uma parte significativa da estrutura de custos — nesse volume, nenhum provedor gera faturas que afetem materialmente a economia da operação. Nessa etapa o critério mais relevante é a velocidade de integração: quão rápido a equipe técnica consegue ter o SDK funcionando com as funcionalidades base. O Google Maps ganha esse critério pela maturidade da sua documentação e pela amplitude da comunidade de desenvolvedores. A conversa sobre migrar para HERE ou Mapbox por razões de custo começa a ser relevante quando a operação ultrapassa as 300 a 400 corridas diárias e a fatura mensal de mapas ultrapassa os $600 a $800 USD. Nesse ponto, a diferença entre provedores pode representar entre $300 e $700 USD mensais — suficiente para justificar quatro a seis semanas de trabalho técnico de migração. O que a análise de migração precisa considerar, além do diferencial de preço, é o período de degradação de qualidade que ocorre enquanto o novo provedor se calibra na operação real: motoristas que reportam inconsistências no GPS snapping, geocodificações que retornam resultados diferentes dos que o passageiro espera, e zonas onde a cobertura do novo provedor é menor que a do anterior.

A escolha do provedor de mapas não é uma decisão técnica de arquitetura que a equipe de produto toma no início do projeto e não volta a revisar. É uma decisão com consequências operacionais diretas: na taxa de cancelamentos por ETA incorreto, no percentual de corridas fracassadas por geocodificação imprecisa em bairros periféricos, e nos custos de plataforma que a 400 corridas diárias podem representar entre $200 e $700 USD de diferença mensal dependendo do provedor e do mix de APIs. O operador que revisa essa decisão quando já tem volume real tem os dados para tomá-la corretamente; o que a otimiza no mês um com estimativas do que espera que aconteça toma a decisão com informação incompleta sobre o comportamento real dos motoristas e dos passageiros nas suas cidades específicas.

O que torna útil a comparação de provedores não é um benchmark abstrato de qual é melhor em condições de laboratório — é a avaliação de cada um contra os requisitos concretos da operação: as cidades onde se opera e a densidade de dados de cada provedor nessas cidades, o perfil de conectividade dos motoristas nas zonas periféricas ativas, o nível de formalidade dos endereços que os passageiros escrevem, e o volume no qual o diferencial de custo se torna relevante. Essa avaliação leva duas ou três semanas com testes em ambiente real de produção e é consideravelmente mais barata que seis meses operando com um provedor que gera problemas que o operador não consegue nomear mas consegue medir nas métricas que importam.