Python'un geopy paketi iki mesafe ölçüm tekniğine sahiptir: Great Circle ve Vincenty formülleri .
>>> 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
Fark ne? Hangi mesafe ölçümü tercih edilir?
Yanıtlar:
Wikipedia'ya göre Vincenty'nin formülü daha yavaş ama daha doğru :
Vincenty'nin formülleri, bir kürenin yüzeyindeki iki nokta arasındaki mesafeyi hesaplamak için kullanılan, Thaddeus Vincenty (1975a) tarafından geliştirilen iki ilişkili yinelemeli yöntemdir ve Dünya figürünün yassı bir küremsi ve küresel bir Dünya varsayan büyük daire mesafesi gibi yöntemlerden daha doğrudur.
İsabetlilik farkı ~0.17%İsrail'de 428 metre uzaklıktadır. Çabuk ve kirli bir hız testi yaptım:
<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)
Kod:
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)
Sonuç olarak: Vincenty'nin formülü, büyük daireye kıyasla hesaplama süresini iki katına çıkarır ve test edilen noktadaki doğruluk kazancı ~% 0,17'dir.
Hesaplama süresi ihmal edilebilir olduğundan, her pratik ihtiyaç için Vincenty'nin formülü tercih edilir.
Güncelleme : Whuber ve CFFK ve CFFK'nin cevabı ile ilgili yorumların ardından, doğruluk kazancının ölçümle değil hatayla karşılaştırılması gerektiğini kabul ediyorum. Bu nedenle, Vincenty'nin formülü ~% 0.17 değil, birkaç büyüklükte daha doğrudur.
Geopy kullanıyorsanız, great_circle ve vincenty mesafeleri elde etmek de eşit derecede uygundur. Bu durumda, neredeyse her zaman size daha doğru sonuç veren sonucu kullanmalısınız, yani vincenty. İki husus (işaret ettiğiniz gibi) hız ve doğruluktur.
Vincenty iki kat daha yavaştır. Ancak muhtemelen gerçek bir uygulamada artan çalışma süresi ihmal edilebilir. Uygulamanız bir milyon mesafe hesaplaması gerektirse bile, sadece birkaç saniyelik bir zaman farkından bahsediyoruz.
Kullandığınız noktalar için, vincenty'deki hata 6 μm ve büyük daire mesafesindeki hata 0.75 m'dir. O zaman vincenty'in 120000 kat daha doğru olduğunu söyleyebilirim (% 0.17 daha doğru değil). Genel noktalar için, büyük daire mesafesindeki hata% 0,5 kadar olabilir. Yani mesafelerde% 0.5 hata ile yaşayabilir misiniz? Rahat kullanım için (Cape Town ile Kahire arasındaki mesafe nedir?), Muhtemelen yapabilirsiniz. Bununla birlikte, birçok CBS uygulamasının daha katı doğruluk gereksinimleri vardır. (% 0,5, 1 km'den 5 m'dir. Bu gerçekten bir fark yaratır.)
Neredeyse tüm ciddi haritalama çalışmaları referans elipsoid üzerinde gerçekleştirilir ve bu nedenle elipsoid üzerinde de mesafelerin ölçülmesi mantıklıdır. Belki bugün büyük daire mesafelerinden kurtulabilirsiniz. Ancak her yeni uygulama için bunun hala kabul edilebilir olup olmadığını kontrol etmeniz gerekecektir. Daha iyisi sadece başlangıçtan itibaren elipsoidal mesafeyi kullanmaktır. Geceleri daha iyi uyuyacaksın.
EK (Mayıs 2017)
@ Craig-hicks tarafından verilen cevaba cevap olarak. Geopy'deki vincenty () yöntemi potansiyel olarak ölümcül bir kusura sahiptir: neredeyse antipodal noktalar için bir hata atar. Koddaki belgeler yineleme sayısının artırılmasını önerir. Ancak bu genel bir çözüm değildir, çünkü vincenty () tarafından kullanılan yinelemeli yöntem bu noktalar için kararsızdır (her yineleme sizi doğru çözümden daha ileri götürür).
Sorunu neden "potansiyel olarak ölümcül" olarak nitelendiriyorum? Çünkü distance fonksiyonunun başka bir yazılım kütüphanesinde herhangi bir şekilde kullanılması istisnanın üstesinden gelebilmelidir. Bir NaN veya büyük daire mesafesini döndürerek bunu yapmak tatmin edici olmayabilir, çünkü elde edilen mesafe fonksiyonu, örneğin nokta nokta ağaçlarında kullanımını engelleyen üçgen eşitsizliğine uymayacaktır.
Durum tamamen kasvetli değil. Python paketim geographiclib , jeodezik mesafeyi hatasız bir şekilde hesaplar. Geopy çekme isteği # 144 Sunulursa, kullanım geographiclib paketine geopy mesafesi işlevini değiştirir. Ne yazık ki bu çekme talebi 2016 Ağustos ayından bu yana dikkat çekiyor.
EK (Mayıs 2018)
geopy 1.13.0 artık mesafeleri hesaplamak için geographiclib paketini kullanıyor. İşte örnek bir çağrı (orijinal sorudaki örneğe dayanarak):
>>> 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
Burada ikinci bir cevap gönderdiğim için özür dilerim, ancak jeodezik mesafeyi hesaplamak için çeşitli algoritmalar için doğruluk ve zamanlama karşılaştırmaları sağlama isteğini @ craig-hicks tarafından yanıtlama fırsatını kullanıyorum. Bu , jeodezik için kullanılan jeodezik için algoritmamın iki uygulamasından birinin kullanılmasına izin veren jeopy için # 144 çekme isteğime yaptığım bir yorumu, biri yerel bir python uygulaması, jeodezik (geographiclib) ve diğer kullanımlar C, jeodezik (pyproj) bir uygulama .
İşte bazı zamanlama verileri. Arama başına süreler mikro saniye cinsindendir
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
İşte benim Geodezik Test Setime dayalı jeodezik hesaplamaların doğruluğu . Hatalar mikron (1e-6 m) cinsinden verilir
method distance destination
geopy vincenty 205.629 141.945
geopy geodesic(pyproj) 0.007 0.013
geopy geodesic(geographiclib) 0.011 0.010
Hannosche'nun hedef işlevindeki kötü bir hatayı düzelten # 194 çekme isteğini ekledim . Bu düzeltme olmadan, vincenty için hedef hesaplamasındaki hata 8.98 metredir.
Test vakalarının% 19.2'si vincenty.distance ile başarısız oldu (iterasyon = 20). Bununla birlikte, test seti bu başarısızlığa neden olacak vakalara çarpıktır.
WGS84 elipsoidindeki rastgele noktalarla Vincenty algoritmasının 1000000 kez 16.6'sında başarısız olacağı garanti edilir (doğru çözüm Vincenty yönteminin sabit olmayan bir sabit noktasıdır).
Vincenty ve iterasyon = 20'nin coğrafi uygulaması ile başarısızlık oranı 1000000 başına 82,8'dir. Yineleme = 200 ile başarısızlık oranı 1000000 başına 21,2'dir.
Bu oranlar küçük olsa da, başarısızlıklar oldukça yaygın olabilir. Örneğin, 1000 rasgele noktadan oluşan bir veri kümesinde (belki de dünya havaalanlarını düşünün), tam mesafe matrisini hesaplamak ortalama 16 kez başarısız olacaktır (yinelemeler = 20 ile).
Geopy.distance paketinin varsayılan olarak vincenty () işlevine sahip bir "distance ()" işlevi sunduğu anlaşılıyor. Gelecekte vincenty () 'den sapma durumunda (olması muhtemel değildir), paket önerisi olarak distance () prensibini kullanmanızı tavsiye ederim. Okumaya devam et:
Bu belge notu, belirttiğiniz vincenty () işlevinin kaynak kodunda bulunmaktadır:
Not: Bu Vincenty mesafesinin uygulanması bazı geçerli noktalar için yakınsama yapamaz. Bazı durumlarda, yineleme sayısı artırılarak bir sonuç elde edilebilir (
iterationssınıfta verilen__init__, varsayılan değer olan 20 anahtar kelime argümanı ). Kullanımı.great_circledaha az tercih edilebilir: class:, marjinal olarak daha az doğru, ancak her zaman bir sonuç üretir.
Yukarıdaki yorum / notu içeren kaynak kodu https://github.com/geopy/geopy/blob/master/geopy/distance.py adresinde bulunabilir vincenty () tanımına ilerleyin
Bununla birlikte, distance () işlevini çağırırken bu paket tarafından kullanılan varsayılan uzaklık işlevi, vincenty () işlevidir, bu da yakınsama başarısızlığının felaket olmadığını ve makul bir yanıtın döndürüldüğünü gösterir - en önemlisi bir istisna oluşturulmaz.
Güncelleme: "cffk" ile belirtildiği gibi, vincenty () işlevi, algoritma birleşmediğinde açıkça bir ValueError istisnası atar - işlev açıklamasında belgelenmemesine rağmen. Bu nedenle, belgeler hatalı.
Vincenty veya haversine veya küresel kosinüs yasası olsun, kullanmayı planladığınız kod, dikkat edilmesi gereken ve hafifletilecek şeyler ve birinin vincenty vs haversine vs sloc sorunları ile nasıl başa çıktığı konusunda bilgelik vardır. herkesin popüler olduğu bilinen veya bilinmeyen gizlenen sorunlarının / edgecas'lerinin farkına vardıkça farklılık gösterir. Tecrübeli programcı bunu biliyor. Yeni başlayanlar olmayabilir. Bir forumdan bir pasaj bazı durumlarda beklenmedik bir şey yaptığında bazılarını hayal kırıklığına uğratmayı umuyorum. Eğer biri bunlardan herhangi birinin bir versiyonunu ciddi şekilde kullanacaksa, vincenty, haversine, sloc, o zaman SE, SO, Reddit, Quora, vb., Bir çözümün ilk kodlamasında sınırlı yardım sağlamış olabilir, ancak bu onların çözümü ya da kabul edilen 'cevap' sorun içermez. Bir proje yeterince önemliyse, makul miktarda araştırmayı hak eder. Kılavuzu okuyun, belgeleri okuyun ve bu kodun kod incelemesi varsa bunu okuyun. Yüzlerce veya daha fazla kez iptal edilmiş bir pasajı veya özeti kopyalamak ve yapıştırmak, güvenliğinin kapsamlı ve güvenli olduğu anlamına gelmez.
Cffk tarafından gönderilen ilgi çekici cevap, paketlenmiş çözümlerde istisnalar veya başka zorluklar yaratabilecek gizlenen edgecas'ların farkında olma noktasını arttırır . Bu görevde yapılan özel iddialar şu anda takip etmek için zaman bütçemin ötesinde, ancak en azından bir vincenty uygulaması da dahil olmak üzere bazı paketlerdeki gerçekten en az bir kişinin iyileştirmeyi önerdiği gizlenen sorunlardan uzaklaşıyorum. bu zorluklarla karşılaşma riskini en aza indirgemek veya ortadan kaldırmak için şu ya da bu şekilde. Vincenty ile ilgili bu konuya daha fazla eklemeyeceğim (çok cahil olmak), ancak bunun yerine haversine, en azından kısmen OP ile ilgili konuya döneceğim.
Python veya başka bir dilde popüler olarak yayınlanan haversin formülü, günümüzde çoğu intel ve intel benzeri sistemlerde ve ARM işlemcilerinde, powerPC'de vb. 180 derece yay mesafesine çok yakın veya yakın olan nadir fakat gerçek ve tekrarlanabilir istisna hatalarına, kayar nokta yaklaşımları ve yuvarlama nedeniyle antipodal noktalara da duyarlı olmak. Bazı yeni başlayanlar henüz bu durumdan ısırılmamış olabilir. Bu fp spec yaklaştığı ve yuvarlandığı için, bu fp64 üzerinde çağıran kodların istisna hatalarına neden olabileceği anlamına gelmez, hayır. Ama bazı kodlar, bazı formüllerin, IEEE 754 fp64'ün yaklaşımlarının ve yuvarlamalarının, bir değerin, böyle bir değeri kusursuz bir şekilde değerlendirmesi beklenen bir matematik yönteminin alanından hafifçe sapmasına neden olabileceği kadar açık kenarları olmayabilir. Bir örnek ... sqrt (). Negatif bir değer sqrt (-0.00000000000000000122739) gibi bir sqrt () yolunu bulursa, bir istisna hatası olacaktır. Haversin formülünde, bir çözüme doğru ilerleyiş şekli, atan2 () 'de iki sqrt () yöntemi vardır. Bir hesaplanır ve daha sonra sqrt kullanılır ki (), dünya üzerinde antipot noktalarda, hafif çok hafif, 0.0 altında veya 1.0'ın üzerinde nedeniyle fp64 yaklaşımları başıboş ve yuvarlama, nadiren, ancak tekrarlanabilir. Tutarlı güvenilir tekrarlanabilirlik, bu bağlamda, bunu istisnai bir risk, izole bir rasgele fluke yerine korumak, hafifletmek için bir edgecase yapar. Gerekli koruma olmadan, haversinin kısa bir python3 snippet'ine bir örnek:
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Çok yakın veya antipot noktalarında, bir nadir, ancak tekrarlı bu aynı enlem, boylam koordinatları ile negatif başıboş Formül l'in ilk satırında hesaplanan. Bu nadir olayları korumak / düzeltmek için , hesaplamadan sonra, aşağıda görüldüğü gibi eklenebilir :
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.0Tabii ki burada tüm işlevi göstermedim, ancak sık sık yayınlandığı gibi kısa bir snippet. Ama sqrt () için bu bir gösteri koruma, test ederek a ve gerekirse ayrıca haricinde bir try her şeyi koymak gereğini kaydederek, bunu normale. Note = '' yukarı üst, bayt kodu aşamasının , işlevin sonucu ile birlikte döndürülürse, bir değere atanmadan önce notun kullanıldığını protesto etmesini önlemektir .
Bu basit değişiklikle, iki ekleme bir test, sqrt () fonksiyonu mutlu olacak ve kod artık ek vardır notu bir sonucu hafif normalize edildiğini uyarı ve neden kod çağıran iade edilebilir. Bazıları umursabilir, bazıları olmayabilir, ama orada, bir istisna hatasını önler, aksi takdirde 'olabilir'. Blok dışında bir deneme istisnayı yakalayabilir, ancak açıkça belirtilmedikçe düzeltmeyebilir. Bir hesaplama satırından hemen sonra düzeltme satırlarını kodlamak daha kolay görünüyor . O zaman iyice ovalanmış giriş burada blok dışında bir deneme gerektirmemelidir.
Özet, Haversine kullanılıyorsa, hiçbir seçim dilinizi önemli bir paket veya kütüphaneyi kullanmak yerine açıkça kodlu, bu testte iyi bir fikir olacağını ve normalleştirmek için bir sırayla 0.0 gerekli aralığına geri <= a <= 1.0 c hesaplamaları ile bir sonraki satırı korumak için . Ancak haversin kod parçacıklarının çoğu bunu göstermez ve riskten bahsetmez.
Deneyim: dünya çapında kapsamlı testler sırasında, 0.001 derecelik artışlarla, bir sabit diski, CPU soğutmasının güvenilirliğini teminatla test eden bir ay boyunca bir istisnaya, güvenilir ve tutarlı bir tekrarlanabilir istisnaya neden olan lat lon kombinasyonları ile doldurdum. hayranım ve sabrım. Evet, o zamandan beri bu günlüklerin çoğunu sildim, çünkü amaçları çoğunlukla ispatı kanıtlamaktı (punta izin verilirse). Ancak, test amacıyla tutulan 'problem lat lon değerleri'nin daha kısa günlükleri var.
Doğruluk: Will bir ve bütün haversinüs sonuç alana küçük bit arka işte bu normalize ederek bazı isabet kaybı? Çok fazla değil, belki de fp64 yaklaşımlarından ve yuvarlamalarından daha fazlası getirilmiyordu, bu da alanın hafifçe kaymasına neden oldu. Haversin'i şimdiden yirmi yılda kabul edilebilir bulursanız - daha basit, daha hızlı, özelleştirilmesi, sorun gidermesi ve bakımı daha kolaysa, haversin projeniz için iyi bir çözüm olabilir.
Gökyüzündeki nesneler arasındaki açısal mesafeleri ölçmek için, yeryüzündeki bir konumdan bakıldığında, azimut ve alt ile gökdelen lat eşdeğeri eşdeğer koordinatlara eşleme yapmak için haversin kullandım, çünkü dikkate alınması gereken elipsoid yok yansıtılan teorik gökdelen, dünya yüzeyi üzerindeki bir konumdan iki nesne arasındaki açısal mesafe bakış açılarını ölçmek için mükemmel bir küredir. İhtiyaçlarıma tam olarak uyuyor. Bu nedenle, haversin bazı uygulamalarda (benim amacım dahilinde) hala çok yararlı ve çok doğrudur ... ancak kullanırsanız, ister dünyadaki CBS veya navigasyon için, ister gökyüzü nesnesi gözlemleri ve ölçümlerinde, test ederek antipot noktaları veya buna çok yakın antipot noktalarının durumda, ave gerektiğinde tekrar alan adına sürüklemek.
Korunmasız haversin internetin her yerinde ve sadece koruma gösteren eski bir usenet yazısı gördüm, sanırım JPL'deki birinden ve bu 1985 öncesi, IEEE 754 kayan nokta spesifikasyonu öncesi olabilir. Diğer iki sayfa, karşıt noktaların yakınındaki olası sorunlardan bahsetti, ancak bu sorunları veya bunların nasıl azaltılabileceğini anlatmadı. Bu nedenle, benim gibi), iyi uygulamaları her zaman daha fazla araştırmaya ve edgecaz'ları test etmeye yetecek kadar iyi anlayamayabilecekleri, kopyaladıkları ve güven içinde bir projeye yapıştırdıkları bazı kodlardan endişe duyuyorlar. cffk'un ilgi çekici direği, sıklıkla belirtilmeyen, snippet'lerde koruma için nadiren alenen kodlanan ve bu şekilde yayınlanan korunmayan ve tartışılmamış sürümlerin miktarına kıyasla bu tür konularla halka açık olması nedeniyle canlandırıcıydı.
20190923 itibariyle, haversin formülü için wiki sayfası, bilgisayar cihazlarındaki kayan nokta sorunları nedeniyle antipodal noktalarda olası sorundan gerçekten bahsetmektedir ...
https://en.wikipedia.org/wiki/Haversine_formula
(bu wiki sayfasında şu anda doğrudan bağlantı kuracağım bölüm için bir html bağlantısı bulunmadığından, sayfa yüklendikten sonra bu tarayıcı sayfasında 'Bu formülleri kullanırken' için bir arama yapın ve haversinin daha resmi olarak bahsedilen antitromal noktalarla ilgili sorununu görün.)
Ve bu diğer siteden de çok kısa bir söz var:
https://www.movable-type.co.uk/scripts/latlong.html
Bu sayfada 'yuvarlama hatalarına karşı koruma da dahil olmak üzere' bir bulgu bulunursa, bu ...
Atan2 yoksa, c 2 ⋅ asinden (min (1, √a)) hesaplanabilir (yuvarlama hatalarına karşı koruma dahil).
Şimdi, yuvarlama hatalarının belirtildiği nadir bir örnek vardır ve asin () sürümü için gösterilen, ancak atan2 () sürümü için belirtilmemiş veya gösterilmemiştir. Ancak en azından yuvarlama hataları riskinden bahsediliyor.
Haversine kullanan herhangi bir 7/24/365 uygulama olan imho, bu korumaya karşı koruma noktalarının yakınında önemli ve basit bir ayrıntı olarak ihtiyaç duyuyor.
Hangi haversin paketlerinin bu korumayı içermediğini veya içermediğini bilmiyorum, ancak tüm bunlara yeniyseniz ve popüler olarak yayınlanan 'snippet' sürümlerini kullanacaksınız, şimdi korumaya ihtiyacınız olduğunu biliyorsunuz ve bu korumanın uygulanması çok basittir, yani, vincenty kullanmıyorsanız ve paketin kodunu değiştirmek için kolay erişim olmadan paketlenmiş bir haversin kullanmıyorsanız.
IOW, vincenty veya haversine veya sloc kullanıldığında, kodla ilgili herhangi bir sorunun, dikkat edilmesi gereken ve hafifletilecek şeylerin ve kişinin vincenty vs haversine vs sloc sorunlarıyla nasıl başa çıkacağının farkına varılması gerekir. popüler olarak bilinen veya bilinmeyen gizlenme sorunları / edgecases.