Casos de uso

Criando um mapa de recursos para resposta a desastres

Durante uma emergência climática em andamento, as informações sobre onde a ajuda é necessária e onde ela está disponível chegam rápido e sem nenhum formato consistente. Um grupo regional de coordenação de ajuda humanitária se viu coletando locais de abrigos, pontos de entrega de suprimentos e relatos de pessoas que precisavam de assistência enviados por voluntários por mensagem de texto com qualquer descrição que lhes viesse à cabeça: um cruzamento, um ponto de referência, um endereço parcial, um par de coordenadas copiado do aplicativo de mapas do celular.

Nada disso pode ser usado diretamente em um mapa compartilhado sem um formato comum por trás. O grupo de coordenação precisava que cada relato recebido fosse convertido na mesma coisa, um par de coordenadas, independentemente de como chegasse. Os relatos que chegavam como texto, um endereço ou uma descrição próxima o bastante de um, passavam pelo /v1/forward para obter uma correspondência de local. Os relatos que chegavam como coordenadas, copiadas do compartilhamento de localização do celular, passavam pelo /v1/reverse para obter um endereço legível e a área administrativa, algo útil para mostrar aos voluntários uma descrição simples do local em vez de um par de números brutos no mapa.

Com cada relato normalizado para uma coordenada, plotá-los juntos em um único mapa compartilhado ficou simples e, mais importante, comparável: um ponto de suprimentos e uma necessidade relatada podiam ser medidos um em relação ao outro pela distância real, o que fazia enorme diferença para direcionar os voluntários de forma eficiente, em vez de adivinhar a proximidade a partir de descrições escritas que não tinham relação evidente entre si.

O grupo fez isso por meio de um formulário de entrada simples, e não de algo mais elaborado, já que a prioridade durante uma operação em andamento era a rapidez e a simplicidade, e não o acabamento. Um voluntário que enviava um relato não precisava saber nem se preocupar com qual endpoint tratava o formato da sua entrada; o formulário decidia isso com base em se o envio parecia texto ou coordenadas, e os dois caminhos terminavam no mesmo ponto normalizado no mapa compartilhado.

A qualidade da correspondência importava mais aqui do que na maioria dos outros usos da geocodificação, já que um relato durante uma emergência que é resolvido para o local errado, mesmo por uma distância pequena, pode mandar ajuda para o lugar errado exatamente no momento mais crítico. O formulário de entrada do grupo exibia a confiança da correspondência retornada pela chamada de geocodificação direta diretamente para quem estava revisando os relatos recebidos, de modo que uma correspondência de baixa confiança passava por uma rápida verificação humana antes de ser considerada confiável e usada, em vez de ser plotada com a mesma aparente certeza de uma correspondência sem ambiguidade.

Nada disso exigiu software especializado de gestão de emergências. O grupo de coordenação rodava o formulário de entrada na infraestrutura que já tinha, acrescentando a geocodificação como a única peça que faltava para que descrições de localização não estruturadas, enviadas por voluntários, se tornassem algo que um mapa compartilhado pudesse de fato exibir e comparar.

O volume de requisições durante uma operação em andamento subia de forma brusca e breve, o tipo de padrão para o qual é difícil planejar um orçamento fixo com antecedência. A cota diária gratuita cobria o uso comum de planejamento e preparação entre os eventos, e o crédito pré-pago absorvia o pico durante uma operação real, sem exigir que o grupo se comprometesse com um plano contínuo maior do qual não precisaria na maior parte do ano.

A documentação dos dois endpoints está em /docs/forward-geocoding/ e /docs/reverse-geocoding/.