Hay una categoría de errores en las coordenadas que no tiene nada que ver con la calidad de la geocodificación subyacente, y sí con la forma en que los números resultantes se almacenan, transmiten y procesan después. Un par de coordenadas perfectamente preciso puede acumular un error de redondeo significativo solo por representarse en algún punto de su recorrido por tu sistema con un tipo numérico de precisión insuficiente, y este tipo de error se puede evitar por completo prestando un poco de atención deliberada.
Los números en coma flotante de precisión simple, conocidos habitualmente como float32, tienen aproximadamente siete dígitos decimales significativos de precisión. Para un valor de latitud o longitud, que necesita varios dígitos antes del punto decimal solo para representar la parte entera de los grados, eso deja claramente menos dígitos de precisión real después del punto decimal de los que ofrecería la coma flotante de doble precisión, habitualmente float64, para el mismo valor. En la práctica, almacenar coordenadas como float32 en lugar de float64 puede introducir un error de redondeo del orden de un metro o más, según la latitud exacta, totalmente independiente de las limitaciones de precisión que ya tuviera la coincidencia de geocodificación original, y que se suma a ellas.
Este tipo de error es fácil de introducir sin querer y fácil de pasar por alto, porque no parece un error de ninguna forma evidente: la coordenada resultante sigue siendo un número plausible y bien formado, solo que se ha desviado silenciosamente un poco del valor original. Suele colarse a través de una columna de base de datos definida con una precisión numérica insuficiente, de un formato de serialización de datos que usa por defecto un tipo numérico más estrecho del previsto o de un cálculo intermedio, como una fórmula de distancia o una transformación de coordenadas, realizado con un tipo de menor precisión que el que usa el resto del proceso.
La recomendación práctica es sencilla: usa coma flotante de doble precisión, o un tipo decimal de coma fija equivalente con suficientes dígitos, para almacenar y calcular coordenadas en todo tu sistema, de principio a fin, y no solo en el punto donde las recibes por primera vez. Revisa en concreto el esquema de tu base de datos, ya que una columna definida con un tipo más estrecho del previsto es una de las fuentes más comunes y fáciles de pasar por alto de este mismo problema, a menudo introducida al principio de un proyecto y nunca revisada una vez que funciona lo bastante bien como para superar las pruebas iniciales. Revisa también cualquier capa de serialización o de API entre sistemas, ya que algunos formatos y bibliotecas usan precisión simple por defecto salvo que se indique lo contrario, lo que reduce la precisión en silencio justo en la frontera donde menos esperarías buscar.
Las coordenadas que devuelven nuestros endpoints de geocodificación directa e inversa tienen valores decimales con doble precisión completa. Conviene verificar directamente que esa precisión se conserva en tu propio proceso de almacenamiento y cálculo, en lugar de suponer que sobrevive automáticamente a cada paso.