Dans tout système qui répond à des questions, il existe une réelle tentation de toujours renvoyer quelque chose plutôt que d'admettre qu'une question ne peut pas recevoir de réponse fiable. Pour les données de localisation en particulier, céder à cette tentation est franchement nuisible, car une réponse plausible mais fausse est généralement bien plus dommageable pour la décision qu'elle alimente qu'un aveu honnête que les données ne permettent pas de répondre avec assurance.
Le raisonnement est simple une fois énoncé clairement. Un résultat nul, ou un résultat explicitement marqué comme peu fiable, est quelque chose qu'une application bien conçue peut détecter et traiter délibérément : demander une précision à l'utilisateur, appliquer une valeur par défaut plus large ou signaler l'enregistrement pour une vérification manuelle. Une supposition fabriquée qui ressemble à n'importe quel autre résultat fiable, sans aucun signal visible indiquant qu'il s'agit en réalité d'une correspondance faible ou ambiguë, ne peut ni être détectée ni faire l'objet d'un traitement particulier, car vue de l'extérieur elle est impossible à distinguer d'une réponse réellement solide, jusqu'au moment où elle provoque un problème bien réel et visible quelque part en aval, souvent difficile à rattacher à sa véritable origine.
C'est pourquoi une requête ambiguë ou impossible à résoudre doit renvoyer soit aucun résultat, soit un résultat dont le score confidence reflète honnêtement et clairement l'incertitude réelle, plutôt que de laisser le géocodeur choisir en silence un candidat plausible parmi plusieurs et le présenter avec la même certitude apparente qu'une correspondance sans ambiguïté. Le même principe s'applique à la précision : un résultat ne doit jamais revendiquer un niveau de précision plus fin que ce que les données permettent réellement, même lorsqu'on voudrait toujours renvoyer quelque chose d'apparence plus précise. Indiquer honnêtement city vaut mieux qu'indiquer house au hasard.
Pour quiconque construit sur ce type de données, la conséquence pratique est de concevoir votre application pour qu'elle s'attende réellement aux résultats nuls et peu fiables et les gère proprement, comme une partie normale et courante des réponses possibles, et non comme un cas exceptionnel et rare nécessitant un traitement séparé ajouté après coup. Un formulaire qui ne prévoit qu'un scénario idéal pour les résultats très fiables et entièrement résolus, sans comportement réfléchi pour tout le reste, finira par échouer de façon déroutante lorsqu'il rencontrera inévitablement une requête que les données ne peuvent pas résoudre avec certitude, ce qui arrive plus souvent que ne le prévoient la plupart des conceptions initiales.
Vérifier à la fois precision et confidence sur chaque résultat, et prévoir un comportement de repli délibéré et réfléchi lorsque l'un ou l'autre passe sous le seuil qu'exige réellement votre cas d'usage, fait toute la différence entre une application qui se dégrade proprement face aux cas difficiles et une application qui propage discrètement des données erronées parce qu'elle n'a jamais été conçue pour attendre autre chose qu'une réponse nette et sans ambiguïté.