Чи є новіші алгоритми маршрутизації (ніж Dijkstra, A *) в базах даних ГІС?


46

Є такі праці, як « Досягнення до A *» від дослідників Microsoft та « Ієрархії шосе» від Сандерса та Штольца (якщо я правильно написав ім’я) від Unig Karlsruhe . Вони обидва скорочують порядок обчислень і прискорюють тисячі разів на великих графіках (результати див. У пов'язаних документах). Остання робота призвела до маршрутизації з відкритим кодом , який, на жаль, недостатньо популярний і не адаптований (я не зміг його скласти, хоча дуже старався).

У той же час, dbs, які я спробував, Spatialite та PgRouting, згідно з їх документами, пропонують саме алгоритми Dijkstra та A * . Я навіть не бачив згаданого двонаправленого пошуку, що економить час на обчислення вдвічі.

Чи є кращі алгоритми для баз даних чи інших програм?


1
Ви розмістили своє запитання до списків електронної пошти користувачів або розробників pgRouting? Ви можете отримати кращу відповідь безпосередньо від цієї спільноти. Список користувачів: ( list.osgeo.org/mailman/listinfo/pgrouting-users ) Список розробників: ( list.osgeo.org/mailman/listinfo/pgrouting-dev )
RyanDalton

+1 Відмінне запитання. Цікаво, який алгоритм google використовує для отримання директив . Пов'язані питання тут .
Кірк Куйкендалл

1
Оскільки Google підтримує команду Karlsruhe ( algo2.iti.uni-karlsruhe.de/english/index.php ), я вважаю, що вони використовують своє програмне забезпечення, яке по суті є маршрутизатором з відкритим кодом.
culebrón

Відповіді:


23

Правда полягає в тому, що більшість людей використовують власну варіацію алгоритму A * . Ви побачите це у більшості "великих хлопців" (я не можу сказати, хто вони є на публічному форумі, але можу сказати вам, що ви, мабуть, використовуєте один із них - гарантовано), де модифікація евристики є дуже залежать від наборів даних, якими вони користуються.

Ви вже згадали про прутінг , який я вважав би "традиційним" варіантом. Це добре для прості алгоритми маршрутизації та для більшості проблем. Він також простий у використанні та використовує традиційну базу даних у своєму резервному часі.

Тим не менш, це дійсно залежить від масштабу та типу проблеми, яку ви намагаєтеся вирішити, а маршрутизація - це проблема графіка .

Знову ж таки, "великі хлопці" зазвичай мають багато даних, пов'язаних з їх графіком (наприклад, дані про трафік, маршрути автобусів, пішохідні доріжки), які впливають на алгоритм маршрутизації. Вони відомі як мультимодальні планові поїздки (де ви також можете вибрати "режими" планування - немає велосипедних доріжок - лише громадський транзит - така штука). Ви можете думати , як планування поїздки також стає час делікатного питання (тобто , якщо ви йдете назад кілька ребер назад, ви зможете зловити метро , який доставить вас до місця призначення вперед набагато швидше , ніж якби ви просто намагалися перейти краю вперед з використанням найменшої вартості).

"Великі хлопці" самі не зберігають свої дані в традиційній базі даних, вони використовують попередньо обчислені графіки (привітання кластерів hadoop / mapreduce!). Як ви можете собі уявити, ці графіки стають дійсно великими, тому знання, як з'єднати краї сусідніх графіків, може стати проблемою.

У будь-якому разі, я б рекомендував вам переглянути кілька мультимодальних проектів графіків маршрутизації:

Графічний сервер приходить на думку. Не багато документації, але багато чистого кодування (див. AFAIK, я вважаю, що MapQuest використовує варіацію цього проекту для деяких своїх продуктів маршрутизації).

Іншим варіантом буде OpenTripPlanner, який має за собою багато розумних людей (включаючи людей із графічного сервера).


15

Не впевнений, що він новіший, але у pgRouting є алгоритм Shooting-Star :

Алгоритм Shooting-Star - це останній з алгоритмів найкоротшого шляху pgRouting. Його особливістю є те, що він рухається від посилання на посилання, а не від вершини до вершини, як це роблять алгоритми Dijkstra та A-Star. Це дає змогу, наприклад, визначити відносини між посиланнями, і це вирішує деякі інші алгоритми на основі вершин, наприклад, "паралельні посилання", які мають одне джерело та ціль, але різні витрати.

Розширення ESRI Network Analyst використовує згаданий вами ієрархічний підхід для обмеження часу вирішення:

Пошук точного найкоротшого шляху на загальнонаціональних даних мережі забирає багато часу через велику кількість ребер, які потрібно шукати. Для підвищення продуктивності мережеві набори даних можуть моделювати природну ієрархію в транспортній системі, коли рух по міждержавному шосе є кращим, ніж рух по місцевих дорогах. Після створення ієрархічної мережі модифікація двонаправленої Dijkstra використовується для обчислення маршруту між початком та пунктом призначення.

На веб-сайті ESRI є дуже детальна довідка з прикладами такого підходу, однак для завантаження потрібна реєстрація (Ієрархічні маршрути в Білій книзі аналітика мережі ArcGIS).


11

Звуження Ієрархія дуже швидкий алгоритм:

Цей алгоритм зручний для оперативної пам’яті під час виконання запиту (для проведення графіку за контрактом потрібно ще кілька оперативної пам’яті, а також масивна попередня обробка)

Існують деякі інші алгоритми - в тому числі алгоритми, що вирішують маршрутизований громадський транспорт:

Microsoft також проводить деякі дослідження:

(що ж, Даніель Деллінг теж з Карлсруе)

Ви можете отримати цікаве введення та огляд доступних алгоритмів:

Попередження: німецькі (!) Лекції. але принаймні заголовки можуть допомогти вам отримати більше інформації (ALT, Arc-Flags, CHASE, ...) або додану літературу!

оновлення

Тепер GraphHopper реалізує ієрархії скорочень, а також інші алгоритми, ви також можете спробувати демо-версію .

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.