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

Ответ 1

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

Здесь самые быстрые алгоритмы маршрутизации в мире сравниваются и проверяются на правильность:

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

Вот техническая беседа google по теме:

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

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

http://tom.mapsforge.org/

Ответ 5

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

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

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

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

Ответ 6

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

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

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

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

Ответ 7

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

Ответ 8

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

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

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

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

Ответ 9

Современным уровнем техники в терминах времени запроса для статических дорожных сетей является алгоритм маркировки концентратора, предложенный 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 ГБ).

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

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

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

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

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

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

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

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

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

Ответ 10

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

Ответ 11

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

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

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

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

Ответ 12

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

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

Ответ 13

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

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

Ответ 14

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

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

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

Ответ 15

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

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

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

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

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

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

Ответ 16

Я вижу, что происходит с картами в OP:

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

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

Ответ 17

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

Ответ 18

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

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