Existe uma tentação real, em qualquer sistema que responde a perguntas, de sempre retornar alguma coisa em vez de admitir que uma pergunta não pode ser respondida de forma confiável. No caso específico dos dados de localização, ceder a essa tentação é ativamente prejudicial, porque uma resposta de aparência plausível, mas errada, geralmente causa muito mais dano à decisão que ela alimenta do que uma admissão honesta de que os dados não sustentam uma resposta confiável.
O raciocínio é simples quando dito de forma direta. Um resultado nulo, ou um resultado marcado explicitamente com baixa confiança, é algo que uma aplicação bem projetada consegue detectar e tratar de forma deliberada, recorrendo a pedir esclarecimentos ao usuário, aplicando um padrão mais amplo ou sinalizando o registro para revisão manual. Um palpite fabricado que parece igual a qualquer outro resultado confiante, sem nenhum sinal visível de que na verdade era uma correspondência fraca ou ambígua, não pode ser detectado nem tratado de forma especial, porque visto de fora é indistinguível de uma resposta realmente sólida, até o momento em que causa um problema real e visível em algum ponto mais adiante, muitas vezes difícil de rastrear até sua origem.
É por isso que uma consulta ambígua ou impossível de resolver deve retornar nenhum resultado, ou um resultado cuja pontuação de confidence reflita de forma honesta e clara a incerteza real envolvida, em vez de o geocodificador escolher em silêncio um candidato plausível entre vários e apresentá-lo com a mesma aparente certeza de uma correspondência inequívoca. O mesmo princípio vale para a precisão: um resultado nunca deve alegar um nível de precisão mais fino do que os dados realmente sustentam, mesmo sob pressão para sempre retornar algo com aparência mais específica. Informar city com honestidade é um resultado melhor do que informar house com base em um palpite.
Para quem constrói sobre esse tipo de dado, a implicação prática é projetar a própria aplicação para realmente esperar e tratar com elegância resultados nulos e de baixa confiança como uma parte normal e rotineira do espaço de respostas, e não como um caso excepcional e raro que exige um tratamento separado acrescentado depois, como um remendo. Um formulário que só tem um caminho feliz para resultados de alta confiança e totalmente resolvidos, sem nenhum comportamento pensado para o resto, vai acabar quebrando de forma confusa quando inevitavelmente encontrar uma consulta que os dados realmente não conseguem resolver com confiança, o que acontece com mais frequência do que a maioria dos projetos iniciais prevê.
Verificar tanto precision quanto confidence em cada resultado, e ter um comportamento alternativo deliberado e bem pensado para quando qualquer um deles ficar abaixo do limite que o seu caso de uso realmente exige, é a diferença entre uma aplicação que se degrada com elegância nos casos difíceis e uma que propaga dados ruins em silêncio porque nunca foi projetada para esperar nada além de uma resposta limpa e inequívoca.