Python의 geopy 패키지 에는 Great Circle 및 Vincenty의 공식 이라는 두 가지 거리 측정 기술이 있습니다.
>>> from geopy.distance import great_circle
>>> from geopy.distance import vincenty
>>> p1 = (31.8300167,35.0662833) # (lat, lon) - https://goo.gl/maps/TQwDd
>>> p2 = (31.8300000,35.0708167) # (lat, lon) - https://goo.gl/maps/lHrrg
>>> vincenty(p1, p2).meters
429.16765838976664
>>> great_circle(p3, p4).meters
428.4088367903001차이점은 무엇입니까? 어떤 거리 측정이 선호됩니까?
답변:
Wikipedia에 따르면 Vincenty의 공식은 느리지 만 더 정확합니다 .
Vincenty의 공식은 Thaddeus Vincenty (1975a)가 개발 한 구상 표면에서 두 점 사이의 거리를 계산하기 위해 측지학에서 사용되는 두 가지 관련 반복 방법입니다. 구형 지구를 가정하는 원거리와 같은 방법보다 더 정확합니다.
~0.17%이스라엘 의 정확도 차이는 428 미터입니다. 나는 빠르고 더러운 속도 테스트를 만들었습니다.
<class 'geopy.distance.vincenty'> : Total 0:00:04.125913, (0:00:00.000041 per calculation)
<class 'geopy.distance.great_circle'> : Total 0:00:02.467479, (0:00:00.000024 per calculation)암호:
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)결론 : Vincenty의 공식은 대원에 비해 계산 시간을 두 배로 늘리며 테스트 지점에서 정확도 이득은 ~ 0.17 %입니다.
계산 시간은 무시할 수 있기 때문에 모든 실제 필요에 대해 Vincenty의 공식이 선호됩니다.
업데이트 : whuber 및 cffk 및 cffk 의 답변에 대한 통찰력있는 의견에 따라 정확성 게인을 측정이 아닌 오류와 비교해야한다는 데 동의합니다. 따라서 Vincenty의 공식은 0.17 %가 아닌 몇 배나 더 정확합니다.
geopy를 사용하는 경우 great_circle 및 vincenty 거리를 얻는 것이 똑같이 편리합니다. 이 경우 거의 항상보다 정확한 결과를 제공하는 결과를 사용해야합니다 (예 : vincenty). 두 가지 고려 사항 (알다시피)은 속도와 정확성입니다.
Vincenty는 두 배 느립니다. 그러나 실제 응용 프로그램에서는 실행 시간이 길어질 수 있습니다. 귀하의 응용 프로그램이 백만 거리 계산을 요구하더라도, 우리는 몇 초의 시간 차이에 대해서만 이야기하고 있습니다.
사용하는 포인트의 빈센트 오차는 6μm이고 원거리 거리 오차는 0.75m입니다. 나는 빈센트가 120000 배 더 정확하다고 말하고 싶습니다 (0.17 % 더 정확함). 일반적인 점의 경우 원거리 거리가 큰 오차는 최대 0.5 %입니다. 따라서 거리에서 0.5 %의 오차로 살 수 있습니까? 평상시 사용 (케이프 타운에서 카이로까지의 거리는 어떻습니까?) 그러나 많은 GIS 응용 프로그램에는 훨씬 더 엄격한 정확도 요구 사항이 있습니다. (0.5 %는 1km 이상 5m입니다. 실제로 차이가 있습니다.)
거의 모든 진지한 매핑 작업은 참조 타원체에서 수행되므로 타원체에서도 거리를 측정해야합니다. 어쩌면 오늘은 원거리를 멀리 갈 수도 있습니다. 그러나 각각의 새로운 응용 프로그램에 대해 이것이 여전히 수용 가능한지 확인해야합니다. 시작부터 타원체 거리를 사용하는 것이 좋습니다. 밤에는 잘 자요.
부록 (2017 년 5 월)
@ craig-hicks의 답변에 대한 답변. geopy의 vincenty () 메소드에는 치명적인 결함이있을 수 있습니다. 거의 반발 점에 오류가 발생합니다. 코드의 문서는 반복 횟수 증가를 제안합니다. 그러나 vincenty ()가 사용하는 반복적 메소드가 그러한 점에서 불안정 하기 때문에 이것은 일반적인 해결책이 아닙니다 (각 반복은 올바른 솔루션에서 더 멀어집니다).
문제를 "잠재적으로 치명적인"것으로 특성화하는 이유는 무엇입니까? 다른 소프트웨어 라이브러리 내에서 거리 기능을 사용하면 예외를 처리 할 수 있어야합니다. 결과 거리 함수는 예를 들어 유리한 지점 트리에서의 사용을 방해하는 삼각형 부등식에 따르지 않기 때문에 NaN 또는 큰 원거리를 반환하여 처리하는 것은 만족스럽지 않을 수 있습니다.
상황이 완전히 황폐하지는 않습니다. 내 파이썬 패키지 geographiclib 는 오류없이 측지 거리를 정확하게 계산합니다. geopy 풀 요청 # 144 가 사용할 수 있다면 사용 geographiclib 패키지에 geopy의 거리 함수를 변경합니다. 불행히도이 끌어 오기 요청은 2016 년 8 월 이후 림보에있었습니다.
부록 (2018 년 5 월)
geopy 1.13.0은 이제 거리 계산을 위해 geographiclib 패키지를 사용합니다. 다음은 샘플 호출입니다 (원래 질문의 예를 기반으로 함).
>>> 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여기에 두 번째 답변을 게시 한 것에 대해 사과드립니다. 그러나 @ craig-hicks의 요청에 응답하여 측지 거리를 계산하기위한 다양한 알고리즘에 대한 정확도 및 타이밍 비교를 제공 할 기회를 얻었습니다. 이 역설은 지오피에 대한 내 풀 요청 # 144에 대한 주석입니다. 지오메트리 내 지오 데식 알고리즘의 두 가지 구현 중 하나를 사용할 수 있습니다. 하나는 기본 파이썬 구현, geodesic (geographiclib) 및 기타 용도입니다. C에서 구현 측지선 (pyproj) .
다음은 몇 가지 타이밍 데이터입니다. 통화 당 시간은 마이크로 초입니다
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내 측지선 테스트 세트를 기반으로 측지선 계산의 정확도는 다음과 같습니다 . 오차는 미크론 (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대상 기능의 잘못된 버그를 수정하는 hannosche의 풀 요청 # 194 를 포함 시켰습니다 . 이 수정 사항이 없으면 빈센트의 대상 계산 오류는 8.98 미터입니다.
테스트 사례의 19.2 %가 vincenty.distance (반복 = 20)로 실패했습니다. 그러나 테스트 세트는 이러한 실패가 발생할 경우로 기울어집니다.
WGS84 타원체에서 임의의 점을 사용하면 Vincenty 알고리즘이 1000000 번 중 16.6 회 실패 할 수 있습니다 (올바른 솔루션은 Vincenty 방법의 고정 점이 불안정합니다).
Vincenty의 Geopy 구현 및 반복 = 20의 경우 실패율은 1000000 당 82.8이고 반복 = 200의 경우 실패율은 1000000 당 21.2입니다.
비록이 비율은 적지 만 실패는 매우 일반적 일 수 있습니다. 예를 들어 1000 개의 랜덤 포인트 (세계 공항을 생각할 수도 있음)의 데이터 세트에서 전체 거리 매트릭스 계산은 평균 16 회 실패합니다 (반복 = 20).
geopy.distance 패키지는 기본적으로 vincenty ()로 설정된 "distance ()"함수를 제공하는 것으로 보입니다. 나는 패키지 권장 사항 인 distance ()를 원칙적으로 사용하는 것이 좋습니다. 미래에 vincenty ()와 다른 경우 (그렇지 않을 수도 있음). 계속 읽기 :
이 문서 참고 사항은 지정한 vincenty () 함수의 소스 코드에 포함되어 있습니다.
참고 :이 Vincenty 거리 구현은 일부 유효한 점에 대해 수렴되지 않습니다. 경우에 따라 반복 횟수 (
iterations클래스에 지정된 키워드 인수,__init__기본값은 20) 를 늘려 결과를 얻을 수 있습니다 . : class :를 사용하는 것이 바람직 할 수 있습니다..great_circle정확도는 낮지 만 항상 결과를 생성합니다.
위의 주석 / 노트가있는 소스 코드는 https://github.com/geopy/geopy/blob/master/geopy/distance.py 에서 찾을 수 있습니다. vincenty ()의 정의로 스크롤 하십시오.
그럼에도 불구하고 캘리브레이션 distance () 일 때 해당 패키지에서 사용하는 기본 거리 함수는 vincenty () 함수입니다. 이는 수렴 실패가 치명적이지 않으며 합리적인 답변이 반환됨을 의미합니다. 가장 중요한 예외는 생성되지 않습니다.
업데이트 : "cffk"에서 알 수 있듯이 vincenty () 함수는 함수 설명에 문서화되어 있지는 않지만 알고리즘이 수렴하지 않으면 명시 적으로 ValueError 예외를 발생시킵니다. 따라서 문서는 버그가 있습니다.
빈센트 또는 소르 세인 또는 코사인의 구형 법칙을 사용하든, 사용하려는 코드의 잠재적 인 문제, 조심하고 완화해야 할 것들, 그리고 빈센트 대 하 세르 인 대 슬로크 문제를 다루는 방법을 알고있는 지혜가 있습니다. 각기 숨어있는 문제 / 가장자리를 인식하게되면 다를 수 있습니다. 노련한 프로그래머가 이것을 알고 있습니다. 초보자는 그렇지 않을 수 있습니다. 포럼의 스 니펫이 특정 경우 예기치 않은 일을 할 때 좌절감을 덜어주기를 바랍니다. 빈센트, 헤르자인, 슬로크, SE, SO, 레딧, 쿼라 등의 버전 중 일부를 심각하게 사용하려는 경우 솔루션의 초기 코딩에 제한적인 도움을 줄 수 있지만 그 의미는 아닙니다. 그들의 해결책이나 받아 들여진 '답변'에는 문제가 없습니다. 프로젝트가 충분히 중요하다면, 적절한 리서치가 필요합니다. 설명서를 읽고, 문서를 읽고, 해당 코드에 대한 코드 검토가 있으면 읽어보십시오. 100 회 이상 공표 된 스 니펫 또는 요지를 복사하여 붙여 넣어도 안전성이 포괄적이고 보장되는 것은 아닙니다.
cffk가 게시 한 흥미로운 답변은 패키지 솔루션에서 예외 또는 기타 어려움을 유발할 수있는 숨어있는 엣지 케이스를 인식하고 있다는 점을 지적 합니다. 그 게시물에 대한 구체적인 주장은 현재 추구하는 시간 예산을 초과하지만 적어도 한 사람이 개선을 제안한 것에 대해 적어도 하나의 빈약 한 구현을 포함하여 특정 패키지에 숨어있는 문제가 실제로 있다는 것을 벗어났습니다. 이러한 어려움을 겪을 위험을 최소화하거나 제거하기 위해 나는 빈약에 관한 주제에 대해 더 이상 언급하지 않지만 (너무 무지한 것임) 적어도 부분적으로는 OP와 관련된 주제에 대해 허세 인으로 바뀔 것이다.
파이썬이나 다른 언어로 널리 퍼져있는 헤르 세인 공식은 오늘날 대부분의 인텔 및 인텔 유사 시스템에서 IEEE 754 부동 소수점 사양을 사용하고 ARM 프로세서, powerPC 등을 사용하기 때문에 부동 소수점 근사와 반올림으로 인해 180 도의 아크 거리, 대구점 근처 또는 거의 드물지만 실제적이고 반복 가능한 예외 오류에 취약합니다. 이 상황으로 일부 초보자는 아직 물지 않았을 수 있습니다. 이 fp 사양은 대략적으로 반올림되므로 fp64를 호출하는 코드가 예외 오류를 일으킬 수 있음을 의미하지는 않습니다. 그러나 일부 코드는 일부 공식은 IEEE 754 fp64의 근사와 반올림으로 인해 값이 완벽하게 평가 될 것으로 예상되는 수학 방법의 영역에서 약간 벗어날 수 있습니다. 예를 들어 ... sqrt (). 음수 값이 sqrt (-0.00000000000000000122739)와 같은 sqrt ()로 들어가면 예외 오류가 발생합니다. 해 세린 공식에서 솔루션으로 진행되는 방식에는 atan2 ()에 두 개의 sqrt () 메소드가 있습니다. 그만큼계산하고 SQRT에 사용되는 (), 세계의 정반대 지점에서 약간 매우 약간, 0.0 이하 또는 1.0 이상으로 인해 FP64 근사치를 이탈하고 라운딩 드물게하지만 반복적. 이러한 맥락에서 일관된 신뢰성있는 반복성은 격리 된 랜덤 플루크 (random fluke)가 아니라 보호해야 할 엣지 케이스 인 예외 위험을 초래합니다. 다음은 필요한 보호 기능이없는 짧은 python3 스리 펫의 예입니다.
import math as m
a = m.sin(dlat / 2)**2 + m.cos(lat1) * m.cos(lat2) * m.sin(dlon / 2)**2
c = 2 * m.atan2(m.sqrt(a), m.sqrt(1 - a))
distance = Radius * c아주 가까운 또는 정반대 지점에서, A는 거의하지만 반복적 것과 동일한 위도 경도 좌표, 음극을 이탈 할 수있다 화학식 I의 첫번째 라인에서 계산. 애프터 / 드문 사건을 해결 한 간단하게 추가 할 수 있습니다, 보호하기 위해 아래와 같이 계산 :
import math as m
note = ''
a = m.sin(dlat / 2)**2 + m.cos(lat1) * m.cos(lat2) * m.sin(dlon / 2)**2
if a < 0.0: a = 0.0 ; note = '*'
if a > 1.0: a = 1.0 ; note = '**'
c = 2 * m.atan2(m.sqrt(a), m.sqrt(1 - a))
distance = Radius * c
# note = '*' # a went below 0.0 and was normalized back to 0.0
# note = '**' # a went above 1.0 and was normalized back to max of 1.0물론 여기에 전체 기능을 표시하지는 않았지만 너무 자주 게시되는 짧은 발췌 문장. 그러나 이것은 a 를 테스트하고 필요한 경우 정규화 하여 sqrt ()에 대한 보호를 보여줍니다. 또한 모든 것을 시도해 볼 필요가 없습니다. note = ''up top은 바이트 코드 스테이지 가 함수의 결과와 함께 리턴되는 경우 값이 지정되기 전에 해당 노트 가 사용 중임 을 항의하지 않도록 방지하는 것입니다.
이 간단한 변경으로 두 개의 추가하는 테스트는 SQRT () 함수는 행복 할 것이다, 그리고 코드는 이제 추가가 주 결과가 약간 정상화되었음을 경고, 왜에 코드를 호출로 반환 할 수 있습니다. 일부는 관심을 가질 수도 있고, 그렇지 않을 수도 있지만 예외 오류를 방지 할 수도 있습니다. try except 블록은 예외를 포착 할 수 있지만 명시 적으로 작성하지 않는 한이를 수정하지는 않습니다. 그것은 바로 후 코드 수정 라인 (들)에보다 쉽게 보인다 계산 라인. 철저히 문질러 진 입력은 여기서는 블록을 제외하고는 전혀 시도하지 않아도됩니다.
요약 : 패키지 또는 라이브러리를 사용하지 않고 명시 적으로 코딩 된 hasrsine을 사용하는 경우, 선택한 언어에 관계없이 0.0 <= a <= 1.0의 범위로 테스트하고 정규화 하는 것이 좋습니다. c 계산으로 다음 줄을 보호합니다 . 그러나 대부분의 haversine 코드 스 니펫은이를 보여주지 않으며 위험을 언급하지 않습니다.
경험 : 전 세계에서 0.001도 단위로 철저한 테스트를 수행하는 동안, 한 달 동안의 CPU 냉각의 신뢰성을 부수적으로 테스트하는 한 달 동안 예외, 신뢰할 수 있고 일관된 반복 가능한 예외를 유발하는 위도 조합으로 하드 드라이브를 채웠습니다. 팬과 내 인내심. 예, 그 목적은 대부분 포인트를 증명하는 것이기 때문에 그 로그의 대부분을 삭제했습니다 (말장난이 허용되는 경우). 그러나 테스트 목적으로 유지되는 '문제 지연 값'에 대한 짧은 로그가 있습니다.
정확성 : a 와 전체 haversine 결과를 다시 작은 영역으로 정규화하여 정확도를 잃게됩니까? fp64 근사치와 반올림이 이미 소개 된 것보다 많지 않을 수도 있습니다. 간단하고 빠르며 쉽게 사용자 정의, 문제 해결 및 유지 관리하는 데 빈센트보다 허세 인을 수용 할 수있는 경우, 소르 세인은 프로젝트에 적합한 솔루션 일 수 있습니다.
나는 지구상의 위치에서 보았을 때 방위각과 고도를 하늘 구의 위도와 같은 좌표로 매핑하면서 하늘의 물체 사이의 각도 거리를 측정하기 위해 오버 헤드 투영 된 스카이 스피어에서 hasrsine을 사용했습니다. 투영 된 이론적 스카이 스피어는 지구 표면의 한 위치에서 두 물체 사이의 각도 거리 모양 각도를 측정 할 때 완벽한 구체입니다. 그것은 내 요구에 완벽하게 부합합니다. 따라서, 헤르 세인은 특정 용도 (물론 내 목적 내에서)에서 여전히 매우 유용하고 매우 정확합니다. 그러나 GIS 나 내비게이션을 위해 지구상에서 또는 하늘 물체 관측 및 측정에서 사용하는 경우 보호하십시오. 대퇴 점 또는 대퇴 점 근처의 경우 ,그리고 필요할 때 필요한 도메인으로 다시 몰아 넣습니다.
보호되지 않은 헤르 세인은 인터넷 전체에 있으며, 일부 보호 기능을 보여준 오래된 유즈넷 게시물을 보았습니다 .JPL의 누군가로부터 생각하고 1985 년 이전의 IEEE 754 부동 소수점 사양 일 수 있습니다. 다른 두 페이지에서는 대변 지점 근처에서 가능한 문제에 대해 언급했지만 이러한 문제 나 완화 방법에 대해서는 설명하지 않았습니다. 따라서 신입 사원 (나 같은)은 자신이 복사하여 신뢰하는 프로젝트에 붙여 넣은 일부 코드에 대한 추가 연구 및 엣지 케이스를 충분히 이해하기에 충분하지 않을 수도 있습니다. cffk의 흥미로운 게시물은 이러한 유형의 문제에 대해 공개적이어서 자주 언급되지 않았으며 스 니펫 보호를 위해 거의 공개적으로 코딩되지 않았으며 게시되지 않은 비보호 버전과 논의되지 않은 버전의 양과 비교하여 거의 논의되지 않았습니다.
20190923 현재, 헤르 세인 공식 위키 페이지는 실제로 컴퓨팅 장치의 부동 소수점 문제로 인해 대두 지점에서 발생할 수있는 문제를 언급하고 있습니다 ...
https://ko.wikipedia.org/wiki/Haversine_formula
(현재 위키 페이지에는 직접 링크 할 섹션에 대한 HTML 앵커가 없으므로 페이지가로드 된 후 해당 브라우저 페이지에서 '이 수식을 사용할 때'를 검색하십시오. 보다 공식적으로 언급 된 반포도 점에 대한 haversine의 문제를 참조하십시오.)
그리고이 다른 사이트에도 매우 간단히 언급되어 있습니다.
https://www.movable-type.co.uk/scripts/latlong.html
해당 페이지에서 '라운딩 오류 방지 기능'을 찾으면 다음과 같은 결과가 나타납니다.
atan2를 사용할 수없는 경우 c는 2 ⋅ asin (min (1, √a))에서 계산할 수 있습니다 (반올림 오류 방지 포함).
이제는 반올림 오류가 언급되는 경우가 드물고, asin () 버전에 대해서는 보호 기능이 표시되었지만 atan2 () 버전에는 표시되지 않았거나 표시되지 않았습니다. 그러나 반올림 오류의 위험은 언급되어 있습니다.
헤르 세인을 사용하는 24/7/365 애플리케이션 인 imho는 중요하고 간단한 세부 사항으로서 대 지점 근처에서 이러한 보호가 필요합니다.
어떤 보호 기능 패키지가이 보호 기능을 포함하거나 포함하지 않는지 모르겠지만이 모든 기능을 처음 접하는 경우 널리 보급 된 '스 니펫'버전을 사용하려는 경우 이제 보호가 필요하다는 것을 알게되었습니다. 보호 기능은 구현하기가 매우 간단합니다. 즉, 빈센트를 사용하지 않고 패키지 코드를 쉽게 수정할 수있는 패키지 된 소르 신을 사용하지 않는 경우입니다.
IOW, 빈센트 또는 허세 인 또는 슬로크를 사용하든 코드와 관련된 문제, 조심해야 할 사항 및 완화해야 할 사항, 빈센트 대 헤르 세인 대 슬로크 문제를 처리하는 방법은 각 사람이 인식하는 방식에 따라 다릅니다. 잘 알려 지거나 알려지지 않은 숨은 문제 / 가장자리.