Giúp chọn một công cụ định tuyến phù hợp


16

Tôi đang xây dựng một hệ thống lập kế hoạch tuyến đường, nhưng tôi vẫn phải quyết định tôi sẽ sử dụng công cụ định tuyến cơ bản nào. Cho đến nay tôi đã tìm thấy pgrouting và neo4j.

Tôi có mạng lưới tuyến đường của mình trong cơ sở dữ liệu postgresql / postgis (được nhập từ một shapefile). Tôi đã thực hiện các truy vấn để trích xuất các nút (điểm cuối của các cách mà bạn phải đưa ra quyết định hướng đi nào hoặc ngõ cụt) và trích xuất các cạnh (thường được tạo bởi nhiều cách liên tiếp). Tất cả các cạnh của tôi là hai chiều.

Mục tiêu chính của tôi là tính toán các tuyến đường trên mạng này bằng thuật toán A-star trong đó distance = cost.

Cảm giác của tôi cho tôi biết rằng một cơ sở dữ liệu đồ thị như neo4j là hướng đi (vì dường như nó được tạo ra chỉ cho mục đích này), nhưng chúng dường như không hỗ trợ sao A theo mặc định và cũng không có cảm giác hình học thực sự . Nó có vẻ phù hợp hơn cho các mạng xã hội thay vì bản đồ.

  • Pgrouting sẽ đáp ứng nhu cầu của tôi?
  • Có đủ nhanh để truy vấn nhanh (+ -2000 nút, + -4000 cạnh) không? Thông thường, đây sẽ là một vài ms cho A-star, nhưng tôi không chắc về việc triển khai này trong sql.
  • Có phải ngôi sao A cho tôi một danh sách các nút và cạnh không?
  • Trong hầu hết các ví dụ tôi thấy về pgrouting tôi nhận thấy thường có một danh sách các lệnh sau khi tính toán tuyến đường (như "Tại X rẽ trái, v.v."). Liệu pgrouting sản xuất này hay là từ hệ thống khác?

Hy vọng ai đó có thể cho tôi một số thông tin về việc chọn hệ thống nào. Neo4j, pgrouting, hoặc một số hệ thống khác.


3
Tôi nghĩ rằng hầu hết các thuật toán định tuyến không hoạt động với "cảm giác hình học", thay vào đó một thuộc tính hình học được tính toán và sử dụng như một chi phí (tức là thước đo khoảng cách của một đa tuyến). Tôi chưa bao giờ sử dụng Neo4j, nhưng nó có vẻ thực sự có khả năng và tôi có thể sẽ sớm sử dụng nó. Tôi mới xem tài liệu và có vẻ như có thể sử dụng A-Star: docs.neo4j.org/chunked/urdy/graph-algo.html docs.neo4j.org/chunked/ sóng / pgRouting cũng có khả năng, và Tôi là một fan hâm mộ lớn của nó. Sẽ rất thú vị khi so sánh hiệu suất của hai giải pháp này.
Allan Adair

Đầu tiên, tôi sẽ đề nghị Xem xét urbansim một mô hình sử dụng đất mở. Đối với câu hỏi định tuyến của bạn, Nếu đây là kế hoạch ứng dụng, thì tôi khuyên bạn nên xem xét phần mềm như TransCAD, CUBE, PLANAR hoặc EMME / 2 trước tiên về chức năng và giao diện người dùng. Họ thường đưa ra các bản demo demo 1 giờ hoặc 2 giờ cho phần mềm của họ (phần mềm bạn có thể chạy trong một hoặc hai giờ để cảm nhận về phần mềm này). Nếu bạn muốn xây dựng một cái gì đó để sử dụng trực tuyến hoặc sử dụng máy tính để bàn, hãy xem pgRouting; tuy nhiên, từ kinh nghiệm, đôi khi, nó không dễ như cách hội thảo / hướng dẫn miêu tả nó.
dassouki

Tôi đã trải qua với một ngôi sao làm việc và nó thật tuyệt vời! Nó trả lời có trong 3 câu hỏi đầu tiên của tôi. Tôi vẫn tự hỏi nếu ai đó ở đây biết bất cứ điều gì về việc tạo hướng điều hướng dài dòng. Có một số công cụ hợp tác với việc tạo ra các hướng dài ("Sau 200m rẽ trái, v.v.") từ đầu ra của tuyến đường được tính toán?
mrg

Câu trả lời:


8

Tôi hiện đang khám phá cùng một vấn đề như bạn, cho mục đích nghiên cứu. Trước khi tôi bắt đầu thử nghiệm hai cơ sở dữ liệu này, tôi có cùng một giả định như bạn. Cơ sở dữ liệu đồ thị Neo4j sẽ là giải pháp hoàn hảo cho loại vấn đề này. Và một phần là vậy, nhưng với rất nhiều vấn đề.

Vấn đề đầu tiên là A-Star chỉ được triển khai nếu bạn đang sử dụng cơ sở dữ liệu nhúng, không thông qua API REST (máy chủ). Nếu bạn muốn sử dụng Neo4j với API REST, thì chỉ hỗ trợ thuật toán Dijkstra. Vấn đề thứ hai là yêu cầu bộ nhớ phần cứng cho Neo4j. Để định tuyến (Dijkstra) trên các mạng "lớn hơn", bạn cần rất nhiều RAM. Đối với mạng lớn, ý tôi là kích thước của cơ sở dữ liệu đường bộ OSM của Đức . Tôi đã chạy thử nghiệm trên máy chủ RAM 6GB (đó là tất cả những gì tôi có hiện tại) và chỉ các mạng nhỏ hơn có thể được định tuyến mà không có lỗi ngoại lệ OutOfMemory. Các mạng "nhỏ" trong các trường hợp thử nghiệm của tôi là ví dụ: cơ sở dữ liệu đường OSM cho Áo hoặc Croatia. Các truy vấn đồng thời tôi vẫn chưa thử nghiệm với Neo4j.

Tất cả những vấn đề này không tồn tại trong pgRouting. Bộ nhớ không phải là một vấn đề như vậy nhưng các truy vấn đồng thời làm tăng lượng bộ nhớ cần thiết. Ví dụ: nếu bạn có hai yêu cầu đồng thời, cần gấp đôi bộ nhớ. Đây không phải là vấn đề ngay cả đối với bộ dữ liệu OSM của Đức, pgRouting được định tuyến mà không có bất kỳ vấn đề nào trong tất cả các yêu cầu đồng thời.

Hiệu suất: Trong hầu hết các trường hợp, Neo4j vượt trội so với pgRouting. Nhưng chỉ khi có đủ bộ nhớ cho tập dữ liệu đã cho và nếu tất cả các nút và mối quan hệ nằm trong bộ nhớ (bắt đầu nóng). Tăng / giảm hiệu suất phụ thuộc vào rất nhiều yếu tố nhưng chủ yếu là kích thước của mạng và khoảng cách (bước nhảy) giữa nút nguồn và nút đích.

Kích thước mạng của bạn khá nhỏ, vì vậy bạn không nên có bất kỳ vấn đề nào với bộ nhớ. Có lẽ Neo4j không phải là một lựa chọn tồi nhưng bạn phải thích nghi với mô hình dữ liệu "nhỏ" khác với cơ sở dữ liệu quan hệ tiêu chuẩn.

Để trả lời bạn câu hỏi:

  • Trong pgRouting, bạn không phải lo lắng về việc triển khai AStar trong sql, tất cả đã được thực hiện.
  • Có, pgRouting có thể cung cấp cho bạn danh sách các nút và cạnh
  • Tôi không nghĩ rằng pgRouting có thể cung cấp cho bạn thông tin như vậy với một số công việc tùy chỉnh xung quanh các truy vấn. Nhưng có lẽ tôi đã sai, có lẽ ai đó đã làm điều này và có thể giúp bạn nhiều hơn về câu hỏi này.

Tôi không biết nếu nó sẽ giúp bạn trực tiếp, nhưng một trong những máy chủ định tuyến nhanh nhất tôi tìm thấy là osm2po . Nó hoạt động với bộ dữ liệu OSM và khá nhanh. Chỉ dijkstra hiện đang được triển khai nhưng nhà phát triển cũng công bố AStar. Tôi hy vọng rằng một số điều này sẽ giúp bạn. :)


Thật tốt khi nghe từ một người đã thực sự thử nghiệm cả hai hệ thống. Trong khi đó tôi có nhiều kinh nghiệm hơn với việc trải thảm. Tôi nhận thấy rằng pgrouting xây dựng toàn bộ biểu đồ cho mỗi truy vấn và điều đó làm cho nó khá chậm đối với các mạng lớn (kích thước của Đức), vì vậy tôi không hiểu tại sao pgrouting lại cần ít bộ nhớ hơn Neo4j. Thử nghiệm tiếp theo của tôi sẽ là lấy toàn bộ đồ thị tĩnh trong ram và định tuyến trên đó (với neo4j, nx_spatial, v.v.) để đảm bảo đáp ứng nhanh hơn cho định tuyến thời gian thực.
mrg

Có, đồ thị càng lớn, sự khác biệt giữa pgrouting và neo4j càng nhiều. Có lẽ nếu bạn đặt toàn bộ biểu đồ vào bộ nhớ thì đó sẽ là giải pháp nhanh nhất, không có câu hỏi nào về điều đó. Neo4j khá nhanh khi tất cả đồ thị được tải vào bộ nhớ. Tôi không biết về nx_spatial, tôi chưa thử nó, nhưng có lẽ tôi sẽ làm được. Tôi tin rằng nó có thể vượt trội hơn cả Neo4j. Nhưng giải pháp này là tốt nếu nó được chấp nhận cho ứng dụng của bạn.
Mario Miler

1
@mrg không chắc nó có còn là vấn đề với bạn không nhưng có OSRM (C ++) và GraphHopper (Java). Cả hai tỷ lệ theo đồ thị trên toàn thế giới và ví dụ như GraphHopper cần dưới 1gb cho Đức (nơi tôi là tác giả)
Karussell

Karussell, cảm ơn bạn đã thông tin! Tôi đã tìm thấy OSRM, nhưng GraphHopper là mới đối với tôi.
mrg

0

Bạn cũng có thể xem gói RW Net 4 của chúng tôi (www.routcare.dk). Nó có thể thực hiện các phép tính đường dẫn ngắn nhất như vậy bằng cách sử dụng A * trực tiếp từ tệp SHP. Gói Basic ở mức € 500 dường như đủ cho nhu cầu của bạn.


Cảm ơn bạn đã phản hồi nhanh chóng, nhưng dự án của tôi vẫn đang trong giai đoạn mà tôi không chắc chắn nếu nó đảm bảo tiêu tiền ngay bây giờ. Ngoài ra, tôi đã làm việc với dữ liệu của mình để bây giờ không biết đã được xử lý.
mrg
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.