Siéntete en la libertad de compartir nuestra web y códigos con tus amigos, apóyanos para aumentar esta comunidad.
Solución:
Según Wikipedia, la fórmula de Vincenty es más lento pero más preciso:
Las fórmulas de Vincenty son dos métodos iterativos relacionados utilizados en geodesia para calcular la distancia entre dos puntos en la superficie de un esferoide, desarrollados por Thaddeus Vincenty (1975a) Se basan en la suposición de que la figura de la Tierra es un esferoide achatado, y por lo tanto son más precisos que los métodos como la distancia de círculo máximo que asumen una Tierra esférica.
La diferencia de precisión es ~0.17% en una distancia de 428 metros en Israel. Hice una prueba de velocidad rápida y sucia:
: Total 0:00:04.125913, (0:00:00.000041 per calculation)
: Total 0:00:02.467479, (0:00:00.000024 per calculation)
Código:
import datetime
from geopy.distance import great_circle
from geopy.distance import vincenty
p1 = (31.8300167,35.0662833)
p2 = (31.83,35.0708167)
NUM_TESTS = 100000
for strategy in vincenty, great_circle:
before = datetime.datetime.now()
for i in range(NUM_TESTS):
d=strategy(p1, p2).meters
after = datetime.datetime.now()
duration = after-before
print "%-40s: Total %s, (%s per calculation)" % (strategy, duration, duration/NUM_TESTS)
Para concluir: La fórmula de Vincenty duplica el tiempo de cálculo en comparación con el círculo máximo, y su ganancia de precisión en el punto probado es ~ 0.17%.
Dado que el tiempo de cálculo es insignificante, se prefiere la fórmula de Vincenty para cada necesidad práctica.
Actualizar: Siguiendo los comentarios perspicaces de whuber y la respuesta de cffk y cffk, estoy de acuerdo en que la ganancia de precisión debe compararse con el error, no con la medición. Por lo tanto, la fórmula de Vincenty es unos pocos órdenes de magnitud más precisa, no ~ 0,17%.
Si está utilizando geopy, entonces las distancias great_circle y vincenty son igualmente convenientes de obtener. En este caso, casi siempre deberías usar el que te dé el resultado más preciso, es decir, Vincent. Las dos consideraciones (como señala) son la velocidad y la precisión.
Vincenty es dos veces más lento. Pero probablemente en una aplicación real el aumento del tiempo de ejecución es insignificante. Incluso si su aplicación requirió un millón de cálculos de distancia, solo estamos hablando de una diferencia en los tiempos de un par de segundos.
Para los puntos que utiliza, el error en Vincent es de 6 μm y el error en la distancia del gran círculo es de 0,75 m. Entonces diría que Vincenty es 120000 veces más preciso (en lugar de un 0,17% más preciso). Para los puntos generales, el error en la distancia del círculo máximo puede llegar al 0,5%. Entonces, ¿puedes vivir con un error del 0,5% en las distancias? Para uso casual (¿cuál es la distancia de Ciudad del Cabo a El Cairo?), Probablemente puedas. Sin embargo, muchas aplicaciones de SIG tienen requisitos de precisión mucho más estrictos. (0.5% son 5 m en 1 km. Eso realmente marca la diferencia).
Casi todo el trabajo de mapeo serio se lleva a cabo en el elipsoide de referencia y, por lo tanto, tiene sentido que las distancias también se midan en el elipsoide. Tal vez hoy pueda salirse con la suya con distancias de círculo máximo. Pero para cada nueva aplicación, deberá comprobar si sigue siendo aceptable. Es mejor usar la distancia elipsoidal desde el principio. Dormirás mejor por la noche.
ADENDA (mayo de 2017)
En respuesta a la respuesta dada por @ craig-hicks. El método vincenty () en geopy tiene un defecto potencialmente fatal: arroja un error para puntos casi antípodas. La documentación del código sugiere aumentar el número de iteraciones. Pero esta no es una solución general porque el método iterativo utilizado por vincenty () es inestable para tales puntos (cada iteración lo lleva más lejos de la solución correcta).
¿Por qué caracterizo el problema como “potencialmente fatal”? Porque cualquier uso de la función de distancia dentro de otra biblioteca de software debe poder manejar la excepción. Manejarlo devolviendo un NaN o la distancia del círculo máximo puede no ser satisfactorio, porque la función de distancia resultante no obedecerá a la desigualdad del triángulo que impide su uso, por ejemplo, en árboles de puntos estratégicos.
La situación no es del todo sombría. Mi paquete de Python Geographiclib calcula la distancia geodésica con precisión sin fallas. La solicitud de extracción de geopy # 144 cambia la función de distancia de geopy para usar el paquete geopy si está disponible. Desafortunadamente, esta solicitud de extracción ha estado en el limbo desde Augest 2016.
ADENDA (mayo de 2018)
geopy 1.13.0 ahora usa el paquete geopylib para calcular distancias. Aquí hay una llamada de muestra (basada en el ejemplo de la pregunta original):
>>> from geopy.distance import great_circle
>>> from geopy.distance import geodesic
>>> p1 = (31.8300167,35.0662833) # (lat, lon) - https://goo.gl/maps/TQwDd
>>> p2 = (31.8300000,35.0708167) # (lat, lon) - https://goo.gl/maps/lHrrg
>>> geodesic(p1, p2).meters
429.1676644986777
>>> great_circle(p1, p2).meters
428.28877358686776
Mis disculpas por publicar una segunda respuesta aquí, pero aprovecho la oportunidad para responder a la solicitud de @ craig-hicks para proporcionar comparaciones de precisión y tiempo para varios algoritmos para calcular la distancia geodésica. Esto parafrasea un comentario que hago a mi solicitud de extracción # 144 para geopy que permite el uso de una de las dos implementaciones de mi algoritmo para geodésicas que se usará dentro de geopy, una es una implementación nativa de Python, geodésica (geodesiclib), y el otro usos una implementación en C, geodésica (pyproj).
Aquí hay algunos datos de tiempo. Los tiempos están en microsegundos por llamada
method dist dest
geopy great_circle 20.4 17.1
geopy vincenty 40.3 30.4
geopy geodesic(pyproj) 37.1 31.1
geopy geodesic(geographiclib) 302.9 124.1
Aquí está la precisión de los cálculos geodésicos basados en mi conjunto de prueba geodésica. Los errores se dan en unidades de micrones (1e-6 m)
method distance destination
geopy vincenty 205.629 141.945
geopy geodesic(pyproj) 0.007 0.013
geopy geodesic(geographiclib) 0.011 0.010
He incluido la solicitud de extracción de Hannosche # 194 que corrige un error grave en la función de destino. Sin esta solución, el error en el cálculo del destino para Vincent es de 8,98 metros.
El 19,2% de los casos de pruebas fallaron con vincenty.distance (iteraciones = 20). Sin embargo, el conjunto de pruebas está sesgado hacia los casos que podrían provocar esta falla.
Con puntos aleatorios en el elipsoide WGS84, se garantiza que el algoritmo Vincenty fallará 16.6 de cada 1000000 veces (la solución correcta es un punto fijo inestable del método Vincenty).
Con la implementación de geopy de Vincenty e iteraciones = 20, la tasa de fallas es 82.8 por 1000000. Con iteraciones = 200, la tasa de fallas es 21.2 por 1000000.
Aunque estas tasas son pequeñas, las fallas pueden ser bastante comunes. Por ejemplo, en un conjunto de datos de 1000 puntos aleatorios (piense en los aeropuertos del mundo, tal vez), calcular la matriz de distancia completa fallaría en promedio 16 veces (con iteraciones = 20).
Aquí puedes ver las comentarios y valoraciones de los lectores
Recuerda que puedes dar difusión a este artículo si lograste el éxito.