Il existe une catégorie d'erreurs de coordonnées qui n'a rien à voir avec la qualité du géocodage sous-jacent, et tout à voir avec la façon dont les nombres obtenus sont ensuite stockés, transmis et utilisés dans des calculs. Un couple de coordonnées parfaitement exact peut accumuler une erreur d'arrondi significative simplement parce qu'il a été représenté, quelque part dans son parcours à travers votre système, dans un type numérique d'une précision insuffisante, et ce type d'erreur est entièrement évitable avec un minimum d'attention.
Les nombres à virgule flottante en simple précision, couramment appelés float32, offrent environ sept chiffres décimaux significatifs. Pour une latitude ou une longitude, qui nécessite plusieurs chiffres avant la virgule rien que pour représenter la partie entière des degrés, il reste nettement moins de chiffres de précision réelle après la virgule que ce qu'offrirait la double précision, couramment float64, pour la même valeur. Concrètement, stocker des coordonnées en float32 plutôt qu'en float64 peut introduire une erreur d'arrondi de l'ordre d'un mètre ou plus, selon la latitude exacte, qui vient s'ajouter, de façon totalement indépendante, aux éventuelles limites de précision de la correspondance de géocodage d'origine.
Ce type d'erreur est facile à introduire par accident et facile à manquer, car il ne ressemble en rien à une erreur évidente : la coordonnée obtenue reste un nombre plausible et bien formé, simplement un nombre qui s'est discrètement éloigné de la valeur d'origine. Il s'introduit souvent par une colonne de base de données définie avec une précision numérique insuffisante, par un format de sérialisation qui utilise par défaut un type numérique plus étroit que prévu, ou par un calcul intermédiaire, une formule de distance ou une transformation de coordonnées, effectué dans un type moins précis que le reste de la chaîne de traitement.
La recommandation pratique est simple : utilisez la virgule flottante en double précision, ou un type décimal à virgule fixe équivalent avec suffisamment de chiffres, pour stocker et calculer les coordonnées dans tout votre système, de bout en bout, et pas seulement à l'endroit où elles sont reçues pour la première fois. Vérifiez en particulier le schéma de votre base de données, car une colonne définie avec un type plus étroit que prévu est l'une des sources les plus courantes et les plus faciles à négliger de ce problème précis, souvent introduite tôt dans un projet et jamais revue une fois que tout fonctionne assez bien pour passer les premiers tests. Vérifiez aussi toute couche de sérialisation ou d'API entre les systèmes, car certains formats et bibliothèques utilisent la simple précision par défaut, sauf indication contraire explicite, ce qui dégrade silencieusement la précision justement à la frontière où vous penseriez le moins à regarder.
Les coordonnées renvoyées par nos endpoints de géocodage direct et de géocodage inverse sont des valeurs décimales en double précision complète. Il vaut la peine de vérifier directement que cette précision est conservée dans votre propre chaîne de stockage et de calcul, plutôt que de supposer qu'elle survit automatiquement à chaque étape.