Geolocalização real: casos e lições aprendidas

A geolocalização deixou de ser uma funcionalidade exótica há anos. Hoje está integrada na entrega de última milha, no controlo de frotas, no marketing local e até na forma como um site decide que moeda te mostrar. Mas entre a teoria dos manuais e a prática há uma distância que só se percebe quando o GPS falha num beco, quando o navegador pede permissão e o utilizador diz que não, ou quando a API devolve uma posição com 800 metros de erro.

Este artigo não explica o que é a geolocalização. Reúne experiências concretas de implementação, erros que se repetem e limites que convém conhecer antes de prometer precisão milimétrica a um cliente ou a um chefe.

Onde se usa de verdade: quatro cenários com detalhes que importam

1. Entrega urbana: a geocerca que não coincide com a realidade

Um caso habitual em empresas de mensageria: define-se um polígono de serviço com coordenadas e configura-se uma geocerca para aceitar pedidos apenas dentro dessa área. O problema aparece quando o polígono é desenhado sobre um mapa de satélite desatualizado e corta ao meio uma rua que na realidade pertence ao município vizinho. O resultado são pedidos rejeitados na fronteira e clientes irritados.

A lição prática: as geocercas devem ser validadas com dados reais de endereços postais, não apenas com traços sobre o mapa. Segundo documentação de fornecedores de mapas, os limites administrativos mudam e as camadas base têm desfasamentos de atualização que podem ultrapassar o ano em zonas periurbanas.

2. Marketing local: o raio de influência que ninguém mede

As campanhas de publicidade com segmentação geográfica permitem escolher um raio em torno de uma loja. Um erro frequente é assumir que um raio de 5 km equivale a “pessoas que podem vir a pé”. Numa cidade com uma autoestrada ou um rio pelo meio, esse raio inclui bairros com uma acessibilidade péssima. Na prática, convém combinar o raio com dados de tráfego e com a localização real dos utilizadores ativos, que as plataformas publicitárias oferecem.

Isto não funciona da mesma forma para negócios de serviço ao domicílio e para retalho: no primeiro caso, o deslocamento é pago pelo negócio e o raio deve refletir tempos de condução, não distâncias em linha reta.

3. Controlo de frotas e assistência: o relatório que chega tarde

Os sistemas de seguimento enviam posições periodicamente. Em zonas com cobertura móvel irregular, o dispositivo armazena as posições e envia-as em bloco quando recupera sinal. Quem consome esses dados deve estar preparado para receber uma rajada de pontos com marcas temporais antigas. Se o painel de controlo apresenta esses pontos como se fossem atuais, o gestor de frota toma decisões sobre informação obsoleta.

Um detalhe que só se aprende com uso real: a bateria do dispositivo condiciona a frequência de envio. Os equipamentos configurados para reportar a cada 30 segundos esgotam a bateria do veículo ou do terminal em jornadas longas. O habitual é alternar modos: frequência alta em movimento, baixa em paragens prolongadas.

4. Web e apps: a geolocalização por IP face ao GPS do navegador

Quando um site pede a localização, há duas vias muito distintas. A API de geolocalização do navegador usa GPS, wifi e torres de telefonia, e requer permissão explícita do utilizador. A geolocalização por IP não pede permissão e é muito menos precisa: pode situar o visitante na cidade do fornecedor de internet, a dezenas ou centenas de quilómetros da sua posição real.

Em projetos de ecommerce, usar o IP para mostrar “a tua loja mais próxima” funciona como aproximação, mas falha com utilizadores de redes corporativas ou VPN. A recomendação habitual é oferecer um seletor manual como alternativa e nunca bloquear o acesso à compra por uma deteção geográfica errada.

Erros que se repetem e como evitá-los

• Confundir precisão com exatidão. O GPS pode indicar um raio de 10 metros e estar deslocado 40 por reflexões de sinal entre edifícios. Em ruas estreitas, a posição salta de passeio sem que o utilizador se mova.
• Não gerir a recusa de permissão. Muitos desenvolvimentos assumem que o utilizador aceitará. Se recusar, a aplicação deve continuar a funcionar com uma localização predefinida ou com introdução manual.
• Guardar coordenadas sem sistema de referência. Misturar WGS84 com outros sistemas de coordenadas produz desvios de centenas de metros. É preciso documentar que sistema usa cada camada de dados.
• Ignorar a privacidade. Armazenar o histórico de posições de utilizadores ou empregados exige base jurídica e transparência. Segundo a normativa de proteção de dados aplicável na União Europeia, o seguimento contínuo de trabalhadores requer justificação e proporcionalidade.
• Não testar em interiores. Dentro de naves industriais, centros comerciais ou parques de estacionamento subterrâneos, o GPS simplesmente não funciona. Se o caso de uso depende de posições interiores, é preciso recorrer a balizas ou wifi, com outra infraestrutura e outro custo.

O que a geolocalização não resolve

É importante ser honesto: a geolocalização não substitui um sistema de endereços bem mantido. Um pedido com um endereço incompleto continua a ser um problema mesmo que o cliente tenha partilhado a sua posição exata. A coordenada do ponto de entrega não indica o número da porta nem o andar.

Também não resolve a atribuição em publicidade: saber que um utilizador estava perto de uma loja não demonstra que a visitou. A medição fiável de visitas físicas requer outras técnicas, como inquéritos ou painéis, e mesmo assim os dados são estimativas.

E não é uma solução de segurança por si só. Os dispositivos podem perder sinal, ser desligados ou manipulados. Qualquer sistema de localização com fins de proteção deve ser combinado com outros sinais e com protocolos humanos de resposta.

Como começar sem tropeçar: uma sequência prática

1. Define o caso de uso e a sua tolerância ao erro. Uma app de caminhadas precisa de precisão de metros; uma campanha de marketing local pode trabalhar com quilómetros.
2. Escolhe a fonte de posição adequada. GPS do dispositivo para alta precisão, IP para aproximação sem fricção, dados de rede móvel como alternativa.
3. Desenha o fluxo de permissões. Explica ao utilizador para que precisas da localização antes de lançar o diálogo do navegador ou do sistema operativo.
4. Testa em condições reais. Caminha por ruas estreitas, entra num centro comercial, simula cobertura baixa. Os emuladores não reproduzem estas falhas.
5. Regista a qualidade do dado. Guarda a precisão reportada junto a cada posição. Esse campo permite filtrar pontos duvidosos a posteriori.
6. Revê a privacidade desde o primeiro dia. Define o que se guarda, durante quanto tempo e com que finalidade.

Uma nota sobre custos e dependência de fornecedores

As APIs de mapas e geocodificação têm condições de uso e preços que mudam. Um projeto que hoje funciona com uma quota gratuita pode tornar-se caro quando o volume de pedidos cresce. Convém rever a documentação oficial do fornecedor e prever um plano B, como armazenar em cache as geocodificações de endereços recorrentes para não repetir consultas idênticas.

Em resumo: a geolocalização é uma ferramenta poderosa com limites concretos. Os projetos que melhor funcionam são os que assumem esses limites desde o design, oferecem alternativas manuais e tratam a posição como mais um dado, com a sua margem de erro e a sua política de privacidade.