Какие алгоритмы вычисляют направления от точки A к точке B на карте?

Как провайдеры карт (такие как Google или Yahoo! Maps) предлагают маршруты?

Я имею в виду, что они, вероятно, имеют реальные данные в некоторой форме, конечно, включая расстояния, но также, возможно, такие вещи, как скорость движения, наличие тротуаров, расписание поездов и т. Д. Но предположим, что данные были в более простом формате, скажем, очень большой ориентированный граф с весом ребер, отражающих расстояния. Я хочу иметь возможность быстро вычислять направления от одной произвольной точки к другой. Иногда эти точки будут близко друг к другу (в пределах одного города), а иногда они будут далеко друг от друга (кросс-кантри).

Алгоритмы графа, такие как алгоритм Дейкстры, не будут работать, потому что граф огромен. К счастью, эвристические алгоритмы типа A *, вероятно, будут работать. Тем не менее, наши данные очень структурированы, и, возможно, какой-то многоуровневый подход может сработать? (Например, сохраните предварительно вычисленные направления между определенными «ключевыми» точками далеко друг от друга, а также некоторые локальные направления. Тогда направления для двух удаленных точек будут включать локальные направления для ключевых точек, глобальные направления к другой ключевой точке, а затем локальные направления снова.)

Какие алгоритмы на самом деле используются на практике?

PS. Этот вопрос был мотивирован нахождением причуд в направлениях картографирования онлайн. Вопреки неравенству треугольника, иногда Google Maps считает, что XZ занимает больше времени и дальше, чем использование промежуточной точки, как в XYZ . Но, может быть, их маршруты для прогулок тоже оптимизированы для другого параметра?

PPS. Вот еще одно нарушение неравенства треугольника, которое предполагает (для меня), что они используют какой-то многоуровневый подход: XZ против XYZ . Бывший, кажется, использует выдающийся Севастопольский бульвар, хотя это немного в стороне.

Изменить : ни один из этих примеров, кажется, больше не работает, но оба работали во время первоначальной публикации.

Говоря как кто-то, кто провел 18 месяцев, работая в картографической компании, которая включала в себя работу над алгоритмом маршрутизации ... да, Дейкстра работает, с парой модификаций:

• Вместо того, чтобы делать Дейкстру один раз от источника к месту, вы начинаете с каждого конца и расширяете обе стороны, пока они не встретятся посередине. Это устраняет примерно половину работы (2 * pi * (r / 2) ^ 2 против pi * r ^ 2).
• Чтобы избежать изучения переулков каждого города между вашим источником и пунктом назначения, у вас может быть несколько слоев картографических данных: слой «шоссе», содержащий только шоссе, «вторичный» слой, содержащий только второстепенные улицы и т. Д. Затем вы исследуете только более мелкие разделы более подробных слоев, расширяясь по мере необходимости. Очевидно, что это описание оставляет много деталей, но вы поняли идею.

С изменениями в том же духе, вы можете сделать даже маршрутизацию по пересеченной местности в очень разумные сроки.

Этот вопрос был активной областью исследования в последние годы. Основная идея состоит в том, чтобы сделать предварительную обработку на графике один раз , чтобы ускорить все последующие запросы . С помощью этой дополнительной информации маршруты могут быть рассчитаны очень быстро. Тем не менее, алгоритм Дейкстры является основой для всех оптимизаций.

Арахнид описал использование двунаправленного поиска и сокращения границ на основе иерархической информации. Эти методы ускорения работают довольно хорошо, но самые последние алгоритмы превосходят эти методы во всех отношениях. С помощью современных алгоритмов на континентальной дорожной сети можно вычислить кратчайшие пути за значительно меньшее время, чем за одну миллисекунду . Для быстрой реализации неизмененного алгоритма Дейкстры требуется около 10 секунд .

В статье « Разработка алгоритмов планирования быстрых маршрутов» дается обзор хода исследований в этой области. См. Ссылки этого документа для получения дополнительной информации.

Самые быстрые из известных алгоритмов не используют информацию об иерархическом статусе дороги в данных, т.е. если это шоссе или местная дорога. Вместо этого они вычисляют на этапе предварительной обработки собственную иерархию, оптимизированную для ускорения планирования маршрута. Это предварительное вычисление может затем использоваться для сокращения поиска: вдали от начальной и конечной точек медленные дороги не должны учитываться во время алгоритма Дейкстры. Преимущества очень хорошая производительность и правильность гарантия результата.

Первые оптимизированные алгоритмы планирования маршрутов имели дело только со статическими дорожными сетями, это означает, что ребро на графике имеет фиксированное значение стоимости. На практике это не так, поскольку мы хотим принимать во внимание динамическую информацию, такую ​​как пробки или ограничения, зависящие от транспортных средств. Последние алгоритмы также могут иметь дело с такими проблемами, но есть еще проблемы для решения, и исследования продолжаются.

Если вам нужны кратчайшие расстояния для расчета решения для TSP , то вас, вероятно, интересуют матрицы, которые содержат все расстояния между вашими источниками и пунктами назначения. Для этого вы можете рассмотреть возможность вычисления кратчайших путей «многие ко многим» с использованием иерархий дорог . Обратите внимание, что это было улучшено благодаря новым подходам за последние 2 года.

Надеемся, что просто устраняя нарушения неравенства треугольника, дополнительный фактор, на который они оптимизируют, - это здравый смысл. Вы не обязательно хотите самый короткий или быстрый маршрут, так как это может привести к хаосу и разрушению . Если вы хотите, чтобы ваши маршруты предпочитали основные маршруты, удобные для грузовиков и способные справиться с отправкой каждого водителя, следующего за спутником, вы быстро отбросите неравенство треугольника [1].

Если Y является узкой жилой улицей между X и Z, вы, вероятно, захотите использовать ярлык только через Y, если пользователь явно запрашивает XYZ. Если они просят XZ, они должны придерживаться главных дорог, даже если это немного дальше и занимает немного больше времени. Это похоже на парадокс Брасса - если каждый попытается выбрать самый короткий и быстрый маршрут, возникшая в результате перегрузка означает, что это уже не самый быстрый маршрут для кого-либо. Отсюда мы отклоняемся от теории графов в теорию игр.

[1] Фактически, любая надежда на то, что полученные расстояния будут функцией расстояния в математическом смысле, умирает, когда вы разрешаете односторонние дороги и теряете требование симметрии. Потерять неравенство треугольника - это просто растереть соль в ране.

Вот самые быстрые в мире алгоритмы маршрутизации, проверенные на правильность:

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

Вот технический доклад Google на эту тему:

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

Вот реализация алгоритма магистральных иерархий, которая обсуждалась Шультесом (в настоящее время только в Берлине, я пишу интерфейс, а также разрабатывается мобильная версия):

http://tom.mapsforge.org/

Я раньше не работал над Google, Microsoft или Yahoo Maps, поэтому не могу рассказать, как они работают.

Однако я разработал специальную систему оптимизации цепочки поставок для энергетической компании, которая включала приложение для планирования и маршрутизации для их парка грузовых автомобилей. Однако наши критерии маршрутизации были гораздо более специфичными для бизнеса, чем где строительство или замедление движения или закрытие полосы движения.

Мы использовали метод ACO (оптимизация колоний муравьев) для планирования и маршрутизации грузовых автомобилей. Этот метод является методом искусственного интеллекта, который был применен к задаче коммивояжера для решения задач маршрутизации. Хитрость с ACO состоит в том, чтобы построить расчет ошибки на основе известных фактов маршрутизации, чтобы модель решения графа знала, когда выходить (когда ошибка достаточно мала).

Вы можете Google ACO или TSP, чтобы узнать больше об этой технике. Однако для этого я не использовал ни один из инструментов ИИ с открытым исходным кодом, поэтому не могу предложить один (хотя я слышал, что SWARM был довольно всеобъемлющим).

Алгоритмы графа, такие как алгоритм Дейкстры, не будут работать, потому что граф огромен.

Этот аргумент не обязательно верен, потому что Дейкстра обычно не смотрит на полный граф, а просто на очень маленькое подмножество (чем лучше взаимосвязан граф, тем меньше это подмножество).

Дейкстра на самом деле может показывать неплохие результаты для графов с хорошим поведением. С другой стороны, при тщательной параметризации A * всегда будет работать так же хорошо или лучше. Вы уже пробовали, как это будет работать с вашими данными?

Тем не менее, мне также было бы очень интересно услышать об опыте других людей. Конечно, такие интересные примеры, как поиск в Google Map, особенно интересны. Я мог бы представить что-то вроде направленной эвристики ближайшего соседа.

Современным уровнем техники с точки зрения времени запросов для статических дорожных сетей является алгоритм маркировки концентратора, предложенный Abraham et al. http://link.springer.com/chapter/10.1007/978-3-642-20662-7_20 . Сквозное и превосходно написанное исследование области было недавно опубликовано в виде технического отчета Microsoft http://research.microsoft.com/pubs/207102/MSR-TR-2014-4.pdf .

Короткая версия ...

Алгоритм маркировки концентратора обеспечивает самые быстрые запросы для статических дорожных сетей, но для его работы требуется большое количество оперативной памяти (18 ГиБ).

Маршрутизация транзитного узла немного медленнее, хотя требует всего около 2 ГБ памяти и быстрее обрабатывается.

Сокращенные иерархии обеспечивают хороший компромисс между быстрым временем предварительной обработки, низкими требованиями к пространству (0,4 ГиБ) и быстрым временем запроса.

Ни один алгоритм полностью не доминирует ...

Этот технический доклад Google Питера Сандерса может представлять интерес

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

Также этот разговор Эндрю Голдберг

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

С открытым исходным кодом реализации иерархий сокращения можно ознакомиться на веб-сайте исследовательской группы Питера Сандерса в KIT. http://algo2.iti.kit.edu/english/routeplanning.php

Также легко доступное сообщение в блоге, написанное Microsoft об использовании алгоритма CRP ... http://blogs.bing.com/maps/2012/01/05/bing-maps-new-routing-engine/

Я немного удивлен, что не увидел упомянутый здесь алгоритм Флойда Варшалла . Этот алгоритм работы очень похож на работу Дейкстры. У него также есть одна очень приятная особенность, которая позволяет вам вычислять столько времени, сколько вы хотите продолжить, используя больше промежуточных вершин. Таким образом, он довольно быстро найдет маршруты, которые используют автомагистрали между штатами или автомагистрали.

Я делал это довольно много раз, на самом деле, пробуя несколько разных методов. В зависимости от размера (географического) карты вы можете рассмотреть возможность использования функции haversine в качестве эвристики.

Лучшее решение, которое я сделал, это использование A * с расстоянием по прямой линии в качестве эвристической функции. Но тогда вам нужны какие-то координаты для каждой точки (пересечения или вершины) на карте. Вы также можете попробовать различные весовые коэффициенты для эвристической функции, т.е.

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

где k - некоторая постоянная, больше чем 0.

Вероятно, аналогично ответу на предварительно вычисленных маршрутах между основными местоположениями и многоуровневыми картами, но я понимаю, что в играх для ускорения A * у вас есть карта, которая является очень грубой для макро-навигации, и детальная карта для навигация к границе макро направлений. Таким образом, у вас есть 2 маленьких пути для расчета, и, следовательно, ваше пространство поиска намного меньше, чем просто сделать один путь к месту назначения. И если вы делаете это много, у вас будет много предварительно вычисленных данных, поэтому, по крайней мере, часть поиска - это поиск предварительно вычисленных данных, а не поиск пути.

Это чистое предположение с моей стороны, но я предполагаю, что они могут использовать структуру данных карты влияния, накладывающую ориентированную карту, чтобы сузить область поиска. Это позволило бы алгоритму поиска направлять путь к основным маршрутам, когда желаемое путешествие длинное.

Учитывая, что это приложение Google, также разумно предположить, что большая часть волшебства делается с помощью обширного кэширования. :) Я бы не удивился, если бы кэширование 5% самых распространенных запросов маршрута Google Map позволило получить большой кусок (20%? 50%?) Запросов, на которые можно было бы ответить простым поиском.

У меня было еще несколько мыслей по этому поводу:

1) Помните, что карты представляют физическую организацию. Сохраните широту / долготу каждого пересечения. Вам не нужно проверять многое за точки, которые лежат в направлении вашей цели. Только если вы оказались заблокированы, вам нужно выйти за рамки этого. Если вы сохраняете наложение превосходных соединений, вы можете ограничить его еще больше - обычно вы никогда не встретите одно из них таким образом, чтобы это было далеко от вашего конечного пункта назначения.

2) Разделите мир на целую группу зон, ограниченных связью, определите все точки соединения между зонами. Найдите зоны, в которых находятся ваш источник и цель, для маршрута начальной и конечной зоны от вашего местоположения до каждой точки подключения, для зон между просто отображением между точками подключения. (Я подозреваю, что многие из них уже рассчитаны заранее.)

Обратите внимание, что зоны могут быть меньше, чем столичная зона. Любой город с особенностями местности, которые делят его (например, река), будет состоять из нескольких зон.

Мне было очень любопытно использовать эвристику, когда некоторое время назад мы получили маршруты из одной и той же стартовой точки возле Санта-Роза, к двум разным лагерям в национальном парке Йосемити. Эти разные пункты назначения дали совершенно разные маршруты (через I-580 или CA-12), несмотря на тот факт, что оба маршрута сошлись за последние 100 миль (вдоль CA-120), после чего снова разошлись на несколько миль в конце. Это было довольно повторяемым. Эти два маршрута были на расстоянии до 50 миль на протяжении примерно 100 миль, но расстояния / время были довольно близки друг к другу, как и следовало ожидать.

Увы, я не могу воспроизвести это - алгоритмы, должно быть, изменились. Но мне было любопытно по поводу алгоритма. Все, что я могу предположить, - это то, что было некоторое направленное сокращение, которое оказалось чрезвычайно чувствительным к крошечной угловой разнице между пунктами назначения, как видно издалека, или были разные предварительно вычисленные сегменты, выбранные по выбору конечного пункта назначения.

Говоря о GraphHopper , быстром планировщике маршрутов с открытым исходным кодом на основе OpenStreetMap, я прочитал немного литературы и реализовал некоторые методы. Самым простым решением является Dijkstra, а простым улучшением является двунаправленная Dijkstra, которая исследует примерно только половину узлов. С двунаправленной Dijkstra маршрут через всю Германию занимает уже 1 секунду (для автомобильного режима), в C это будет, вероятно, только 0,5 с или около того;)

Я создал анимированный GIF-файл поиска по реальному пути с двунаправленной Dijkstra здесь . Также есть еще несколько идей, чтобы сделать Dijkstra быстрее, чем делать A *, который является «ориентированным на цель Dijkstra». Также я создал для него gif-анимацию .

Но как это сделать (намного) быстрее?

Проблема в том, что для поиска пути необходимо изучить все узлы между точками, и это действительно дорого, так как в Германии их уже несколько миллионов. Но дополнительная проблема Dijkstra и т. Д. Состоит в том, что такие поиски используют много оперативной памяти.

Существуют эвристические решения, но также и точные решения, которые организуют график (дорожную сеть) в иерархических слоях, имеют как преимущества, так и недостатки и в основном решают проблему скорости и оперативной памяти. Я перечислил некоторые из них в этом ответе .

Для GraphHopper я решил использовать Иерархии Сокращения, потому что это относительно «легко» реализовать и не требует много времени для подготовки графа. Это по-прежнему приводит к очень быстрому времени отклика, как вы можете проверить в нашем онлайн-экземпляре GraphHopper Maps . Например, из Южной Африки в восточный Китай, что составляет 23000 км и почти 14 дней езды на автомобиле, а на сервере - всего ~ 0,1 с.

Я работал над маршрутизацией в течение нескольких лет, с недавним всплеском активности, вызванным потребностями моих клиентов, и я обнаружил, что A * достаточно быстро; на самом деле нет необходимости искать оптимизацию или более сложные алгоритмы. Маршрутизация по огромному графу не является проблемой.

Но скорость зависит от наличия в сети всей сети маршрутизации, под которой я подразумеваю ориентированный граф дуг и узлов, представляющих сегменты и соединения маршрутов соответственно. Основные временные затраты - это время, необходимое для создания этой сети. Некоторые приблизительные цифры, основанные на обычном ноутбуке под управлением Windows и маршрутизации по всей Испании: время, необходимое для создания сети: 10-15 секунд; время, необходимое для расчета маршрута: слишком мало для измерения.

Другая важная вещь - это возможность повторно использовать сеть для сколь угодно большого количества вычислений маршрутизации. Если ваш алгоритм каким-то образом пометил узлы, чтобы записать лучший маршрут (общую стоимость для текущего узла и лучшую дугу к нему) - как это должно быть в A * - вы должны сбросить или очистить эту старую информацию. Вместо прохождения сотен тысяч узлов проще использовать систему нумерации поколений. Отметьте каждый узел номером поколения его данных; увеличить номер генерации при расчете нового маршрута; любой узел со старшим номером поколения устарел, и его информацию можно игнорировать.

Я вижу, что случилось с картами в ОП:

Посмотрите на маршрут с указанной промежуточной точкой: маршрут идет немного назад из-за той дороги, которая не является прямой.

Если их алгоритм не вернется назад, он не увидит более короткий маршрут.

Алгоритм кратчайшего пути для всех пар вычислит кратчайшие пути между всеми вершинами графа. Это позволит предварительно вычислять пути вместо того, чтобы требовать вычисления пути каждый раз, когда кто-то хочет найти кратчайший путь между источником и пунктом назначения. Алгоритм Флойда-Варшалла является алгоритмом кратчайшего пути для всех пар.

Карты никогда не принимают во внимание всю карту. Я предполагаю: - 1. В зависимости от вашего местоположения, они загружают место и достопримечательности на этом месте. 2. Когда вы ищете пункт назначения, то есть когда они загружают другую часть карты и составляют график из двух мест, а затем применяют алгоритмы кратчайшего пути.

Кроме того, существует важный метод динамического программирования, который, как я подозреваю, используется при расчете кратчайших путей. Вы можете также сослаться на это.