Il est courant de voir des coordonnées tronquées à quelques décimales avant d'être stockées ou affichées, souvent simplement pour qu'un nombre ait l'air plus net dans un tableau ou une URL. Ce qu'on oublie facilement, c'est que chaque décimale d'une latitude ou d'une longitude correspond à une distance précise et calculable sur le terrain, et qu'arrondir des chiffres revient à supprimer une précision physique réelle, pas seulement un encombrement visuel.
Près de l'équateur, une coordonnée à quatre décimales distingue des lieux distants d'environ dix mètres, à peu près la largeur d'un bâtiment. Passez à deux décimales et vous distinguez désormais des lieux distants de près d'un kilomètre, ce qui peut facilement faire la différence entre un quartier et le suivant. Arrondissez à zéro décimale et vous ne distinguez plus que des degrés entiers, couvrant de nombreux kilomètres. La distance exacte par décimale diminue légèrement à mesure que l'on s'éloigne de l'équateur vers les pôles, pour la longitude en particulier, puisque les méridiens convergent, mais la relation générale entre décimales et distance réelle vaut partout.
Cela devient un vrai problème dans quelques situations courantes. Stocker des coordonnées dans une colonne de base de données dont la précision décimale est insuffisante tronque silencieusement les données à l'insertion, et rien dans cet échec ne ressemble à une erreur, puisque le nombre obtenu reste une coordonnée valide, simplement moins précise. Faire transiter des coordonnées par un système qui les arrondit pour l'affichage, puis utiliser cette valeur arrondie pour un calcul ultérieur, comme une vérification de distance ou une recherche de proximité, propage l'arrondi initial dans chaque résultat en aval. Copier manuellement des coordonnées d'un système à l'autre, lorsqu'une personne supprime des chiffres parce que la valeur complète semblait inutilement longue, a le même effet.
La bonne habitude consiste à stocker et transmettre les coordonnées avec une précision décimale suffisante pour votre cas d'usage réel, en général au moins cinq à six décimales pour tout ce qui doit rester réellement précis à l'échelle du bâtiment ou de la rue, et à n'arrondir pour l'affichage qu'à la toute dernière étape, avant de montrer un nombre à une personne, jamais avant un calcul. Si vous n'avez vraiment besoin que d'une distinction à l'échelle de la ville, arrondir plus tôt ne pose pas de problème, mais ce doit être un choix délibéré fondé sur les besoins de votre application, et non le hasard d'une largeur de colonne de base de données ou d'une habitude de formatage.
Les coordonnées renvoyées ici par le géocodage direct et le géocodage inverse ont une précision décimale suffisante pour les cas d'usage à l'échelle du bâtiment. Ce que vous faites de cette précision en aval, notamment en matière de stockage et d'arrondi, mérite d'être vérifié délibérément plutôt que de supposer qu'elle traverse intacte chaque étape de votre chaîne de traitement.