Aiuta a scegliere un motore di routing adatto

Sto costruendo un sistema di pianificazione del percorso, ma devo ancora decidere quale motore di routing sottostante userò. Finora ho trovato pgrouting e neo4j.

Ho la mia rete di rotte in un database postgresql / postgis (importato da un file di forma). Ho fatto delle domande per estrarre i nodi (punti finali dei modi in cui devi decidere quale direzione prendere o vicoli ciechi) e per estrarre i bordi (spesso costituiti da più modi consecutivi). Tutti i miei bordi sono bidirezionali.

Il mio obiettivo principale è calcolare i percorsi su questa rete usando un algoritmo A-star dove distance = cost.

La mia sensazione mi dice che un database grafico come Neo4j è la strada da percorrere (in quanto sembra essere fatto proprio per questo scopo), ma non sembrano supportare A-star di default e inoltre non c'è un vero senso della geometria . Sembra più adatto ai social network anziché alle mappe.

Il pgrouting soddisferebbe i miei bisogni?
È abbastanza veloce per le query al volo (+ -2000 nodi, + -4000 bordi)? Normalmente questo sarebbe un paio di ms per A-star, ma non sono sicuro di questa implementazione in sql.
P-staring A-star mi dà un elenco di nodi e bordi?
Nella maggior parte degli esempi che vedo sul pgrouting noto che di solito c'è un elenco di comandi dopo il calcolo del percorso (come "Alla X svolta a sinistra, ecc"). La pgrouting produce questo o proviene da un altro sistema?

Spero che qualcuno possa darmi alcune informazioni su quale sistema scegliere. Neo4j, pgrouting o qualche altro sistema.

pgrouting routing

— MRG
fonte

Penso che la maggior parte degli algoritmi di routing non funzionino con un "senso della geometria", invece un attributo geometrico viene calcolato e utilizzato come costo (ovvero misura della distanza di una polilinea). Non ho mai usato Neo4j, ma sembra davvero capace e potrei usarlo presto. Ho appena dato un'occhiata alla documentazione e sembra possibile usare A-Star: docs.neo4j.org/chunked/stable/graph-algo.html docs.neo4j.org/chunked/stable/… pgRouting è anche capace, e Ne sono un grande fan. Sarebbe interessante confrontare le prestazioni di queste due soluzioni.

— Allan Adair,

In primo luogo, suggerirei di guardare a urbansim un modello di utilizzo del territorio open source. Per quanto riguarda la tua domanda di routing, se questa è un'applicazione di pianificazione, suggerirei prima di guardare software come TransCAD, CUBE, PLANAR o EMME / 2 per funzionalità e interfaccia utente. Generalmente distribuiscono CD demo di 1 ora o 2 ore del loro software (software che è possibile eseguire per un'ora o due per avere un'idea). Se vuoi creare qualcosa per uso online o desktop, dai un'occhiata a pgRouting; tuttavia, per esperienza, a volte, non è facile come il workshop / tutorial lo ritrae.

— Dassouki,

Ho avuto problemi con una stella che funziona ed è fantastico! Risponde sì alle mie prime 3 domande. Mi chiedo comunque se qualcuno qui sa qualcosa sulla generazione di indicazioni di navigazione dettagliate. Esistono alcuni strumenti che cooperano con la protuberanza che generano direzioni dettagliate ("Dopo 200 m girare a sinistra, ecc.") Dall'output del percorso calcolato?

— sig.

Risposte:

Attualmente sto esplorando il tuo stesso problema, ai fini del documento di ricerca. Prima di iniziare a testare questi due database, avevo la tua stessa presunzione. Quel database grafico Neo4j sarebbe la soluzione perfetta per questo tipo di problema. E in parte lo è, ma con molti problemi.

Il primo problema è che A-Star è implementato solo se si utilizza un database incorporato, non tramite l'API REST (server). Se si desidera utilizzare Neo4j con l'API REST, è supportato solo l'algoritmo Dijkstra. Il secondo problema sono i requisiti di memoria hardware per Neo4j. Per il routing (Dijkstra) su reti "più grandi" è necessaria molta RAM. Per rete di grandi dimensioni intendo qualcosa di simile alle dimensioni del database stradale OSM della Germania . Ho eseguito i miei test su un server RAM da 6 GB (è tutto quello che ho attualmente) e solo le reti più piccole potevano essere instradate senza errori di eccezione OutOfMemory. Le reti "piccole" nei miei casi di test sono ad esempio il database stradale OSM per Austria o Croazia. Domande simultanee che non ho ancora testato con Neo4j.

Tutti questi problemi non esistono in pgRouting. La memoria non è un problema del genere, ma le query simultanee aumentano la quantità necessaria di memoria. Ad esempio, se si hanno due richieste simultanee, è necessaria una doppia quantità di memoria. Questo non è stato un problema nemmeno per un set di dati OSM Germania, pgRouting ha instradato senza problemi tutte le richieste simultanee.

Prestazioni: nella maggior parte dei casi, Neo4j supera le prestazioni di pgRouting. Ma solo se c'è abbastanza memoria per il set di dati dato e se tutti i nodi e le relazioni sono in memoria (hot start). L'aumento / diminuzione delle prestazioni dipende da molti fattori, ma principalmente dalle dimensioni della rete e dalla distanza (hop) tra il nodo di origine e di destinazione.

Le dimensioni della tua rete sono piuttosto ridotte, quindi non dovresti avere problemi con la memoria. Probabilmente Neo4j non è una cattiva scelta, ma è necessario adattarsi a un "piccolo" modello di dati diverso rispetto ai database di relazioni standard.

Per rispondere alle tue domande:

In pgRouting non devi preoccuparti dell'implementazione di AStar in sql, che è già stata implementata.
Sì, pgRouting può fornirti un elenco di nodi e bordi
Non credo che pgRouting possa darti tali informazioni senza alcun lavoro personalizzato sulle query. Ma forse mi sbaglio, forse qualcuno ha fatto questo e può aiutarti di più su questa domanda.

Non so se ti aiuterà direttamente, ma uno dei server di routing più veloci che ho trovato è osm2po . Funziona con il set di dati OSM ed è abbastanza veloce. Al momento è implementato solo dijkstra ma lo sviluppatore ha annunciato anche AStar. Spero che un po 'di questo ti possa aiutare. :)

— Mario Miler
fonte

È bello sentire qualcuno che ha effettivamente testato entrambi i sistemi. Nel frattempo ho molta più esperienza con il pgrouting. Ho notato che pgrouting crea l'intero grafico per ogni query e che lo rende piuttosto lento per reti di grandi dimensioni (dimensioni della Germania), quindi non vedo perché pgrouting richiederebbe meno memoria di Neo4j. Il mio prossimo tentativo sarà quello di ottenere l'intero grafico statico in ram e instradarlo (con neo4j, nx_spatial ecc.) Per garantire una risposta più veloce per il routing in tempo reale.

— sig.

Sì, più grande è il grafico, maggiore è la differenza tra pgrouting e neo4j. Probabilmente se metti in memoria l'intero grafico di quello che sarebbe la soluzione più veloce, non c'è dubbio. Neo4j è abbastanza veloce quando tutto il grafico è caricato in memoria. Non so di nx_spatial, non l'ho provato, ma forse lo farò. Credo che potrebbe superare anche Neo4j. Ma questa soluzione è buona se è accettabile per la tua applicazione.

— Mario Miler,

@mrg non è sicuro che sia ancora un problema per te ma ci sono OSRM (C ++) e GraphHopper (Java). Entrambi scalano in base a grafici di tutto il mondo e, ad esempio, GraphHopper ha bisogno di meno di 1 GB per la Germania (di cui sono l'autore)

— Karussell

Karussell, grazie per le informazioni! Avevo già trovato OSRM, ma GraphHopper è nuovo per me.

— sig.

Puoi anche dare un'occhiata al nostro pacchetto RW Net 4 (preparatoware.dk). Può eseguire calcoli di percorsi così brevi usando A * direttamente da un file SHP. Il pacchetto Basic a € 500 sembra sufficiente per le tue esigenze.

— Uffe Kousgaard
fonte

Grazie per la tua rapida risposta, ma il mio progetto è ancora in una fase di cui non sono sicuro se meriti di spendere soldi in questo momento. Inoltre ho iniziato a lavorare sui miei dati, quindi per ora è stato affrontato l'ignoto.

— sig.