Алгоритмы поиска пути (маршрутизация, планирование поездок) на графах с ограничениями по времени

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

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

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

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

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

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

Итак, вопрос: учитывая список остановок, маршрутов и время прибытия / отправления / поездки, как мне легко найти самый быстрый путь от остановки A до остановки B?


person lacop    schedule 30.08.2011    source источник


Ответы (1)


  1. Смоделируйте свою проблему в виде графика. Каждая станция будет Vertex, а каждый автобус / поезд будет Edge.
  2. создайте функцию w:Edges->R, которая указывает время / деньги / ... для каждого ребра.
  3. теперь у вас есть типичная проблема минимального пути, которую можно решить с помощью алгоритма Дейкстры, который находит минимальный путь ко всем вершинам из заданного источника.

(*) Для "наименьшего количества переходов" ваш вес фактически равен 1 для каждого ребра, поэтому вы даже можете оптимизировать его, запустив BFS или даже двунаправленный BFS вместо dijkstra, как я объяснено в этом сообщении [Это объясняется социальной дистанцией, но на самом деле это тот же алгоритм].


ИЗМЕНИТЬ
как изменение нестатической природы графика [для времени], которое вы упомянули в комментариях [для цены и количества переходов, то, что я упомянул выше, все еще применимо, поскольку эти графики статичны], вы можете использовать алгоритм маршрутизации вектора расстояния, который на самом деле означал работают для динамических графиков и представляют собой распределенный вариант алгоритма Беллмана Форда.
Идея алгоритма:

  • периодически каждая вершина отправляет свой «вектор расстояний» своим соседям [вектор указывает, сколько «стоит» путешествие от отправляющей вершины к каждой другой вершине.
  • Его соседи пытаются обновить свои таблицы маршрутизации [через какое ребро лучше всего перейти к каждой цели]
  • в вашем случае каждый узел знает, как быстрее всего добраться до своих соседей, [время в пути + время ожидания], и он [вершина / станция] добавляет это число к каждому входу в векторе расстояния, чтобы знать, как и сколько времени потребуется, чтобы добраться до места назначения. Когда автобус уезжает, время в пути должно быть пересчитано для всех узлов [из этого источника], и новый вектор должен быть отправлен его соседям.
person amit    schedule 30.08.2011
comment
Да, в этом случае вы не станете быстрее, чем алгоритм Дейкстры m, если только нет ограничений, которые вы сдерживаете, которые позволяют дальнейшую оптимизацию. Для показателей, отличных от времени, вам нужно будет сформулировать «вес», который представляет собой комбинацию времени, затрат и хлопот. Возможно, вам также придется предоставить пользователю возможность точно определять, каковы эти веса и пересчитывать их на лету, или иметь пару заранее определенных сценариев (100% времени, 100% дешево, 50/50/0, 40/40/20, и т.п.) и сохранить кешированную версию таблицы поиска Дейкстры. - person corsiKa; 30.08.2011
comment
Если я чего-то не упустил, это не сработает. Дейкстра отлично подходит для статического графа только с пространственной областью, но у нее есть временная область. Например, если вы доберетесь до узла на автобусе, который займет 1 минуту, края будут другими, чем если бы это заняло 5 минут. Вы можете опоздать на автобус, поэтому вес станет больше, потому что вам придется ждать. Кроме того, некоторые ребра могут исчезнуть, если вы попали в узел определенным образом (пропустили последнюю шину дня), но останутся там, если вы попали туда другим способом. AFAIK, Дейкстра не допускает этого, но, пожалуйста, поправьте меня, если я ошибаюсь. - person lacop; 30.08.2011
comment
@albwq: алгоритм Дейкстры не обрабатывает «ожидание» в вершинах следующей шины, в этом вы правы. Однако он действителен для двух других критериев, которые вы запросили: стоимости и количества переходов. [см. мой последний раздел о равномерной оптимизации количества переходов]. - person amit; 30.08.2011
comment
@albwq: Я отредактировал свой ответ и добавил краткое описание [и ссылки] алгоритма, предназначенного для обработки динамических сетей. - person amit; 30.08.2011
comment
Выглядит интересно, я попробую. Спасибо. - person lacop; 30.08.2011
comment
зомби-ответ для потерянных посетителей: почти все обычные алгоритмы не работают на графиках, зависящих от времени, особенно с временем ожидания. Быстрое и гибкое решение, которое действительно работает, - это RAPTOR. - person dube; 27.03.2015