Bantu memilih mesin perutean yang cocok


16

Saya sedang membangun sistem perencanaan rute, tetapi saya masih harus memutuskan mesin routing apa yang akan saya gunakan. Sejauh ini saya telah menemukan pgrouting dan neo4j.

Saya memiliki jaringan rute saya di database postgresql / postgis (diimpor dari shapefile). Saya telah membuat pertanyaan untuk mengekstrak node (titik akhir dari cara di mana Anda harus membuat keputusan ke arah mana harus pergi atau jalan buntu) dan untuk mengekstrak tepi (sering dibuat dengan beberapa cara berturut-turut). Semua tepi saya adalah dua arah.

Tujuan utama saya adalah untuk menghitung rute di jaringan ini menggunakan algoritma bintang-A di mana distance = biaya.

Perasaan saya memberi tahu saya bahwa basis data grafik seperti neo4j adalah cara untuk pergi (karena tampaknya dibuat hanya untuk tujuan ini), tetapi mereka tampaknya tidak mendukung bintang-A secara default dan juga tidak ada rasa geometri yang nyata . Tampaknya lebih cocok untuk jejaring sosial daripada peta.

  • Akankah pemogokan memenuhi kebutuhan saya?
  • Apakah cukup cepat untuk permintaan langsung (+ -2000 node, + -4000 edge)? Biasanya ini akan menjadi beberapa ms untuk bintang-A, tetapi saya tidak yakin tentang implementasi ini dalam sql.
  • Apakah pgrouting A-star memberi saya daftar node dan edge?
  • Dalam sebagian besar contoh saya melihat tentang pgrouting saya perhatikan biasanya ada daftar perintah setelah perhitungan rute (seperti "Di X belok kiri, dll"). Apakah pgrouting menghasilkan ini atau ini dari sistem lain?

Semoga seseorang dapat memberi saya beberapa informasi tentang sistem apa yang harus saya pilih. Neo4j, pgrouting, atau sistem lain.


3
Saya pikir sebagian besar algoritma routing tidak beroperasi dengan "sense of geometry", sebaliknya atribut geometrik dihitung dan digunakan sebagai biaya (yaitu ukuran jarak polyline). Saya tidak pernah menggunakan Neo4j, tapi kelihatannya sangat mampu dan saya akan segera menggunakannya. Saya baru saja melihat pada dokumentasi dan sepertinya mungkin untuk menggunakan A-Star: docs.neo4j.org/chunked/stable/graph-algo.html docs.neo4j.org/chunked/stable/… pgRouting juga mampu, dan Saya penggemar beratnya. Akan menarik untuk membandingkan kinerja kedua solusi ini.
Allan Adair

Pertama, saya akan menyarankan untuk melihat urbansim model penggunaan lahan opensource. Adapun pertanyaan perutean Anda, Jika ini adalah aplikasi perencanaan, maka saya akan menyarankan melihat perangkat lunak seperti TransCAD, CUBE, PLANAR, atau EMME / 2 terlebih dahulu untuk fungsi dan antarmuka pengguna. Mereka biasanya memberikan demo demo 1 jam atau 2 jam dari perangkat lunak mereka (perangkat lunak yang dapat Anda jalankan selama satu atau dua jam untuk merasakannya). Jika Anda ingin membuat sesuatu untuk penggunaan online atau penggunaan desktop, lihat pgRouting; Namun, dari pengalaman, terkadang, tidak semudah bagaimana workshop / tutorial menggambarkannya.
dassouki

Saya mulai bekerja dengan bintang-bintang yang bekerja dan itu luar biasa! Itu menjawab ya pada 3 pertanyaan pertama saya. Masih saya bertanya-tanya apakah seseorang di sini tahu apa-apa tentang menghasilkan arah navigasi verbose. Apakah ada beberapa perkakas yang bekerja sama dengan pgrouting yang menghasilkan arah verbose ("Setelah 200m belok kiri, dll") dari output rute yang dihitung?
mrg

Jawaban:


8

Saat ini saya sedang mengeksplorasi masalah yang sama seperti Anda, untuk tujuan makalah penelitian. Sebelum saya mulai menguji dua database ini, saya memiliki anggapan yang sama seperti Anda. Database grafik Neo4j itu akan menjadi solusi sempurna untuk masalah seperti ini. Dan sebagian memang demikian, tetapi dengan banyak masalah.

Masalah pertama adalah bahwa A-Star hanya diimplementasikan jika Anda menggunakan database tertanam, bukan melalui REST API (server). Jika Anda ingin menggunakan Neo4j dengan REST API, maka hanya algoritma Dijkstra yang didukung. Masalah kedua adalah persyaratan memori perangkat keras untuk Neo4j. Untuk perutean (Dijkstra) pada jaringan "lebih besar" Anda membutuhkan banyak RAM. Untuk jaringan besar saya maksudkan seperti ukuran basis data jalan OSM Jerman . Saya telah menjalankan tes pada server RAM 6GB (itu yang saya miliki saat ini) dan hanya jaringan yang lebih kecil yang dapat dialihkan tanpa kesalahan pengecualian OutOfMemory. Jaringan "kecil" dalam kasus pengujian saya misalnya, basis data jalan OSM untuk Austria atau Kroasia. Pertanyaan serentak saya masih belum diuji dengan Neo4j.

Semua masalah ini tidak ada di pgRouting. Memori bukan masalah seperti itu tetapi permintaan bersamaan meningkatkan jumlah memori yang dibutuhkan. Misalnya, jika Anda memiliki dua permintaan bersamaan, dibutuhkan jumlah memori ganda. Ini bukan masalah bahkan untuk dataset OSM Jerman, pgRouting dialihkan tanpa masalah semua permintaan bersamaan.

Kinerja: Dalam kebanyakan kasus, Neo4j mengungguli pgRouting. Tetapi hanya jika ada memori yang cukup untuk dataset yang diberikan dan jika semua node dan hubungan ada dalam memori (hot start). Peningkatan / penurunan kinerja tergantung pada banyak faktor tetapi sebagian besar pada ukuran jaringan dan jarak (hop) antara sumber dan target node.

Ukuran jaringan Anda cukup kecil, jadi Anda seharusnya tidak memiliki masalah dengan memori. Mungkin Neo4j bukan pilihan yang buruk tetapi Anda harus beradaptasi dengan model data yang "sedikit" berbeda dari pada database hubungan standar.

Untuk menjawab pertanyaan Anda:

  • Dalam pgRouting Anda tidak perlu khawatir tentang implementasi AStar di sql, yang sudah diterapkan.
  • Ya, pgRouting dapat memberi Anda daftar node dan edge
  • Saya tidak berpikir bahwa pgRouting dapat memberi Anda informasi seperti itu tanpa beberapa pekerjaan khusus seputar pertanyaan. Tapi mungkin saya salah, mungkin seseorang telah melakukan ini dan dapat membantu Anda lebih banyak tentang pertanyaan ini.

Saya tidak tahu apakah itu akan membantu Anda secara langsung, tetapi salah satu server perutean tercepat yang saya temukan adalah osm2po . Ia bekerja dengan dataset OSM dan cukup cepat. Hanya dijkstra yang saat ini diterapkan tetapi pengembang juga mengumumkan AStar. Saya harap beberapa dari ini akan membantu Anda. :)


Adalah baik untuk mendengar dari seseorang yang benar-benar menguji kedua sistem. Sementara itu saya punya lebih banyak pengalaman dengan pgrouting. Saya perhatikan bahwa pgrouting membuat seluruh grafik untuk setiap permintaan dan itu membuatnya agak lambat untuk jaringan besar (ukuran Jerman), jadi saya tidak melihat mengapa pgrouting akan membutuhkan lebih sedikit memori daripada Neo4j. Percobaan saya berikutnya adalah untuk mendapatkan seluruh grafik statis di ram dan rute itu (dengan neo4j, nx_spatial dll) untuk memastikan respon yang lebih cepat untuk perutean waktu nyata.
mrg

Ya, semakin besar grafiknya, semakin banyak perbedaan antara pgrouting dan neo4j. Mungkin jika Anda memasukkan seluruh grafik ke dalam memori daripada itu akan menjadi solusi tercepat, tidak ada pertanyaan tentang itu. Neo4j cukup cepat ketika semua grafik dimuat ke dalam memori. Tidak tahu tentang nx_spatial, saya belum mengujinya, tapi mungkin saya akan mengujinya. Saya percaya itu bisa mengungguli Neo4j. Tetapi solusi ini bagus jika dapat diterima untuk aplikasi Anda.
Mario Miler

1
@ mrg tidak yakin apakah ini masih menjadi masalah bagi Anda tetapi ada OSRM (C ++) dan GraphHopper (Java). Baik skala untuk grafik di seluruh dunia dan misalnya, kebutuhan GraphHopper di bawah 1GB untuk Jerman (di mana saya penulis)
Karussell

Karussell, terima kasih atas informasinya! Saya sudah menemukan OSRM, tetapi GraphHopper baru bagi saya.
mrg

0

Anda juga dapat melihat paket RW Net 4 kami (www.routeware.dk). Itu dapat melakukan perhitungan jalur terpendek seperti menggunakan A * langsung dari file SHP. Paket Basic seharga € 500 tampaknya cukup untuk kebutuhan Anda.


Terima kasih atas tanggapan Anda yang cepat, tetapi proyek saya masih dalam tahap yang saya tidak yakin jika ia mengeluarkan uang saat ini. Juga saya mendapat pgrouting bekerja pada data saya jadi untuk sekarang yang tidak diketahui telah ditangani.
mrg
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.