En cualquier sistema que responde preguntas existe una tentación real de devolver siempre algo en lugar de admitir que una pregunta no se puede responder de forma fiable. En el caso concreto de los datos de ubicación, ceder a esa tentación es claramente perjudicial, porque una respuesta verosímil pero errónea suele ser mucho más dañina para la decisión que alimenta que admitir con honestidad que los datos no permiten una respuesta segura.
El razonamiento es sencillo cuando se expone directamente. Un resultado nulo, o un resultado marcado explícitamente con baja confianza, es algo que una aplicación bien diseñada puede detectar y gestionar de forma deliberada: pedir al usuario una aclaración, aplicar un valor predeterminado más amplio o marcar el registro para revisión manual. Una suposición fabricada que parece igual que cualquier otro resultado seguro, sin ninguna señal visible de que en realidad fue una coincidencia débil o ambigua, no se puede detectar ni gestionar de forma especial, porque desde fuera es indistinguible de una respuesta realmente sólida, hasta el momento en que provoca un problema real y visible en algún punto posterior del proceso que a menudo es difícil rastrear hasta su verdadero origen.
Por eso una consulta ambigua o imposible de resolver debería devolver o bien ningún resultado, o bien un resultado cuya puntuación de confidence refleje de forma honesta y clara la incertidumbre real, en lugar de que el geocodificador elija en silencio un candidato plausible entre varios y lo presente con la misma certeza aparente que una coincidencia inequívoca. El mismo principio se aplica a la precisión: un resultado nunca debería declarar un nivel de precisión más fino del que los datos realmente respaldan, aunque haya presión para devolver siempre algo que parezca más específico. Informar city con honestidad es mejor resultado que informar house a partir de una suposición.
Para quien construye sobre este tipo de datos, la consecuencia práctica es diseñar su propia aplicación para esperar de verdad y gestionar con elegancia los resultados nulos y de baja confianza como una parte normal y habitual del espacio de respuestas, no como un caso excepcional y poco frecuente que requiere un tratamiento especial añadido a última hora. Un formulario que solo tiene un camino feliz para resultados de alta confianza y totalmente resueltos, sin un comportamiento pensado para todo lo demás, acabará fallando de forma confusa cuando inevitablemente se encuentre con una consulta que los datos realmente no pueden resolver con confianza, algo que ocurre con más frecuencia de lo que prevén la mayoría de los diseños iniciales.
Comprobar tanto precision como confidence en cada resultado, y tener un comportamiento alternativo deliberado y pensado para cuando cualquiera de los dos quede por debajo del umbral que tu caso de uso concreto realmente requiere, marca la diferencia entre una aplicación que se degrada con elegancia en los casos difíciles y otra que propaga datos erróneos en silencio porque nunca se diseñó para esperar algo distinto de una respuesta limpia e inequívoca.