Планировщик поездок , планировщик маршрутов или планировщик маршрутов — это специализированная поисковая система , используемая для поиска оптимальных способов передвижения между двумя или более заданными местами, иногда с использованием более одного вида транспорта . [1] [2] Поиски могут быть оптимизированы по различным критериям, например, самый быстрый , самый короткий , с наименьшим количеством пересадок , самый дешевый . [3] Они могут быть ограничены, например, отправлением или прибытием в определенное время, чтобы избегать определенных промежуточных точек и т. д. Одна поездка может использовать последовательность из нескольких видов транспорта , что означает, что система может знать об услугах общественного транспорта , а также о транспортных сетях для частного транспорта. Планирование поездки или планирование путешествия иногда отличается от планирования маршрута , [4] которое обычно рассматривается как использование частных видов транспорта, таких как езда на велосипеде , вождение автомобиля или ходьба , обычно с использованием одного вида транспорта за раз. Планирование поездки или путешествия, напротив, будет использовать по крайней мере один вид общественного транспорта , который работает в соответствии с опубликованными расписаниями ; Учитывая, что общественный транспорт отправляется только в определенное время (в отличие от частного транспорта, который может отправляться в любое время), алгоритм должен не только найти путь к месту назначения, но и попытаться оптимизировать его, чтобы минимизировать время ожидания на каждом этапе. В европейских стандартах, таких как Transmodel , планирование поездки используется специально для описания планирования маршрута для пассажира, чтобы избежать путаницы с совершенно отдельным процессом планирования операционных поездок, которые будут совершаться общественными транспортными средствами, на которых такие поездки совершаются.
Планировщики поездок широко используются в индустрии туризма с 1970-х годов агентами по бронированию. [5] Развитие Интернета , распространение геопространственных данных и развитие информационных технологий в целом привели к быстрому развитию множества приложений для самостоятельного обслуживания или браузерных онлайн- планировщиков интермодальных поездок.
Планировщик поездок можно использовать совместно с системами продажи билетов и бронирования.
В конце 1980-х и начале 1990-х годов некоторые национальные железнодорожные операторы и крупные столичные транзитные органы разработали собственные специализированные планировщики поездок для поддержки своих служб запросов клиентов. Они обычно работали на мэйнфреймах и имели внутренний доступ с терминалами для их собственных сотрудников в центрах информации для клиентов, колл-центрах и в билетных кассах для ответа на запросы клиентов. Данные поступали из баз данных расписаний, используемых для публикации печатных расписаний и управления операциями, а некоторые включали простые возможности планирования маршрутов. Информационная система расписания движения поездов HAFAs, разработанная в 1989 году немецкой компанией [6] Hacon (теперь часть Siemens AG), является примером такой системы и была принята Швейцарскими федеральными железными дорогами (SBB) и Deutsche Bahn в 1989 году. Система «Маршруты» Лондонского транспорта (теперь TfL ), использовавшаяся до разработки онлайн-планировщика и охватывающая все службы общественного транспорта в Лондоне, была еще одним примером мэйнфреймового OLTP-планировщика поездок и включала большую базу данных туристических достопримечательностей и популярных мест в Лондоне.
В 1990-х годах с появлением персональных компьютеров с достаточной памятью и процессорной мощностью для планирования поездок (что является относительно дорогим вычислительным процессом с точки зрения требований к памяти и процессору), были разработаны системы, которые можно было устанавливать и запускать на мини-компьютерах и персональных компьютерах. Первая цифровая система планирования поездок на общественном транспорте для микрокомпьютера была разработана Эдуардом Тульпом, студентом факультета информатики Амстердамского университета на компьютере Atari . [7] Он был нанят Голландскими железными дорогами для создания цифрового планировщика поездок для железнодорожных служб. В 1990 году первый цифровой планировщик поездок для Голландских железных дорог (на дискете) был продан для установки на ПК и компьютеры для офлайн-консультаций. [8] Принципы его программного обеспечения были опубликованы в голландской университетской статье в 1991 году [9] Вскоре он был расширен, чтобы включить весь общественный транспорт в Нидерландах.
Другим пионером был Ганс-Якоб Тоблер в Швейцарии. Его продукт Finajour , работавший на PC DOS и MS-DOS, был первым электронным расписанием для Швейцарии. Первая опубликованная версия продавалась в течение периода расписания 1989/1990. [10] [11] [12] Вскоре последовали и другие европейские страны, выпустившие собственные планировщики путешествий.
Дальнейшим развитием этой тенденции стало развертывание планировщиков поездок на еще меньших платформах, таких как мобильные устройства. В 1998 году была выпущена версия Hafas для Windows CE , которая сжала приложение и все расписание поездов Deutsche Bahn до шести мегабайт и работала как автономное приложение.
Развитие Интернета позволило добавить основанные на HTML пользовательские интерфейсы, чтобы позволить широкой публике напрямую запрашивать системы планирования поездок. Тестовый веб-интерфейс для HaFA был запущен в качестве официального планировщика железнодорожных поездок Deutsche Bahn в 1995 году и со временем превратился в главный веб-сайт Deutsche Bahn. В 2001 году Transport for London запустил первый в мире крупномасштабный планировщик мультимодальных поездок для мирового города, охватывающий все виды транспорта Лондона, а также железнодорожные маршруты в Лондон; он использовал механизм планирования поездок, предоставленный [1] Mentz Gmbh] из Мюнхена после того, как более ранние попытки в конце 1990-х годов добавить веб-интерфейс к собственному внутреннему планировщику поездок TfL на мэйнфрейме не смогли масштабироваться. Интернет-планировщики поездок для крупных транспортных сетей, таких как национальные железные дороги и крупные города, должны поддерживать очень высокую частоту запросов и поэтому требуют программных архитектур, оптимизированных для поддержки такого трафика. Первый в мире мобильный планировщик поездок для большой столичной области, интерфейс на основе WAP для Лондона с использованием движка Mentz, был запущен в 2001 году лондонской стартап-компанией Kizoom Ltd, которая также запустила первый в Великобритании планировщик железнодорожных поездок для мобильного Интернета в 2000 году, также как WAP-сервис, а затем и SMS-сервис. Начиная с 2000 года, сервис Traveline [13] предоставлял всем частям Великобритании региональное мультимодальное планирование поездок на автобусах, междугородных автобусах и поездах. Веб-планировщик поездок для железных дорог Великобритании был запущен UK National Rail Enquiries в 2003 году.
Ранние планировщики поездок на общественном транспорте обычно требовали указания остановки или станции для конечных точек. Некоторые также поддерживали ввод названия туристической достопримечательности или других популярных мест назначения, сохраняя таблицу ближайшей к месту назначения остановки. Позже это было расширено возможностью добавления адресов или координат для предложения истинного планирования от точки до точки.
Решающее значение для развития крупномасштабного планирования мультимодальных поездок в конце 1990-х и начале 2000-х годов имела параллельная разработка стандартов для кодирования данных об остановках и расписании от многих различных операторов и настройка рабочих процессов для регулярного агрегирования и распространения данных. Это сложнее для таких видов транспорта, как автобусы и междугородные автобусы, где, как правило, существует большое количество мелких операторов, чем для железной дороги, где обычно задействовано всего несколько крупных операторов, у которых уже есть форматы обмена и процессы для управления своими сетями. В Европе, где есть плотная и сложная сеть общественного транспорта, была разработана эталонная модель CEN Transmodel для общественного транспорта для поддержки процесса создания и гармонизации стандартных форматов как на национальном, так и на международном уровне.
В 2000-х годах в рамках нескольких крупных проектов были разработаны распределенные архитектуры планирования поездок, позволяющие объединить отдельные планировщики поездок, каждый из которых охватывает определенную область, для создания составного движка, охватывающего очень большую территорию.
Планировщики поездок на общественном транспорте оказались чрезвычайно популярными (например, к 2005 году Deutsche Bahn уже получала [6] 2,8 миллиона запросов в день, а сайты планирования поездок являются одними из самых посещаемых информационных сайтов в каждой стране, где они есть. Возможность покупки билетов на поездки на найденные поездки еще больше увеличила полезность и популярность сайтов; ранние реализации, такие как Trainline в Великобритании, предлагали доставку билетов по почте; в большинстве европейских стран это было дополнено методами самостоятельной печати и мобильной доставки. Интернет-планировщики поездок теперь являются основным каналом продаж для большинства железнодорожных и воздушных транспортных операторов.
Google начал добавлять возможности планирования поездок в свой набор продуктов с версией Google Transit в 2005 году, охватывающей поездки в регионе Портленда , как описано менеджером агентства TriMet [17] Бибианой Макхью. Это привело к разработке General Transit Feed Specification (GTFS), формата для сбора транзитных данных для использования в планировщиках поездок, который оказал большое влияние на разработку экосистемы потоков данных PT, охватывающих многие разные страны. Успешное принятие GTFS в качестве доступного выходного формата крупными операторами во многих странах позволило Google расширить покрытие своего планировщика поездок на многие другие регионы по всему миру. Возможности планирования поездок Google Transit были интегрированы в продукт Google Maps в 2012 году.
Дальнейшее развитие механизмов планирования поездок привело к интеграции данных в реальном времени, чтобы планы поездок на ближайшее будущее учитывали задержки и сбои в реальном времени. UK National Rail Enquiries добавили реальное время в свой планировщик поездок на поезде в 2007 году. Также значительным было включение других типов данных в результаты планирования поездок, таких как уведомления о сбоях, уровни загруженности, расходы на CO2 и т. д. Планировщики поездок некоторых крупных мегаполисов, такие как Transport for London trip planner, имеют возможность динамически приостанавливать отдельные станции и целые линии, чтобы во время крупных сбоев создавались измененные планы поездок, которые исключают недоступные части сети. Другим развитием стало добавление данных о доступности и способность алгоритмов оптимизировать планы с учетом требований конкретных ограничений, таких как доступ для инвалидных колясок.
Для Олимпийских игр 2012 года в Лондоне был создан улучшенный планировщик поездок в Лондон, который позволял смещать предлагаемые результаты поездок для управления доступной пропускной способностью по разным маршрутам, распределяя трафик по менее загруженным маршрутам. Еще одним нововведением стало подробное моделирование всех путей доступа в и из каждого олимпийского объекта (от остановки PT до входа на индивидуальную арену) с прогнозируемым и фактическим временем ожидания в очереди, чтобы обеспечить проверку безопасности и другие задержки, которые учитываются в рекомендуемом времени поездки.
Инициатива по разработке планировщика поездок с открытым исходным кодом [18] OpenTripPlanner была инициирована транспортным агентством TriMet из Портленда, штат Орегон , в 2009 году и разработана при участии агентств и операторов из США и Европы; полная версия 1.0, выпущенная в сентябре 2016 года, позволяет небольшим транспортным агентствам и операторам предоставлять услуги по планированию поездок без уплаты лицензионных сборов за патентованную услугу.
Планировщик маршрутов общественного транспорта — это планировщик интермодальных поездок, обычно доступный через Интернет , который предоставляет информацию о доступных услугах общественного транспорта . Приложение предлагает пользователю ввести исходную точку и пункт назначения, а затем использует алгоритмы для поиска хорошего маршрута между ними на услугах общественного транспорта. Время в пути может быть ограничено либо временем отправления, либо временем прибытия, а также могут быть указаны другие предпочтения маршрута.
Планировщик интермодальных поездок поддерживает интермодальные поездки , т. е. поездки с использованием более чем одного вида транспорта , например, велосипеда, скоростного транспорта , автобуса , парома и т. д. Многие планировщики маршрутов поддерживают планирование «от двери до двери», в то время как другие работают только между остановками в транспортной сети , такими как станции, аэропорты или автобусные остановки .
Для маршрутизации общественного транспорта планировщик поездок ограничен временем прибытия или отправления. Он также может поддерживать различные критерии оптимизации — например, самый быстрый маршрут, наименьшее количество пересадок, наиболее доступный . Оптимизация по цене ( самый дешевый, самый гибкий тариф и т. д.) обычно выполняется отдельным алгоритмом или движком, хотя планировщики поездок, которые могут возвращать цены на билеты для найденных ими поездок, также могут предлагать сортировку или фильтрацию результатов по цене и типу продукта. Для планирования дальних железнодорожных и воздушных поездок, где цена является существенным фактором при оптимизации цены, планировщики поездок могут предлагать клиентам самые дешевые даты для поездки с гибким временем в пути.
Планирование дорожных участков иногда выполняется отдельной подсистемой в планировщике поездок, но может учитывать как расчеты поездок в одном режиме, так и интермодальные сценарии (например, Park and Ride , kiss and ride и т. д.). Типичные оптимизации для автомобильной маршрутизации — кратчайший маршрут , самый быстрый маршрут , самый дешевый маршрут и ограничения для определенных промежуточных точек. Рост популярности электромобилей ставит новые задачи перед планированием маршрутов, например, разреженная инфраструктура зарядки, ограниченный запас хода и длительная зарядка должны быть приняты во внимание и оставлять место для оптимизации. [19] Некоторые продвинутые планировщики поездок могут учитывать среднее время поездки на участках дороги или даже прогнозируемое в реальном времени среднее время поездки на участках дороги.
Планировщик маршрутов в идеале должен предоставлять подробные маршруты пешеходного доступа к остановкам, станциям, достопримечательностям и т. д. Он будет включать в себя параметры, учитывающие требования доступности для различных типов пользователей, например: «без ступенек», «без доступа для инвалидных колясок», «без лифтов» и т. д.
Некоторые системы планирования поездок могут рассчитывать велосипедные маршруты, [20] объединяя все пути, доступные для велосипедистов, и часто включая дополнительную информацию, такую как топография, дорожное движение, инфраструктура для езды на велосипеде на улице и т. д. Эти системы предполагают или позволяют пользователю указывать предпочтения в отношении тихих или безопасных дорог, минимального перепада высот, велосипедных дорожек и т. д.
Планировщики поездок зависят от ряда различных типов данных, а качество и объем этих данных ограничивают их возможности. Некоторые планировщики поездок интегрируют множество различных типов данных из многочисленных источников. Другие могут работать только с одним режимом, например, с маршрутами полетов между аэропортами, или использовать только адреса и уличную сеть для маршрутов движения.
Пассажиры путешествуют не потому, что хотят попасть на определенную станцию или остановку, а потому, что хотят попасть в интересующее их место, например, на спортивную арену, туристическую достопримечательность, торговый центр, парк, суд и т. д. и т. п. Многие планировщики поездок позволяют пользователям искать такие «Точки интереса» либо по названию, либо по категории ( музей, стадион, тюрьма и т. д.). Наборы данных систематически названных, геокодированных и категоризированных популярных мест назначения можно получить на коммерческой основе, например, набор данных The UK PointX [21] , или получить из наборов данных с открытым исходным кодом, таких как OpenStreetMap . Крупные операторы, такие как Transport for London или National Rail, исторически имели хорошо разработанные наборы таких данных для использования в своих центрах обработки вызовов клиентов, а также информацию о ссылках на ближайшие остановки. Для точек интереса, которые охватывают большую площадь, таких как парки, загородные дома или стадионы, важно точное геокодирование входов.
Пользовательские интерфейсы планирования поездок могут быть сделаны более удобными в использовании за счет интеграции данных Gazetteer . Это может быть связано с остановками, чтобы помочь с поиском остановок, в частности, для устранения неоднозначности; в США есть 33 места с названием Newport и 14 в Великобритании - Gazetteer может использоваться для различения, что есть что, а также в некоторых случаях для указания связи транспортных развязок с городами и городскими центрами, куда пассажиры пытаются добраться - например, только один из пяти или около того аэропортов Лондона фактически находится в Лондоне. Данные для этой цели обычно берутся из дополнительных слоев в наборе данных карты, например, предоставленном Esri , Ordnance Survey , Navtech или специальными наборами данных, такими как UK National Public Transport Gazetteer .
Планировщики дорожных поездок, иногда называемые планировщиками маршрутов, используют данные уличной и пешеходной сети для расчета маршрута, используя просто сетевое подключение (т. е. поездки могут выполняться в любое время и не ограничиваться расписанием). Такие данные могут поступать из одного или нескольких общедоступных, коммерческих или краудсорсинговых наборов данных, таких как TIGER , Esri или OpenStreetMap . Данные являются основополагающими как для расчета участков доступа для достижения остановок общественного транспорта, так и для расчета дорожных поездок как таковых. Основополагающим представлением является граф узлов и ребер (т. е. точек и связей). Данные могут быть дополнительно аннотированы для помощи в планировании поездок для различных видов транспорта;
Продвинутые планировщики поездок учитывают состояние сети в реальном времени. Для этого они используют два основных типа фидов, полученных от служб дорожных данных с использованием интерфейсов, таких как Datex II или UTMC .
Для работы планировщиков маршрутов транзита данные о расписании транзита должны всегда быть актуальными. Для облегчения обмена данными и взаимодействия между различными планировщиками поездок появилось несколько стандартных форматов данных.
Общая спецификация транзитных потоков , разработанная в 2006 году [22] , в настоящее время используется сотнями транспортных агентств по всему миру.
В Европейском Союзе все операторы общественного пассажирского транспорта обязаны предоставлять информацию в соответствии с форматом обмена данными о расписании движения поездов ЕС. [23] [24] [25] В других частях мира существуют схожие стандарты обмена. [26]
Местоположение и идентификация точек доступа к общественному транспорту, таких как автобусные, трамвайные и междугородные остановки, станции, аэропорты, паромные причалы и порты, имеют основополагающее значение для планирования поездок, а набор данных об остановках является существенным слоем инфраструктуры транспортных данных. Для интеграции остановок с пространственными поисками и системами маршрутизации дорог они геокодируются . Для интеграции их с расписаниями и маршрутами им присваивается уникальный идентификатор в транспортной сети. Для того чтобы быть узнаваемыми для пассажиров, им присваиваются официальные названия, а также может иметься общедоступный короткий код (например, трехбуквенные коды ИАТА для аэропортов) для использования в интерфейсах. Исторически сложилось так, что разные операторы довольно часто использовали разные идентификаторы для одной и той же остановки, а номера остановок не были уникальными в пределах страны или даже региона. Системы управления данными об остановках, такие как набор кодов местоположений станций Международного союза железных дорог (МСЖД) или система NaPTAN (Национальная точка доступа к общественному транспорту) Великобритании для номеров остановок, обеспечивают средства обеспечения уникальности номеров и полного описания остановок, что значительно облегчает интеграцию данных. Форматы обмена расписаниями, такие как GTFS , TransXChange или NeTEx, включают в себя данные об остановках, а пространственные наборы данных, такие как OpenStreetMap, позволяют геокодировать идентификаторы остановок.
Для сетей общественного транспорта с очень высокой частотой обслуживания, таких как городские метрополитены и внутригородские автобусные службы, топология сети также может использоваться для планирования маршрута, при этом предполагается средний интервал, а не конкретное время отправления. Данные о маршрутах поездов и автобусов также полезны для визуализации результатов, например, для нанесения маршрута поезда на карту. Национальные картографические органы, такие как Картографическое управление Великобритании, обычно включают транспортный слой в свои наборы данных, а европейская структура INSPIRE включает инфраструктурные связи общественного транспорта в свой набор стратегических цифровых данных. Формат CEN NeTEx позволяет обмениваться как физическим слоем (например, инфраструктурными связями автомобильных и железнодорожных путей), так и логическим слоем (например, связями между запланированными пунктами остановок на данной линии) транспортной инфраструктуры
В Великобритании Online Journey Planner (OJP) — это механизм, используемый National Rail для планирования маршрутов, расчета тарифов и определения наличия билетов. OJP получает информацию о маршрутах из механизма планирования SilverRail, известного как IPTIS (Integrated Passenger Transport Information System). На веб-сайте National Rail представлена информация о том, как компании могут получить прямой доступ к этим данным через файлы xml онлайн-потока данных. [27] Однако в 2023 году OJP был отключен в пользу нового планировщика поездок, который в настоящее время интегрирован в nationalrail.co.uk.
Данные о расписании общественного транспорта используются планировщиками поездок для определения доступных поездок в определенное время. Исторически данные о железнодорожном транспорте были широко доступны в национальных форматах, и во многих странах также имеются данные об автобусах и других видах транспорта в национальных форматах, таких как VDV 452 (Германия), TransXChange (Великобритания) и Neptune (Франция). Данные о расписании также все чаще становятся доступными в международных форматах, таких как GTFS и NeTEx . Чтобы маршрут можно было спроецировать на карту, GTFS позволяет указать простую форму графика; в то время как основанные на Transmodel стандарты, такие как CEN NeTEx , TransXChange, дополнительно допускают более подробное представление, которое может распознавать составляющие связи и различать несколько различных семантических слоев. [1]
Планировщики поездок могут иметь возможность включать информацию в режиме реального времени в свою базу данных и учитывать ее при выборе оптимальных маршрутов для поездок в ближайшем будущем. Системы автоматического определения местоположения транспортных средств (AVL) [2] отслеживают местоположение транспортных средств с помощью систем GPS и могут передавать информацию в режиме реального времени и прогнозы в систему планирования поездок. [1] Планировщик поездок может использовать интерфейс в режиме реального времени, такой как CEN Service Interface for Real Time Information, чтобы получить эти данные.
Ситуация — это программное представление инцидента [ требуется ссылка ] или события, которое влияет или может повлиять на транспортную сеть. Планировщик поездок может интегрировать информацию о ситуации и использовать ее как для пересмотра расчетов планирования поездки, так и для аннотирования своих ответов, чтобы информировать пользователей как через текстовое представление, так и через картографическое представление. Планировщик поездок обычно использует стандартный интерфейс, такой как SIRI , TPEG или Datex II, для получения информации о ситуации.
Инциденты фиксируются с помощью системы сбора инцидентов (ICS) различными операторами и заинтересованными сторонами, например, в диспетчерских транспортных операторов, вещателями или аварийными службами. Текстовая и графическая информация может быть объединена с результатом поездки. Недавние инциденты могут быть рассмотрены в маршруте, а также визуализированы на интерактивной карте.
Обычно планировщики поездок используют эффективное представление сети и расписания в памяти, чтобы обеспечить быстрый поиск большого количества путей. Запросы к базе данных также могут использоваться, когда количество узлов, необходимых для вычисления поездки, невелико, и для доступа к вспомогательной информации, касающейся поездки. Один движок может содержать всю транспортную сеть и ее расписания или может позволять распределенное вычисление поездок с использованием распределенного протокола планирования поездок, такого как JourneyWeb или Delfi Protocol. К движку планирования поездок могут обращаться различные внешние интерфейсы, используя программный протокол или интерфейс прикладной программы, специализированный для запросов поездок, чтобы предоставить пользовательский интерфейс на различных типах устройств.
Разработка систем планирования поездок шла рука об руку с разработкой стандартов данных для представления остановок, маршрутов и расписаний сети, таких как TransXChange , NaPTAN , Transmodel или GTFS , которые гарантируют, что они соответствуют друг другу. Алгоритмы планирования поездок являются классическим примером проблем в области теории вычислительной сложности . Реализации в реальном мире предполагают компромисс вычислительных ресурсов между точностью, полнотой ответа и временем, необходимым для расчета. [4]
Подзадача планирования маршрута является более простой для решения [28] , поскольку она обычно включает в себя меньше данных и меньше ограничений. Однако с разработкой «дорожных расписаний», связывающих разное время в пути для дорожных соединений в разное время суток, время в пути становится все более важным и для планировщиков маршрутов.
Планировщики поездок используют алгоритм маршрутизации для поиска в графе, представляющем транспортную сеть. В простейшем случае, когда маршрутизация не зависит от времени, граф использует (направленные) ребра для представления сегментов улиц/путей и узлы для представления перекрестков . Маршрутизация на таком графе может быть эффективно выполнена с использованием любого из ряда алгоритмов маршрутизации, таких как алгоритм Дейкстры , A* , Флойда–Уоршалла или Джонсона . [29] Различные веса, такие как расстояние, стоимость или доступность, могут быть связаны с каждым ребром, а иногда и с узлами.
При включении зависящих от времени характеристик, таких как общественный транспорт, существует несколько предложенных способов представления транспортной сети в виде графика, и могут использоваться различные алгоритмы, такие как RAPTOR [30]
Автоматизированные планировщики поездок автоматически генерируют ваш маршрут на основе предоставленной вами информации. Один из способов — указать желаемое место назначения, даты вашей поездки и интересы, и план будет создан через некоторое время. Другой способ — предоставить необходимую информацию, пересылая письма с подтверждением от авиакомпаний , отелей и компаний по прокату автомобилей. [31]
С помощью пользовательского планировщика поездок пользователь создает свой собственный маршрут путешествия индивидуально, выбирая соответствующие мероприятия из базы данных. Некоторые из этих веб-сайтов, такие как Triphobo.com, предлагают готовые базы данных точек интереса, в то время как другие полагаются на контент, созданный пользователями .
В 2017 году Google выпустила мобильное приложение под названием Google Trips. [32] Стартапы по индивидуальному планированию поездок вновь стали пользоваться интересом инвесторов с появлением науки о данных, искусственного интеллекта и голосовых технологий в 2018 году. Lola.com , стартап по планированию путешествий на основе искусственного интеллекта, и Hopper.com сумели привлечь значительное финансирование для разработки приложений по планированию поездок. [33] [34]
Когда бронирования и платежи добавляются в мобильное приложение для планирования поездок, то результат считается мобильностью как услугой .
Дистрибьюторские компании могут включать программное обеспечение для планирования маршрутов в свои системы управления автопарком , чтобы оптимизировать эффективность маршрутов. Настройка планирования маршрутов для дистрибьюторских компаний часто включает возможность отслеживания по GPS и расширенные функции отчетности, которые позволяют диспетчерам предотвращать незапланированные остановки, сокращать пробег и планировать более экономичные маршруты.