El error de los 24 kilómetros: Por qué la precisión de los Floats es un problema real

Un vistazo a cómo el truncamiento de coordenadas afecta a las consultas geoespaciales, basado en una depuración real de un servicio de localizadores.

El error de los 24 kilómetros: Por qué la precisión de los Floats es un problema real

Todos hemos pasado por eso. Escribes el código, las pruebas unitarias pasan y el entorno de staging se ve impecable. Despliegas a producción con confianza. Entonces, llega un ticket de un usuario, o peor aún, de un ops manager: “Estoy parado en la ubicación que me dio la app y aquí no hay nada más que un maizal”.

Me encontré con este escenario exacto recientemente mientras trabajaba en un servicio de localización legacy. La lógica de la aplicación parecía sólida: tomar la ubicación del usuario, consultar la base de datos para buscar los registros más cercanos y mostrarlos en un mapa. Sin embargo, en casos extremos específicos, nuestra recomendación “más cercana” estaba desviada por kilómetros.

El culpable no fue un fallo algorítmico complejo ni un timeout del servidor. Fue un problema de calidad de datos sutil y silencioso: La precisión de los Floats.

A menudo tratamos la latitud y la longitud como otro conjunto más de números de punto flotante, truncándolos para ahorrar almacenamiento o simplificar la presentación visual. Pero en el mundo físico, eliminar un decimal no es solo un error de redondeo; es la diferencia entre caminar a la tienda y manejar (conducir) hasta el siguiente pueblo.

En este post, compartiré cómo diagnosticamos un margen de error masivo en las coordenadas de nuestro dataset, que oscilaba entre ~1.1 km y ~96 km, y las implicaciones detrás de eso.

Las matemáticas: Cuando 0.1 es igual a 11 kilómetros

Como ingenieros, amamos la optimización. Miramos una coordenada como 41.88203 y pensamos: “¿Realmente necesito esos últimos tres dígitos? 41.8 se ve más limpio”. Si estás trazando puntos en un mapa estático y alejado (con poco zoom) el mundo, eso podría estar bien. Pero si estás dirigiendo a un usuario a una ubicación de servicio crítica, ese truncamiento es peligroso.

Para entender la escala del problema, tenemos que ponernos nuestros sombreros de Ingeniería Geofísica por un momento: La Tierra es aproximadamente una esfera y medimos las posiciones en grados.

Aquí está el desglose de lo que esos decimales representan realmente en el terreno:

  • 1.0 grado de latitud es aproximadamente 111 km (69 millas).
  • 0.1 grados es aproximadamente 11 km (6.9 millas).
  • 0.01 grados nos lleva a 1.1 km (0.68 millas).

Cuando auditamos nuestro dataset, nos dimos cuenta de que teníamos registros almacenados con solo uno o dos lugares decimales. Si tu base de datos trunca una coordenada a una precisión de 0.1, tu punto de interés tiene un margen de error de casi 11 km. Ya no estás apuntando a un edificio; apenas estás apuntando a una zona postal específica.

Para profundizar en la geodesia detrás de esto, QGIS ofrece excelentes recursos sobre Sistemas de Referencia de Coordenadas. Entender estos fundamentos es crucial cuando tu aplicación depende de consultas geoespaciales.

Ejemplo: La ubicación fantasma

Veamos un ejemplo concreto. Encontramos un registro en nuestra base de datos con las coordenadas 41.8 de latitud y -72.83 de longitud.

A simple vista, esto parece información válida. Pero apliquemos las matemáticas que acabamos de repasar.

Con una latitud de 41.8, la precisión se limita al primer decimal. Esto introduce un margen de error potencial de aproximadamente 111 km en latitud. Incluso con la longitud ligeramente más precisa, el margen de error sigue siendo de alrededor de 11 km.

En este caso específico, esta ambigüedad crea un fallo operativo crítico. Si nuestra app recomenda esta ubicación, el usuario llegaría a las coordenadas solo para encontrar… nada.

El punto de interés real está ubicado aproximadamente a 24 km (15 millas) de las coordenadas almacenadas en nuestra base de datos. Debido a que el registro de la base de datos es impreciso, se dirigía al usuario a una ubicación completamente incorrecta.

Precisión vs. Exactitud: Un dilema de base de datos

Esta investigación resaltó una distinción clásica de datos que a menudo se pasa por alto: Precisión vs. Exactitud.

  • Precisión es cuántos lugares decimales almacenas (por ejemplo, 41.12345 es preciso).
  • Exactitud es qué tan cerca está esa coordenada de la puerta principal física del edificio.

Puedes tener una alta precisión (41.0000000) que es completamente inexacta (ubicación incorrecta). En nuestro caso, teníamos baja precisión, lo que garantizaba baja exactitud.

Reflexión final

La precisión de las coordenadas no es solo un problema matemático; es un problema de experiencia de usuario (UX). Al respetar los decimales, dejas de enviar a los usuarios a los pueblos equivocados.

¿Alguna vez has experimentado un “error de 24 kilómetros” en tus datos? ¿O quizás un error de formato de fecha que tumbó un servicio? Deja un comentario abajo con tus historias de terror.

No tengas miedo de indagar en tus datos legacy: podrías encontrar algunas “optimizaciones” interesantes esperando ser arregladas.