Quali algoritmi calcolano le direzioni dal punto A al punto B su una mappa?

In che modo i fornitori di mappe (come Google o Yahoo! Maps) suggeriscono le indicazioni?

Voglio dire, probabilmente hanno dati del mondo reale in qualche forma, compresi certamente le distanze ma forse anche cose come velocità di marcia, presenza di marciapiedi, orari dei treni, ecc. Ma supponiamo che i dati fossero in un formato più semplice, ad esempio un grafico diretto molto grande con pesi per bordi che riflettono le distanze. Voglio essere in grado di calcolare rapidamente le direzioni da un punto arbitrario all'altro. A volte questi punti saranno vicini (all'interno di una città), mentre a volte saranno distanti (fondo).

Gli algoritmi grafici come l'algoritmo Dijkstra non funzioneranno perché il grafico è enorme. Fortunatamente, gli algoritmi euristici come A * probabilmente funzioneranno. Tuttavia, i nostri dati sono molto strutturati e forse potrebbe funzionare qualche tipo di approccio a più livelli? (Ad esempio, memorizza le direzioni pre-calcolate tra determinati punti "chiave" distanti tra loro, così come alcune direzioni locali. Quindi le indicazioni per due punti distanti coinvolgeranno le direzioni locali verso i punti chiave, le direzioni globali verso un altro punto chiave, e quindi locale indicazioni di nuovo.)

Quali algoritmi vengono effettivamente utilizzati nella pratica?

PS. Questa domanda è stata motivata dalla ricerca di stranezze nelle direzioni di mappatura online. Contrariamente alla disuguaglianza del triangolo, a volte Google Maps pensa che XZ impiega più tempo ed è più lontano dell'uso di un punto intermedio come in XYZ . Ma forse le loro indicazioni per camminare possono anche ottimizzare per un altro parametro?

PPS. Ecco un'altra violazione della disuguaglianza del triangolo che suggerisce (per me) che usano una sorta di approccio a più livelli: XZ contro XYZ . Il primo sembra usare il famoso Boulevard de Sebastopol anche se è leggermente fuori mano.

Modifica : nessuno di questi esempi sembra funzionare più, ma entrambi hanno funzionato al momento del post originale.

Parlando come qualcuno che ha trascorso 18 mesi a lavorare in una società di mappatura, che includeva lavorare sull'algoritmo di routing ... sì, Dijkstra funziona, con un paio di modifiche:

• Invece di fare Dijkstra una volta dalla fonte alla dest, inizi da ogni estremità ed espandi entrambi i lati fino a quando si incontrano nel mezzo. Questo elimina circa metà del lavoro (2 * pi * (r / 2) ^ 2 vs pi * r ^ 2).
• Per evitare di esplorare i vicoli di ogni città tra l'origine e la destinazione, puoi avere diversi livelli di dati cartografici: un livello "autostrade" che contiene solo autostrade, un livello "secondario" che contiene solo strade secondarie e così via. Quindi, esplori solo sezioni più piccole dei livelli più dettagliati, espandendoti se necessario. Ovviamente questa descrizione lascia molti dettagli, ma hai capito.

Con le modifiche in tal senso, è possibile eseguire il routing anche tra paesi in tempi molto ragionevoli.

Questa domanda è stata un'area attiva di ricerca negli ultimi anni. L'idea principale è di eseguire una preelaborazione sul grafico una volta , per velocizzare tutte le query successive . Con queste informazioni aggiuntive gli itinerari possono essere calcolati molto velocemente. Tuttavia, l'algoritmo di Dijkstra è la base per tutte le ottimizzazioni.

Arachnid ha descritto l'uso della ricerca bidirezionale e della potatura dei bordi in base a informazioni gerarchiche. Queste tecniche di accelerazione funzionano abbastanza bene, ma gli algoritmi più recenti superano di gran lunga queste tecniche. Con gli algoritmi attuali è possibile calcolare percorsi più brevi in ​​meno tempo di un millisecondo su una rete stradale continentale. Una rapida implementazione dell'algoritmo non modificato di Dijkstra richiede circa 10 secondi .

L'articolo Engineering Fast Route Planning Algorithms offre una panoramica dei progressi della ricerca in questo campo. Vedi i riferimenti di quel documento per ulteriori informazioni.

Gli algoritmi più veloci conosciuti non utilizzano informazioni sullo stato gerarchico della strada nei dati, cioè se si tratta di un'autostrada o di una strada locale. Invece, calcolano in una fase di preelaborazione una propria gerarchia ottimizzata per accelerare la pianificazione del percorso. Questo pre-calcolo può quindi essere usato per potare la ricerca: lontano dall'inizio e dalla destinazione non è necessario prendere in considerazione le strade lente durante l'algoritmo di Dijkstra. I benefici sono molto buone prestazioni e la correttezza garanzia per il risultato.

I primi algoritmi di pianificazione del percorso ottimizzati si occupavano solo di reti stradali statiche, ciò significa che un bordo nel grafico ha un valore di costo fisso. Questo non è vero in pratica, poiché vogliamo prendere in considerazione informazioni dinamiche come ingorghi o restrizioni dipendenti dal veicolo. Anche gli algoritmi più recenti possono affrontare tali problemi, ma ci sono ancora problemi da risolvere e la ricerca sta proseguendo.

Se hai bisogno delle distanze più brevi per calcolare una soluzione per il TSP , allora probabilmente sei interessato a matrici che contengono tutte le distanze tra le tue fonti e destinazioni. Per questo potresti prendere in considerazione il calcolo di numerosi percorsi più brevi usando le gerarchie autostradali . Si noti che questo è stato migliorato da approcci più recenti negli ultimi 2 anni.

Basta affrontare le violazioni della disuguaglianza del triangolo, si spera che il fattore aggiuntivo per cui stanno ottimizzando sia il buonsenso. Non vuoi necessariamente il percorso più breve o più veloce, in quanto può portare al caos e alla distruzione . Se vuoi che le tue indicazioni preferiscano le rotte principali che sono adatte ai camion e in grado di far fronte a tutti gli autisti che seguono il navigatore satellitare le inviano, scarti rapidamente la disuguaglianza del triangolo [1].

Se Y è una stretta strada residenziale tra X e Z, probabilmente si desidera utilizzare la scorciatoia tramite Y se l'utente chiede esplicitamente XYZ. Se chiedono XZ, dovrebbero attenersi alle strade principali anche se è un po 'più avanti e richiede un po' più di tempo. È simile al paradosso di Braess : se tutti cercano di percorrere il percorso più breve e più veloce, la congestione che ne risulta significa che non è più il percorso più veloce per nessuno. Da qui ci allontaniamo dalla teoria dei grafi nella teoria dei giochi.

[1] In effetti, ogni speranza che le distanze prodotte siano una funzione di distanza in senso matematico muore quando si consentono strade a senso unico e si perde il requisito di simmetria. Perdere anche la disuguaglianza del triangolo è solo sfregare il sale nella ferita.

Ecco gli algoritmi di routing più veloci al mondo confrontati e dimostrati per la correttezza:

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

Ecco un discorso tecnico su Google sull'argomento:

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

Ecco un'implementazione dell'algoritmo delle gerarchie autostradali come discusso da Schultes (attualmente solo a Berlino, sto scrivendo l'interfaccia e anche una versione mobile è in fase di sviluppo):

http://tom.mapsforge.org/

Non ho mai lavorato su Google, Microsoft o Yahoo Maps prima, quindi non posso dirti come funzionano.

Tuttavia, ho progettato un sistema di ottimizzazione della catena di fornitura personalizzato per un'azienda energetica che includeva un'applicazione di pianificazione e instradamento per la loro flotta di camion. Tuttavia, i nostri criteri di instradamento erano molto più specifici del business rispetto a dove sono i rallentamenti della costruzione o del traffico o la chiusura delle corsie.

Abbiamo impiegato una tecnica chiamata ACO (ottimizzazione delle colonie di formiche) per programmare e indirizzare i camion. Questa tecnica è una tecnica di intelligenza artificiale che è stata applicata al problema del commesso viaggiatore per risolvere i problemi di routing. Il trucco con ACO è quello di costruire un calcolo dell'errore basato su fatti noti del routing in modo che il modello di risoluzione dei grafici sappia quando uscire (quando l'errore è abbastanza piccolo).

Puoi google ACO o TSP per trovare ulteriori informazioni su questa tecnica. Non ho usato nessuno degli strumenti di intelligenza artificiale open source per questo, quindi non posso suggerirne uno (anche se ho sentito che SWARM era piuttosto completo).

Gli algoritmi grafici come l'algoritmo Dijkstra non funzioneranno perché il grafico è enorme.

Questo argomento non vale necessariamente perché Dijkstra di solito non guarderà il grafico completo ma piuttosto solo un sottoinsieme molto piccolo (più il grafico è interconnesso, più piccolo è questo sottoinsieme).

Dijkstra potrebbe effettivamente funzionare piuttosto bene per grafici ben educati. D'altra parte, con un'attenta parametrizzazione A * funzionerà sempre altrettanto bene, o meglio. Hai già provato come si comporterebbe sui tuoi dati?

Detto questo, sarei anche molto interessato a conoscere le esperienze di altre persone. Naturalmente, esempi importanti come la ricerca di Google Map sono particolarmente interessanti. Potrei immaginare qualcosa di simile a un euristico vicino più vicino diretto.

L'attuale stato dell'arte in termini di tempi di interrogazione per le reti stradali statiche è l'algoritmo di etichettatura Hub proposto da Abraham et al. http://link.springer.com/chapter/10.1007/978-3-642-20662-7_20 . Un sondaggio completo e ottimamente scritto sul campo è stato recentemente pubblicato come un rapporto tecnico Microsoft http://research.microsoft.com/pubs/207102/MSR-TR-2014-4.pdf .

La versione breve è ...

L'algoritmo di etichettatura Hub fornisce le query più veloci per le reti stradali statiche ma richiede l'esecuzione di una grande quantità di RAM (18 GiB).

Il routing del nodo di transito è leggermente più lento, sebbene richieda solo circa 2 GiB di memoria e abbia un tempo di preelaborazione più rapido.

Le gerarchie di contrazioni offrono un buon compromesso tra tempi di preelaborazione rapidi, requisiti di spazio ridotto (0,4 GiB) e tempi di query rapidi.

Nessun algoritmo è completamente dominante ...

Questo discorso tecnico su Google di Peter Sanders potrebbe essere interessante

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

Anche questo discorso di Andrew Goldberg

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

Un'implementazione open source delle gerarchie di contrazioni è disponibile dal sito Web del gruppo di ricerca di Peter Sanders presso KIT. http://algo2.iti.kit.edu/english/routeplanning.php

Anche un post sul blog facilmente accessibile scritto da Microsoft sull'uso dell'algoritmo CRP ... http://blogs.bing.com/maps/2012/01/05/bing-maps-new-routing-engine/

Sono un po 'sorpreso di non vedere l' algoritmo di Floyd Warshall menzionato qui. Questo algoritmo funziona in modo molto simile a quello di Dijkstra. Ha anche una caratteristica molto bella che ti permette di calcolare fino a quando vuoi continuare permettendo più vertici intermedi. Quindi troverà naturalmente i percorsi che utilizzano le autostrade o le autostrade abbastanza rapidamente.

L'ho fatto molte volte, in realtà, provando diversi metodi. A seconda delle dimensioni (geografiche) della mappa, potresti prendere in considerazione l'utilizzo della funzione haversine come euristica.

La migliore soluzione che ho fatto è stata usare A * con una distanza in linea retta come funzione euristica. Ma poi hai bisogno di una sorta di coordinate per ogni punto (intersezione o vertice) sulla mappa. Puoi anche provare diversi pesi per la funzione euristica, ad es

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

dove k è una costante maggiore di 0.

Probabilmente simile alla risposta su percorsi precalcolati tra le principali località e mappe stratificate, ma la mia comprensione è che nei giochi, per accelerare A *, hai una mappa che è molto grossolana per la navigazione macro e una mappa a grana fine per navigazione al limite delle macro direzioni. Quindi hai 2 piccoli percorsi da calcolare, e quindi il tuo spazio di ricerca è molto più piccolo del semplice fare un singolo percorso verso la destinazione. E se hai intenzione di farlo molto, avresti molti di questi dati pre-calcolati, quindi almeno una parte della ricerca è una ricerca di dati pre-calcolati, piuttosto che una ricerca di un percorso.

Questa è pura speculazione da parte mia, ma suppongo che possano usare una struttura di dati della mappa di influenza sovrapposta alla mappa diretta per restringere il dominio di ricerca. Ciò consentirebbe all'algoritmo di ricerca di indirizzare il percorso verso le rotte principali quando il viaggio desiderato è lungo.

Dato che si tratta di un'app di Google, è anche ragionevole supporre che gran parte della magia venga eseguita tramite una cache estesa. :) Non sarei sorpreso se la memorizzazione nella cache del 5% delle richieste di percorso più comuni su Google Map consentisse di rispondere a una grande parte (20%? 50%?) Di richieste con una semplice ricerca.

Ho avuto qualche altro pensiero su questo:

1) Ricorda che le mappe rappresentano un'organizzazione fisica. Memorizza la latitudine / longitudine di ogni incrocio. Non è necessario controllare molto oltre i punti che si trovano nella direzione del bersaglio. Solo se ti trovi bloccato devi andare oltre. Se memorizzi un overlay di connessioni superiori, puoi limitarlo ancora di più: normalmente non attraverserai mai uno di questi in un modo che si allontana dalla tua destinazione finale.

2) Dividi il mondo in un intero gruppo di zone definite da connettività limitata, definisci tutti i punti di connettività tra le zone. Trova le zone in cui si trovano la tua sorgente e destinazione, per il percorso della zona iniziale e finale dalla posizione a ciascun punto di connessione, per le zone tra la semplice mappa tra i punti di connessione. (Sospetto che molti di questi ultimi siano già pre-calcolati.)

Si noti che le zone possono essere più piccole di un'area metropolitana. Qualsiasi città con caratteristiche del terreno che lo dividono (per esempio un fiume) sarebbe più zone.

Ero molto curioso dell'euristica usata, quando un po 'di tempo fa abbiamo ottenuto percorsi dalla stessa posizione di partenza vicino a Santa Rosa, verso due diversi campeggi nel Parco nazionale Yosemite. Queste diverse destinazioni produssero rotte piuttosto diverse (via I-580 o CA-12) nonostante entrambe le rotte convergessero per le ultime 100 miglia (lungo la CA-120) prima di divergere di nuovo di alcune miglia alla fine. Questo era abbastanza ripetibile. I due percorsi erano distanti fino a 50 miglia per circa 100 miglia, ma le distanze / i tempi erano abbastanza vicini l'uno all'altro come ci si aspetterebbe.

Purtroppo non posso riprodurlo, gli algoritmi devono essere cambiati. Ma mi ha incuriosito l'algoritmo. Tutto quello che posso supporre è che ci sia stata una potatura direzionale che si è rivelata squisitamente sensibile alla minuscola differenza angolare tra le destinazioni vista da lontano, o che c'erano diversi segmenti pre-calcolati selezionati dalla scelta della destinazione finale.

Parlando di GraphHopper , un veloce pianificatore di percorsi Open Source basato su OpenStreetMap, ho letto un po 'di letteratura e implementato alcuni metodi. La soluzione più semplice è un Dijkstra e un semplice miglioramento è un Dijkstra bidirezionale che esplora all'incirca solo la metà dei nodi. Con Dijkstra bidirezionale un percorso attraverso tutta la Germania impiega già 1 secondo (per la modalità auto), in C sarebbe probabilmente solo 0,5 secondi circa;)

Ho creato una gif animata di una vera ricerca di percorsi con Dijkstra bidirezionale qui . Inoltre ci sono alcune idee in più per rendere Dijkstra più veloce come fare A *, che è un "Dijkstra orientato agli obiettivi". Inoltre ho creato un'animazione gif per questo.

Ma come farlo (molto) più velocemente?

Il problema è che per un percorso di ricerca tutti i nodi tra le posizioni devono essere esplorati e questo è davvero costoso come già in Germania ce ne sono diversi milioni. Ma un ulteriore punto debole di Dijkstra ecc è che tali ricerche utilizzano molta RAM.

Esistono soluzioni euristiche ma anche soluzioni esatte che organizzano il grafico (rete stradale) in strati gerarchici, entrambi hanno pro e contro e risolvono principalmente il problema di velocità e RAM. Ne ho elencati alcuni in questa risposta .

Per GraphHopper ho deciso di utilizzare le Gerarchie di contrazioni perché è relativamente "facile" da implementare e non richiede anni per la preparazione del grafico. Risulta comunque in tempi di risposta molto rapidi come puoi testare nella nostra istanza online GraphHopper Maps . Ad esempio, dal Sud Africa alla Cina orientale, il che si traduce in una distanza di 23000 km e in quasi 14 giorni di guida in auto, impiegando solo circa 0,1 secondi sul server.

Ho lavorato all'instradamento per alcuni anni, con una recente raffica di attività provocata dalle esigenze dei miei clienti e ho scoperto che A * è abbastanza veloce; non c'è davvero bisogno di cercare ottimizzazioni o algoritmi più complessi. Il routing su un enorme grafico non è un problema.

Ma la velocità dipende dall'avere l'intera rete di routing, per cui intendo il grafico diretto di archi e nodi che rappresentano rispettivamente segmenti di percorso e giunzioni, in memoria. Il sovraccarico di tempo principale è il tempo impiegato per creare questa rete. Alcuni dati approssimativi basati su un normale laptop con Windows e instradamento su tutta la Spagna: tempo impiegato per creare la rete: 10-15 secondi; tempo impiegato per calcolare un percorso: troppo breve per misurare.

L'altra cosa importante è poter riutilizzare la rete per tutti i calcoli di routing che desideri. Se il tuo algoritmo ha contrassegnato i nodi in qualche modo per registrare il percorso migliore (costo totale per il nodo corrente e arco migliore per esso) - come deve in A * - devi ripristinare o cancellare queste vecchie informazioni. Piuttosto che passare attraverso centinaia di migliaia di nodi, è più facile usare un sistema numerico di generazione. Contrassegnare ciascun nodo con il numero di generazione dei suoi dati; incrementare il numero di generazione quando si calcola un nuovo percorso; qualsiasi nodo con un numero di generazione precedente è obsoleto e le sue informazioni possono essere ignorate.

Vedo che succede con le mappe nel PO:

Guarda il percorso con il punto intermedio specificato: il percorso va leggermente indietro a causa di quella strada che non è diritta.

Se il loro algoritmo non tornerà indietro non vedrà il percorso più breve.

Un algoritmo del percorso più breve di tutte le coppie calcolerà i percorsi più brevi tra tutti i vertici in un grafico. Ciò consentirà di pre-calcolare i percorsi anziché richiedere il calcolo di un percorso ogni volta che qualcuno vuole trovare il percorso più breve tra una sorgente e una destinazione. L'algoritmo di Floyd-Warshall è un algoritmo di percorso più breve di tutte le coppie.

Le mappe non prendono mai in considerazione l'intera mappa. La mia ipotesi è: - 1. Secondo la tua posizione, caricano un posto e i punti di riferimento su quel posto. 2. Quando cerchi la destinazione, è quando caricano l'altra parte della mappa e creano un grafico in due punti, quindi applicano gli algoritmi del percorso più breve.

Inoltre, esiste un'importante tecnica di programmazione dinamica che sospetto sia utilizzata nel calcolo dei percorsi più brevi. Puoi fare riferimento anche a quello.