Uygun bir yönlendirme motoru seçmeye yardımcı olun


16

Ben bir rota planlama sistemi inşa ediyorum, ama hala hangi yönlendirme motorunu kullanacağım karar vermek zorunda. Şimdiye kadar pgrouting ve neo4j buldum.

Benim yol ağım bir postgresql / postgis veritabanında (bir shapefile ithal) var. Düğümleri (hangi yöne gideceğinizi veya çıkmaz uçları karar vermeniz gereken yolların uç noktaları) ve kenarları (genellikle birbirini izleyen birkaç yoldan oluşur) ayıklamak için sorgular yaptım. Tüm kenarlarım iki yönlü.

Ana hedefim, mesafe = maliyetin olduğu bir A-yıldız algoritması kullanarak bu ağdaki rotaları hesaplamak.

Duygularım, neo4j gibi bir grafik veritabanının (sadece bu amaç için yapıldığı gibi) gitmenin yolu olduğunu söylüyor, ancak varsayılan olarak A-yıldızını desteklemiyor gibi görünüyor ve ayrıca gerçek bir geometri duygusu yok . Haritalar yerine sosyal ağlar için daha uygun görünüyor.

  • Pgrouting benim ihtiyaçlarımı karşılar mıydı?
  • Anında sorgular için yeterince hızlı mı (+ -2000 düğüm, + -4000 kenar)? Normalde bu A-star için birkaç ms olacaktır, ama sql bu uygulama hakkında emin değilim.
  • Pgrouting A-star bana düğümlerin ve kenarların bir listesini veriyor mu?
  • Çoğu örnekte pgrouting i görüyorum genellikle rota hesaplandıktan sonra komutların bir listesi vardır ("X sola dönün, vb" gibi). Pgrouting bunu üretir mi yoksa başka bir sistemden mi?

Umarım birisi bana hangi sistemi seçeceğiyle ilgili bilgi verebilir. Neo4j, pgrouting veya başka bir sistem.


3
Çoğu yönlendirme algoritmasının bir "geometri duygusu" ile çalışmadığını, bunun yerine geometrik bir öznitelik hesaplanır ve maliyet olarak kullanılır (yani bir çoklu çizginin mesafe ölçüsü). Hiç Neo4j kullanmadım, ama gerçekten yetenekli görünüyor ve yakında kullanıyorum. Belgelere bir göz attım ve A-Star'ı kullanmak mümkün görünüyor: docs.neo4j.org/chunked/stable/graph-algo.html docs.neo4j.org/chunked/stable/… pgRouting de yetenekli ve Ben büyük bir hayranıyım. Bu iki çözümün performansını karşılaştırmak ilginç olacaktır.
Allan Adair

İlk olarak, urbansim'e açık kaynak arazi kullanım modeline bakmanızı öneririm . Yönlendirme sorunuza gelince, bu uygulama planlıyorsa, işlevsellik ve kullanıcı arabirimi için önce TransCAD, CUBE, PLANAR veya EMME / 2 gibi yazılımlara bakmanızı öneririm. Genellikle yazılımlarının 1 saat veya 2 saat demo cd'lerini verirler (bunu hissetmek için bir veya iki saat çalıştırabileceğiniz yazılım). Çevrimiçi kullanım veya masaüstü kullanımı için bir şeyler oluşturmak istiyorsanız pgRouting; ancak, deneyimden, bazen, atölye / öğretici onu nasıl tasvir ettiği kadar kolay değildir.
dassouki

A-star çalışma ile pgrouting var ve harika! İlk 3 sorumda evet yanıtı var. Yine de burada birisinin ayrıntılı navigasyon yönleri oluşturma hakkında bir şey biliyor mu merak ediyorum. Hesaplanan rotanın çıkışından ayrıntılı yönler üreten ("200m sonra sola dönün, vb.") Pgrouting ile birlikte çalışan bazı araçlar var mı?
mrg

Yanıtlar:


8

Şu anda araştırma makalesi amacıyla sizinle aynı sorunu araştırıyorum. Bu iki veritabanını test etmeye başlamadan önce, sizinle aynı varsayımı yaptım. Bu Neo4j grafik veritabanı bu tür bir sorun için mükemmel bir çözüm olacaktır. Ve kısmen öyle, ama birçok problemle.

İlk sorun, A-Star'ın REST API (sunucu) üzerinden değil, yalnızca gömülü veritabanı kullanıyorsanız uygulanmasıdır. Neo4j'ü REST API ile kullanmak istiyorsanız, sadece Dijkstra algoritması desteklenir. İkinci sorun Neo4j için donanım belleği gereksinimleridir. "Daha büyük" ağlarda yönlendirme (Dijkstra) için çok fazla RAM'e ihtiyacınız vardır. Büyük ağ için Almanya OSM yol veri tabanının boyutu gibi bir şey demek istiyorum . Testlerimi 6GB RAM sunucusunda çalıştırdım (şu anda sahip olduğum tek şey) ve sadece daha küçük ağlar OutOfMemory istisna hataları olmadan yönlendirilebilir. Test durumlarımdaki "küçük" ağlar, örneğin Avusturya veya Hırvatistan için OSM yol veritabanıdır. Eşzamanlı sorgular Neo4j ile hala test etmedim.

Bu sorunların tümü pgRouting'de mevcut değildir. Bellek böyle bir sorun değildir, ancak eşzamanlı sorgular gereken bellek miktarını artırır. Örneğin, iki eşzamanlı isteğiniz varsa, iki kat bellek gerekir. Bu, bir Almanya OSM veri kümesi için bile bir sorun değildi, pgRouting, eşzamanlı tüm isteklerin sorunsuz bir şekilde yönlendirildi.

Performans: Çoğu durumda, Neo4j pgRouting'den daha iyi performans gösterir. Ancak yalnızca verilen veri kümesi için yeterli bellek varsa ve tüm düğümler ve ilişkiler bellekte ise (sıcak başlangıç). Performansın artması / azalması birçok faktöre bağlıdır, ancak çoğunlukla ağın boyutuna ve kaynak ile hedef düğüm arasındaki mesafeye (atlamalar) bağlıdır.

Ağ boyutunuz oldukça küçük olduğundan, bellekle ilgili herhangi bir sorun yaşamamanız gerekir. Muhtemelen Neo4j kötü bir seçim değildir, ancak standart ilişki veritabanlarına göre "küçük" farklı bir veri modeline uyum sağlamanız gerekir.

Size soruları cevaplamak için:

  • PgRouting'de, zaten uygulanmış olan sql'deki AStar uygulaması hakkında endişelenmenize gerek yoktur.
  • Evet, pgRouting size düğümlerin ve kenarların listesini verebilir
  • Ben pgRouting sorguları etrafında bazı özel çalışmaları ile bu tür bilgi verebilir sanmıyorum. Ama belki yanılıyorum, belki biri bunu yaptı ve bu soru hakkında size daha fazla yardımcı olabilir.

Size doğrudan yardımcı olup olmayacağını bilmiyorum, ama bulduğum en hızlı yönlendirme sunucusundan biri osm2po . OSM veri kümesiyle çalışır ve oldukça hızlıdır. Şu anda sadece dijkstra uygulanmaktadır, ancak geliştirici AStar'ı da duyurdu. Umarım bunlardan bazıları size yardımcı olur. :)


Her iki sistemi de test eden birinden haber almak güzel. Bu arada pgrouting ile ilgili çok daha fazla deneyime sahibim. Pgrouting her sorgu için tüm grafik oluşturur ve bu büyük ağlar (Almanya boyutu) için oldukça yavaş yapar, bu yüzden neden pgrouting Neo4j daha az bellek gerektirir görmüyorum fark ettim. Bir sonraki denemem, gerçek zamanlı yönlendirme için daha hızlı bir yanıt sağlamak için tüm grafiği ram ve statik olarak sabitlemek (neo4j, nx_spatial vb.) Olacaktır.
mrg

Evet, grafik ne kadar büyük olursa, pgrouting ve neo4j arasındaki fark da o kadar fazladır. Muhtemelen tüm grafiği belleğe en hızlı çözümden daha fazla koyarsanız, bununla ilgili bir soru yok. Tüm grafik hafızaya yüklendiğinde Neo4j oldukça hızlıdır. Nx_spatial hakkında bilmiyorum, ben test etmedim, ama belki de yapacağım. Neo4j'den bile daha iyi performans gösterebileceğine inanıyorum. Ancak bu çözüm, uygulamanız için kabul edilebilirse iyidir.
Mario Miler

1
@mrg hala sizin için bir sorun olup olmadığından emin değil, ancak OSRM (C ++) ve GraphHopper (Java) var. Her iki ölçeği de dünya çapında grafiklere ve örneğin GraphHopper'ın Almanya için 1 gb'ın altında olması gerekiyor (burada yazarım)
Karussell

Karussell, bilgi için teşekkürler! OSRM'yi zaten buldum, ancak GraphHopper benim için yeni.
mrg

0

Ayrıca RW Net 4 paketimize de bakabilirsiniz (www.routeware.dk). Bir SHP dosyasından doğrudan A * kullanarak bu kadar kısa yol hesaplamaları yapabilir. 500 € 'luk Temel paket ihtiyaçlarınız için yeterli görünüyor.


Hızlı yanıtınız için teşekkür ederim, ancak projem hala şu anda para harcamayı gerektiriyorsa emin olmadığım bir aşamada. Ayrıca şu anda bilinmeyen ele alınmıştır böylece benim veriler üzerinde çalışan pgrouting var.
mrg
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.