Hangi algoritmalar haritadaki A noktasından B noktasına yönleri hesaplar?


543

Harita sağlayıcıları (Google veya Yahoo! Maps gibi) yol tariflerini nasıl önerir?

Yani, muhtemelen mesafeler de dahil olmak üzere bir şekilde gerçek dünya verilerine sahipler, ancak belki de sürüş hızları, kaldırımların varlığı, tren tarifeleri vb. Gibi şeyler var. Ama verilerin daha basit bir formatta olduğunu varsayalım, çok büyük bir yönlendirilmiş grafik kenar ağırlıkları mesafeleri yansıtır. Bir keyfi noktadan diğerine hızlı bir şekilde yön hesaplayabilmek istiyorum. Bazen bu noktalar birbirine yakın olacak (bir şehir içinde), bazen birbirinden çok uzak olacaklar (kros).

Grafik çok büyük olduğu için Dijkstra'nın algoritması gibi grafik algoritmaları çalışmaz. Neyse ki, A * gibi sezgisel algoritmalar muhtemelen işe yarayacaktır. Ancak, verilerimiz çok yapılandırılmıştır ve belki de bir tür katmanlı yaklaşım işe yarayabilir? (Örneğin, önceden hesaplanmış yönleri belirli "anahtar" noktalar ile bazı yerel yönler arasında saklayın. Ardından uzaktaki iki noktanın yönleri, kilit noktalara yerel yönleri, başka bir kilit noktaya küresel yönleri ve ardından yerel yönlendirin.)

Pratikte hangi algoritmalar kullanılır?

PS. Bu soru, çevrimiçi haritalama yönlerinde tuhaflıklar bularak motive edildi. Üçgen eşitsizliği aksine, bazen Google Maps düşünüyor XZ daha uzun sürer ve daha uzak olduğu gibi bir ara noktası kullanarak daha XYZ . Ama belki de yürüme yönleri başka bir parametre için de optimize edilebilir mi?

PPS. Üçgen eşitsizliğin bir başka ihlali (bana göre) bir tür katmanlı yaklaşım kullandıklarını gösteriyor: XZ ve XYZ . Birincisi, biraz yoldan çıkmış olsa da, tanınmış Boulevard de Sebastopol'u kullanıyor gibi görünüyor.

Düzenleme : Bu örneklerin hiçbiri artık işe yaramıyor gibi görünüyor, ancak her ikisi de orijinal gönderi sırasında işe yaradı.


3
BTW, A * algoritması "Dijkstra'nın, hedefe" mesafe "ile ilgili bir alt sınır sağlayan ek bilgi mevcutsa, araştırılması gereken alt bölümün büyüklüğünü azaltan Dijkstra algoritmasının genelleştirilmesidir"
Mitch Wheat

Re A *: evet, gerçekten. Neyse ki, bizim durumumuzda, bu "ek bilgi" örneğin düz çizgi mesafesi kullanılarak elde edilebilir. Yukarıda "Dijkstra" dediğimde vanilya Dijkstra demek istiyorum.
A. Rex

Yaya yol tarifleri? Başka hiçbir yerde bilmem, ama buralarda (Hampshire, İngiltere), büyük G'nin yaya verileri yok - beni yaya bölgesi vb. Çevresindeki yollar boyunca yönlendiriyor. Bunun için iyi olan tek şey, rota için harcanan zamanı tahmin etmektir :)
jTresidder

Özellikle yol tarifleri sürüş veya yürüyüş için olup olmadığını umursamıyorum. Sadece nasıl çalıştıklarını bilmek istiyorum! Orada yürüyüş bağlantıları var nedeni, çünkü Paris'te dolaşmak ve 66 Wallace çeşmeleri görmek için bir yol bilgisayar. (Bu haritaların uç noktaları Wallace fıskiyeleri olmalıdır.)
A. Rex

Bu sorudaki ödül, özellikle büyük sağlayıcılardan birinde çalışan insanlardan daha fazla ve daha iyi cevapları teşvik etmektir . Veri yapıları, algoritmalar, önceden ne kadar önceden hesaplandığı vb. Hakkındaki yorumlar takdir edilmektedir.
A. Rex

Yanıtlar:


526

Yönlendirme algoritması üzerinde çalışmayı içeren bir harita şirketinde 18 ay geçiren biri olarak konuşmak ... evet, Dijkstra's birkaç değişiklikle çalışıyor:

  • Dijkstra'nın bir zamanlar kaynağından desteye yapmak yerine , her iki uçtan başlayıp ortada buluşana kadar her iki tarafı da genişletiyorsunuz. Bu işin yaklaşık yarısını ortadan kaldırır (2 * pi * (r / 2) ^ 2 vs pi * r ^ 2).
  • Kaynağınız ve hedefiniz arasındaki her şehrin arka sokaklarını keşfetmekten kaçınmak için birkaç harita verisi katmanına sahip olabilirsiniz: Yalnızca otoyolları içeren bir 'karayolları' katmanı, yalnızca ikincil sokakları içeren 'ikincil' katmanı vb. Ardından, daha ayrıntılı katmanların yalnızca daha küçük bölümlerini keşfederek gerektiği gibi genişlersiniz. Açıkçası bu açıklama çok fazla ayrıntı bırakıyor, ancak fikri anlıyorsunuz.

Bu hatlardaki değişikliklerle, çok makul bir zaman diliminde ülkeler arası yönlendirme bile yapabilirsiniz.


29
Gerçek dünyada bu konuda çalışan biri, harika! Başka bir yorumda bahsedilen Google hakkındaki makalede olduğu gibi ön hesaplama yapmanın ne kadar mümkün olduğu hakkında bir fikriniz var mı?
A. Rex

10
Bu nitelikte herhangi bir ön işlem yapmadık, ama kesinlikle ilginç bir optimizasyon gibi görünüyor.
Nick Johnson

29
“sadece en verimli çözüm değil, sadece bir çözüm üretilmesi garantilidir” Bu doğru değildir; kullanılan sezgisel tarama kabul edilebilir olduğu sürece, A * algoritması en düşük maliyetli yolu üretir. Kabul edilebilir, maliyetin asla fazla tahmin edilmediği, ancak hafife alınabileceği anlamına gelir (ancak kötü tahminler algoritmayı yavaşlatacaktır). Ön işlemden elde edilen verilerin kullanılması, daha iyi bir kabul edilebilir sezgisel ve bu nedenle A * 'nın daha hızlı çalışmasını sağlamaya yardımcı olacaktır.
a1kmm

6
Aslında, daha fazla dikkate alındığında, tamamen haklısınız. Hedef düğüm ve hedef arasındaki Büyük Daire Mesafesini değerlendirilmekte olan kenarın maliyetine ekleyerek, bunu kullanmak için mevcut bir algoritmayı geliştirebilirsiniz. Aslında algoritmamızın bunu yapıp yapmadığından emin değilim - ama çok mantıklı bir optimizasyon.
Nick Johnson

11
A *, en kötü durumda (tüm yolların eşdeğer olduğunu söyleyen bir buluşsal yöntem), Djikstra'nınkine tam olarak eşittir.
Tordek

111

Bu soru son yıllarda aktif bir araştırma alanı olmuştur. Ana fikir bir yapmaktır önişlemeyi grafikte kez için, hızlandırmak bütün aşağıdaki sorgular . Bu ek bilgilerle güzergahlar çok hızlı hesaplanabilir. Yine de, Dijkstra Algoritması tüm optimizasyonların temelini oluşturmaktadır.

Arachnid , hiyerarşik bilgilere dayanarak çift yönlü arama ve kenar budama kullanımını açıkladı. Bu hızlandırma teknikleri oldukça iyi çalışıyor, ancak en yeni algoritmalar bu tekniklerden kesinlikle daha iyi performans gösteriyor. Mevcut algoritmalarla, en kısa yollar bir kıta yolu ağında bir milisaniyeden daha kısa sürede hesaplanabilir . Değiştirilmemiş Dijkstra algoritmasının hızlı bir şekilde uygulanması yaklaşık 10 saniyeye ihtiyaç duyar .

Mühendislik Hızlı Rota Planlama Algoritmaları makalesi , bu alandaki araştırmanın ilerlemesine genel bir bakış sunmaktadır. Daha fazla bilgi için bu makalenin referanslarına bakın.

Bilinen en hızlı algoritmalar, verilerdeki yolun hiyerarşik durumu hakkında, yani bir otoyol veya yerel bir yol ise, bilgiyi kullanmaz. Bunun yerine, bir ön işleme adımında rota planlamasını hızlandırmak için optimize edilmiş kendi hiyerarşisini hesaplarlar. Bu ön hesaplama daha sonra aramayı budamak için kullanılabilir: Dijkstra Algoritması sırasında başlangıç ​​ve varış noktalarından uzakta yavaş yolların dikkate alınması gerekmez. Faydaları çok iyi performans ve sonuç için doğruluk garantisidir.

İlk optimize edilmiş rota planlama algoritmaları sadece statik yol ağlarıyla ilgilidir, bu da grafikteki bir kenarın sabit bir maliyet değerine sahip olduğu anlamına gelir. Trafik sıkışıklığı veya araca bağımlı kısıtlamalar gibi dinamik bilgileri hesaba katmak istediğimiz için bu pratikte doğru değildir. En son algoritmalar da bu tür sorunlarla ilgilenebilir, ancak hala çözülmesi gereken sorunlar vardır ve araştırmalar devam etmektedir.

TSP için bir çözüm hesaplamak için en kısa yol mesafelerine ihtiyacınız varsa, muhtemelen kaynaklarınız ve hedefleriniz arasındaki tüm mesafeleri içeren matrislerle ilgileniyorsunuzdur. Bunun için Karayolu Hiyerarşilerini Kullanarak Çoktan Çokya En Kısa Yolları Hesaplamayı düşünebilirsiniz . Bunun son 2 yılda daha yeni yaklaşımlarla geliştirildiğini unutmayın.


1
Gerçekten aydınlatıcı. Bahsettiğiniz yeni yaklaşımlar nelerdir?
Tomas Pajonk

1
Özellikle Kasılma Hiyerarşileri. Bununla ilgili daha fazla bilgiyi burada bulabilirsiniz: algo2.iti.kit.edu/routeplanning.php . Bunun hakkında bir google teknik konuşması da var: youtube.com/watch?v=-0ErpE8tQbw
SebastianK

19

Üçgen eşitsizlik ihlallerini ele almak için, umarız optimize ettikleri ekstra faktör sağduyudur. Kaos ve yıkıma yol açabileceğinden, mutlaka en kısa veya en hızlı rotayı istemezsiniz . Yol tariflerinin kamyon dostu olan ve her sat-nav-takip sürücüsünün gönderilmesi ile başa çıkabilen ana yolları tercih etmesini istiyorsanız, üçgen eşitsizliğini hızlı bir şekilde atarsınız [1].

Y, X ve Z arasındaki dar bir yerleşim sokağıysa, muhtemelen kullanıcı açıkça XYZ isterse, Y yoluyla kısayolu kullanmak istersiniz. XZ isterlerse, biraz daha ilerlemiş ve biraz daha uzun sürse bile ana yollara bağlı kalmalıdırlar. Braess'in paradoksuna benzer - eğer herkes en kısa, en hızlı rotayı almaya çalışırsa, ortaya çıkan tıkanıklık, artık herkes için en hızlı rota olmadığı anlamına gelir. Buradan grafik teorisinden oyun teorisine geçiyoruz.

[1] Aslında, tek yönlü yollara izin verdiğinizde ve simetri gereksinimini kaybettiğinizde, üretilen mesafelerin matematiksel anlamda bir mesafe fonksiyonu olacağı umudu ölür. Üçgen eşitsizliğini de kaybetmek, sadece yaraya tuz sürmektir.


14

İşte doğruluk açısından karşılaştırılmış ve kanıtlanmış dünyanın en hızlı yönlendirme algoritmaları:

http://algo2.iti.uka.de/schultes/hwy/schultes_diss.pdf

İşte konuyla ilgili bir Google teknoloji konuşması:

http://www.youtube.com/watch?v=-0ErpE8tQbw

İşte şemalar tarafından tartışıldığı gibi otoyol hiyerarşileri algoritmasının bir uygulaması (şu anda sadece Berlin'de, arayüzü yazıyorum ve bir mobil sürüm de geliştiriliyor):

http://tom.mapsforge.org/


9

Daha önce Google, Microsoft veya Yahoo Maps üzerinde çalışmadım, bu yüzden nasıl çalıştıklarını size söyleyemem.

Ancak, bir enerji şirketi için kamyon filoları için bir programlama ve yönlendirme uygulaması içeren özel bir tedarik zinciri optimizasyon sistemi tasarladım. Bununla birlikte, rota belirleme kriterlerimiz, inşaat veya trafik yavaşlaması veya şerit kapanışlarından çok daha işe özgüdür.

Kamyonları programlamak ve yönlendirmek için ACO (Ant koloni optimizasyonu) adlı bir teknik kullandık. Bu teknik, yönlendirme sorunlarını çözmek için seyahat eden satıcı problemine uygulanan bir AI tekniğidir. ACO'nun püf noktası, yönlendirme hakkında bilinen gerçeklere dayanan bir hata hesaplaması oluşturmaktır, böylece grafik çözme modeli ne zaman çıkılacağını bilir (hata ne zaman küçüktür).

Bu teknik hakkında daha fazla bilgi edinmek için Google ACO veya TSP'yi kullanabilirsiniz. Ancak bunun için açık kaynaklı AI araçlarından hiçbirini kullanmadım, bu yüzden bir tane öneremem (SWARM'ın oldukça kapsamlı olduğunu duydum).


4
yönlendirme! = çay kaşığı. tsp'de tüm mesafeleri bilirsiniz ve durma sırasını optimize edersiniz - bu noktadan noktaya bir algo değildir.
Karussell

8

Grafik çok büyük olduğu için Dijkstra'nın algoritması gibi grafik algoritmaları çalışmaz.

Bu argüman her zaman geçerli değildir, çünkü Dijkstra genellikle tam grafiğe bakmayacak, sadece çok küçük bir altkümeye bakacaktır (grafik ne kadar iyi bağlanırsa, bu altküme o kadar küçük olur).

Dijkstra aslında iyi kalpli grafikler için oldukça iyi performans gösterebilir. Öte yandan, dikkatli parametreleştirme ile A * her zaman iyi veya daha iyi performans gösterir. Verilerinizde nasıl performans göstereceğini zaten denediniz mi?

Bununla birlikte, diğer insanların deneyimlerini duymakla da ilgileneceğim. Elbette, Google Map'in araması gibi önemli örnekler özellikle ilginçtir. Yönlendirilmiş en yakın komşu buluşsal yöntemi gibi bir şey hayal edebiliyorum.


2
Diyelim ki A noktasından B noktasına, en uygun mesafe d olan yön bulmaya çalışıyorsunuz. Dijkstra'nın algoritması en azından A'dan en fazla d mesafedeki tüm noktaları inceleyecektir. A San Francisco ve B Boston ise, bu, ABD'nin çoğunu incelediği anlamına gelir. N'est-ce pas?
A. Rex

2
Evet öyle. Almak istediğim, bunun yerine A * 'nın kullanılabilmesi ve (buluşsal yöntem kullansa bile) her zaman en uygun çözümü bulmasıdır!
Konrad Rudolph

Evet tabi ki. Orijinal yazımı yazdıktan sonra kullandığım "sezgisel" kelimesini düşündüm. Burada biraz yanlış, çünkü en uygun çözümü buluyor.
A. Rex

2
De, nokta A * olmasıdır kullanır (aksine bir sezgisel olan bir) bir sonraki adım belirlenmesi. Bu tek karar gerçekten yetersiz olabilir. Ancak, sadece çalışma zamanını etkiler, sonucu değil, çünkü sadece Dijstra'dan ne kadar iyi olduğunu tahmin eder.
Konrad Rudolph

8

Statik yol ağları için sorgu süreleri bakımından mevcut teknik durum, Abraham ve ark. Tarafından önerilen Hub etiketleme algoritmasıdır. http://link.springer.com/chapter/10.1007/978-3-642-20662-7_20 . Alanın kapsamlı ve mükemmel bir şekilde yazılmış bir araştırması kısa bir süre önce http://research.microsoft.com/pubs/207102/MSR-TR-2014-4.pdf adlı bir Microsoft teknik raporu olarak yayınlandı .

Kısa versiyonu ...

Hub etiketleme algoritması, statik yol ağları için en hızlı sorguları sağlar, ancak çalışması için büyük miktarda koç gerektirir (18 GiB).

Geçiş düğümü yönlendirmesi biraz daha yavaş olsa da, yalnızca yaklaşık 2 GiB bellek gerektirir ve daha hızlı bir ön işleme süresi vardır.

Daralma Hiyerarşileri, hızlı ön işleme süreleri, düşük alan gereksinimleri (0.4 GiB) ve hızlı sorgu süreleri arasında hoş bir takas sağlar.

Hiç kimse algoritmaya tamamen hakim değildir ...

Peter Sanders'ın bu Google teknoloji konuşması ilgi çekici olabilir

https://www.youtube.com/watch?v=-0ErpE8tQbw

Ayrıca Andrew Goldberg tarafından yapılan bu konuşma

https://www.youtube.com/watch?v=WPrkc78XLhw

Kasılma hiyerarşilerinin açık kaynaklı bir uygulaması, KIT'deki Peter Sanders araştırma grubu web sitesinden edinilebilir. http://algo2.iti.kit.edu/english/routeplanning.php

Ayrıca, CRP algoritmasının kullanımı hakkında Microsoft tarafından yazılmış kolay erişilebilir bir blog yazısı ... http://blogs.bing.com/maps/2012/01/05/bing-maps-new-routing-engine/


7

Floyd Warshall'ın burada bahsettiği algoritmayı görmekten biraz şaşırdım . Bu algoritma çalışması Dijkstra'nınki gibi. Ayrıca, çok daha fazla ara noktaya izin vermeye devam etmek istediğiniz sürece hesaplamanıza izin veren çok güzel bir özelliğe sahiptir. Bu nedenle doğal olarak eyaletlerarası veya otoyolları kullanan yolları oldukça hızlı bir şekilde bulacaktır.


6

Bunu birçok kez yaptım, aslında birkaç farklı yöntem deniyorum. Haritanın boyutuna (coğrafi) bağlı olarak, haversin işlevini sezgisel olarak kullanmayı düşünebilirsiniz.

Yaptığım en iyi çözüm sezgisel işlev olarak düz çizgi mesafeli A * kullanmaktı. Ancak haritadaki her nokta (kavşak veya tepe noktası) için bir tür koordinatlara ihtiyacınız vardır. Sezgisel işlev için farklı ağırlıklar da deneyebilirsiniz.

f(n) = k*h(n) + g(n)

burada k, 0'dan biraz daha büyüktür.


4

Muhtemelen büyük konumlar ve katmanlı haritalar arasındaki önceden hesaplanmış rotalar üzerindeki cevaba benzer, ancak benim anlayışım, oyunlarda, A * hızlandırmak için, makro navigasyon için çok kaba bir haritanız ve makro yön sınırına navigasyon. Hesaplamak için 2 küçük yolunuz var ve bu nedenle arama alanınız, hedef için tek bir yol yapmaktan çok daha küçük. Ve bunu çok yapmakla uğraşıyorsanız, bu verilerin çoğunu önceden hesaplamış olursunuz, bu nedenle aramanın en azından bir kısmı, bir yol aramak yerine önceden hesaplanmış veriler için bir aramadır.


3

Bu benim için saf bir spekülasyon, ancak arama alanını daraltmak için yönlendirilmiş haritayı kaplayan bir etki haritası veri yapısı kullanabildiklerini düşünüyorum. Bu, arama algoritmasının, istenen yolculuk uzun olduğunda yolu ana rotalara yönlendirmesini sağlar.

Bunun bir Google uygulaması olduğu göz önüne alındığında, sihrin çoğunun kapsamlı önbellekleme ile yapıldığını varsayalım. :) Basit bir arama ile yanıtlanması için isteklerin büyük bir kısmı (% 20?% 50?) İçin izin verilen en yaygın% 5 Google Map rota isteklerini önbelleğe almanız şaşırmam.


"Etki haritası veri yapısı" için iyi bir referansınız var mı? Teşekkürler!
A. Rex

3

Bu konuda biraz daha düşüncelerim vardı:

1) Haritaların fiziksel bir organizasyonu temsil ettiğini unutmayın. Her kavşağın enlem / boylamını saklayın. Hedefinizin yönünde uzanan noktaların çok ötesine bakmanıza gerek yoktur. Sadece kendinizi bloke ederseniz bunun ötesine geçmeniz gerekir. Üstün bağlantıların bir bindirmesini saklarsanız, onu daha da sınırlandırabilirsiniz - normalde bunlardan birini asla son hedefinizden uzaklaşmayacak şekilde geçemezsiniz.

2) Dünyayı sınırlı bağlantı ile tanımlanan bir dizi bölgeye ayırın, bölgeler arasındaki tüm bağlantı noktalarını tanımlayın. Konumunuzdan her bir bağlantı noktasına başlangıç ​​ve bitiş bölgesi rotası için, bağlantı noktaları arasındaki basit harita arasındaki bölgeler için kaynak ve hedefinizin hangi bölgelerde olduğunu bulun. (Ben ikincisinin zaten önceden hesaplandığından şüpheleniyorum.)

Bölgelerin bir metropol alanından daha küçük olabileceğini unutmayın. Onu ayıran arazi özelliklerine sahip herhangi bir şehir (örneğin, bir nehir) birden fazla bölge olacaktır.


3

Kullanılan buluşsal yöntemleri çok merak ettim, bir süre önce Santa Rosa yakınlarındaki aynı başlangıç ​​noktasından Yosemite Ulusal Parkı'ndaki iki farklı kamp alanına rota aldık. Bu farklı hedefler, her iki güzergâhın, son birkaç mil tekrar sapmadan önce son 100 mil boyunca (CA-120 boyunca) birleşmesine rağmen oldukça farklı rotalar (I-580 veya CA-12 ile) üretti. Bu oldukça tekrarlanabilirdi. İki rota yaklaşık 100 mil boyunca 50 mil uzaktaydı, ancak mesafeler / saatler beklediğiniz gibi birbirine oldukça yakındı.

Ne yazık ki bunu yeniden üretemiyorum - algoritmalar değişmiş olmalı. Ama algoritmayı merak ettim. Tahmin edebileceğim tek şey, uzaklardan görüldüğü gibi varış yerleri arasındaki küçük açısal farka mükemmel bir şekilde duyarlı olan bazı yönlü budamaların olması ya da son varış yeri seçimi ile seçilen farklı önceden hesaplanmış segmentlerin olmasıdır.


3

OpenStreetMap tabanlı hızlı bir Açık Kaynak rota planlayıcısı olan GraphHopper'dan bahsetmişken, biraz literatür okudum ve bazı yöntemler uyguladım. En basit çözüm bir Dijkstra'dır ve basit bir gelişme, düğümlerin yaklaşık yarısını araştıran çift yönlü bir Dijkstra'dır. İki yönlü Dijkstra ile tüm Almanya'da bir rota zaten 1sn sürer (araba modu için), C'de muhtemelen sadece 0,5sn;

Burada çift ​​yönlü Dijkstra ile gerçek bir yol arama animasyonlu bir gif yarattım . Ayrıca Dijkstra'yı "hedefe yönelik bir Dijkstra" olan A * gibi daha hızlı hale getirmek için daha fazla fikir var . Ayrıca bunun için bir gif-animasyon oluşturdum.

Ama bunu nasıl daha hızlı yapabilirim?

Sorun, bir yol araması için konumlar arasındaki tüm düğümlerin araştırılması gerektiğidir ve bu zaten Almanya'da olduğu gibi gerçekten maliyetlidir ve bunlardan birkaç milyonu vardır. Ancak Dijkstra vb.'nin ek bir ağrı noktası, bu tür aramaların çok fazla RAM kullanmasıdır.

Sezgisel çözümler vardır, ancak hiyerarşik katmanlarda grafiği (yol ağı) düzenleyen kesin çözümler de vardır, her ikisi de pro & eksilere sahiptir ve esas olarak hız ve RAM problemini çözer. Bazılarını bu cevapta listeledim .

GraphHopper için Büzülme Hiyerarşilerini kullanmaya karar verdim çünkü uygulanması nispeten 'kolay' ve grafiğin hazırlanması için zaman almıyor. Çevrimiçi örnek GraphHopper Haritalarımızda test edebileceğiniz gibi yine de çok hızlı yanıt süreleriyle sonuçlanmaktadır . Örneğin Güney Afrika'dan doğu Çin'e 23000km mesafe ve araba için yaklaşık 14 gün sürüş süresi ile sonuçlanır ve sunucuda sadece ~ 0.1s sürer.


Hedefe yönelik arama yapmak için Yer işaretlerini kullanan Bidirectional Dijkstra, yalnızca Bidirectional Dijkstra'dan daha etkilidir. Bkz. Www14.informatik.tu-muenchen.de/lehre/2010SS/sarntal/… Ancak bu makale, biraz zor olan potansiyel işlevi hesaplamak veya yer işaretlerini seçmek için yeterince ayrıntılı değildir.
Paul Chernoch

2

Birkaç yıldır yönlendirme üzerinde çalıştım, yakın zamanda müşterilerimin ihtiyaçları tarafından yönlendirilen bir aktivite patlaması ve A * 'nın yeterince hızlı olduğunu gördüm; gerçekten optimizasyon veya daha karmaşık algoritmalar aramaya gerek yoktur. Muazzam bir grafiğin üzerinden geçmek sorun değil.

Ancak hız, tüm yönlendirme ağına sahip olmasına bağlıdır, bu da bellekte sırasıyla rota segmentlerini ve kavşakları temsil eden yayların ve düğümlerin yönlendirilmiş grafiğini kastediyorum. Ana zaman ek yükü, bu ağı oluşturmak için harcanan zamandır. Windows çalıştıran ve tüm İspanya'ya yönlendiren sıradan bir dizüstü bilgisayara dayanan bazı kaba figürler: ağı oluşturmak için geçen süre: 10-15 saniye; bir rotayı hesaplamak için geçen süre: ölçmek için çok kısa.

Diğer önemli şey, ağı istediğiniz kadar yönlendirme hesaplaması için yeniden kullanabilmektir. Algoritmanız düğümleri en iyi rotayı kaydetmek için bir şekilde işaretlediyse (mevcut düğüme toplam maliyet ve buna en iyi ark) - A * 'da olduğu gibi - bu eski bilgileri sıfırlamanız veya temizlemeniz gerekir. Yüz binlerce düğümden geçmek yerine, bir nesil sayı sistemi kullanmak daha kolaydır. Her düğümü verilerinin üretim numarası ile işaretleyin; yeni bir rota hesaplarken üretim numarasını artırın; eski nesil numaraya sahip herhangi bir düğüm eskidir ve bilgileri yok sayılabilir.


1

OP'deki haritalarda ne olduğunu görüyorum:

Ara nokta belirtilmiş olan rotaya bakın: Düz olmayan yol nedeniyle rota hafifçe geriye doğru gider.

Algoritmaları geri gitmezse, daha kısa yolu görmez.


İlginç fikir. PPS'ime OP'ye bir ihlal daha ekledim. Lütfen bir göz atın ve orada bir açıklama görüp göremeyeceğinize bakın.
A. Rex

Zoom A noktasında YOL aşağı - maks. Üç noktalı rotanın nasıl batıya, güneye, doğuya gittiğine dikkat edin. Bence, bir chokepoint'dan geçmesi gerekmedikçe geri takip etmeyi sevmeyen bir algoritmaya bakıyoruz.
Loren Pechtel

PPS örneğimde, başlangıç ​​adresini "10 Avenue de Flandre, 75019 Paris" olarak değiştirin. Bu, bahsettiğiniz küçük backtrack'i kaldırır, ancak sorun hala oradadır. Bence asıl mesele gerçekten o ana Blvd'de kalmak istiyor ...
A. Rex

1
Sanırım bu durumda buldum: Bunları araba ile yapın ve zamanlamalar mantıklı. Muhtemelen büyük yolu daha hızlı görüyor ve yürüyüş rotası onu kısmıyor.
Loren Pechtel

1
Not: İlk sorun da bu standartla mantıklı, buna neden olan backtrack olmayabilir.
Loren Pechtel

0

Tüm çiftlerin en kısa yol algoritması, bir grafikteki tüm köşeler arasındaki en kısa yolları hesaplar. Bu, bir kaynak ve hedef arasındaki en kısa yolu her bulmak istediğinde yolun hesaplanmasını gerektirmek yerine yolların önceden hesaplanmasını sağlar. Floyd-Warshall algoritması çok çiftli en kısa yol algoritmasıdır.


-4

Haritalar asla haritanın tamamını dikkate almaz. Benim tahminim: - 1. Bulunduğunuz yere göre, o yere bir yer ve yerler yükler. 2. Hedefi aradığınızda, haritanın diğer kısmını yüklediklerinde ve iki yerden bir grafik oluşturduklarında ve en kısa yol algoritmalarını uyguladıklarında budur.

Ayrıca, en kısa yolların hesaplanmasında kullanılan şüpheli Dinamik programlama önemli bir teknik vardır. Buna da başvurabilirsiniz.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.