Loading article…
旅程プランナー、旅行プランナー、またはルートプランナーは、2 つ以上の指定された場所の間を移動する最適な手段を見つけるために使用される特殊な検索エンジンであり、場合によっては複数の交通手段を使用します。[ 1 ] [ 2 ]検索は、たとえば最速、最短、乗り換えの最小、最安など、さまざまな基準で最適化できます。[ 3 ]特定の時間に出発または到着する、特定の経由地を避けるなど、制約を設けることもできます。 1 つの旅程で複数の交通手段のシーケンスを使用する可能性があるため、システムは公共交通機関のサービスだけでなく、自家用車の交通ネットワークについても認識している場合があります。
旅行計画または旅程計画は、ルート計画[4]とは区別されることがあります。ルート計画は通常、自転車、自動車、徒歩などの私的な交通手段を使用し、通常は一度に1つの手段を使用することと考えられています。一方、旅行計画または旅程計画では、公開された時刻表に従って運行する少なくとも1つの公共交通機関を利用します。公共交通機関は特定の時間にのみ出発するため（いつでも出発できる私的な交通機関とは異なり）、アルゴリズムは目的地までの経路を見つけるだけでなく、各区間で発生する待ち時間を最小限に抑えるように最適化する必要があります。Transmodelなどの欧州規格では、旅行計画は、乗客のルートを計画するために具体的に使用され、そのような旅行が行われる公共交通機関の車両が行う運行旅行を計画するまったく別のプロセスとの混同を避けています。
旅行プランナーは、1970年代から予約代理店によって旅行業界で広く使用されてきました。 [ 5 ]インターネットの普及、地理空間データの普及、および情報技術全般の発展により、セルフサービスアプリやブラウザベースのオンライン複合交通プランナーが急速に開発されました。
旅行プランナーは、チケット発券システムや予約システムと併用して使用できます。例えば、旅行計画技術の最大の単一用途は、英国の鉄道予約システムで使用されており、RTJP（リアルタイム旅行プランナー）と呼ばれることが多く、2 地点または複数の地点間のデータを処理します。これは、ナショナル レールの公式ウェブサイトで確認できます。[ 6 ]
1980年代後半から1990年代初頭にかけて、一部の国営鉄道会社や主要都市交通局は、顧客問い合わせサービスを支援するために独自の専用旅行プランナーを開発した。これらのプランナーは通常メインフレーム上で稼働し、顧客情報センター、コールセンター、切符売り場などの社内スタッフが端末からアクセスして顧客からの問い合わせに対応していた。データは、印刷された時刻表の発行や運行管理に使用される時刻表データベースから取得され、一部のプランナーには簡単な経路検索機能も含まれていた。 1989年にドイツの企業[ 7 ] Hacon（現在はシーメンスAGの一部）によって開発されたHAFAs時刻表情報システムは、そのようなシステムの一例であり、 1989年にスイス連邦鉄道（SBB）とドイツ鉄道に採用されました。オンラインプランナーの開発以前に使用されていたロンドン交通局（現在のTfL ）の「Routes」システムは、ロンドンのすべての公共交通サービスを網羅しており、メインフレームOLTPの旅程プランナーのもう1つの例であり、ロンドンの観光名所や人気の目的地の大規模なデータベースが含まれていました。
1990 年代には、旅行計画を実行するのに十分なメモリとプロセッサパワーを備えたパーソナル コンピュータが登場し (メモリとプロセッサの要件の観点から計算コストが比較的高い)、ミニ コンピュータやパーソナル コンピュータにインストールして実行できるシステムが開発されました。マイクロ コンピュータ用の最初のデジタル公共交通旅行プランナー システムは、アムステルダム大学の情報科学の学生であった Eduard Tulp によってAtari PC 上で開発されました。[ 8 ]彼はオランダ鉄道に雇われ、列車の運行用のデジタル旅行プランナーを構築しました。1990 年に、オランダ鉄道向けの最初のデジタル旅行プランナー (フロッピー ディスク) が、オフラインで参照するために PC やコンピュータにインストールできるように販売されました。[ 9 ]彼のソフトウェア プログラムの原理は、1991 年にオランダの大学の論文で発表されました。[ 10 ]これはすぐにオランダのすべての公共交通機関を含むように拡張されました。
もう一人先駆者はスイスのハンス＝ヤコブ・トブラーでした。彼の製品であるFinajourはPC DOSとMS-DOSで動作し、スイス初の電子時刻表でした。最初の公開版は1989/1990年の時刻表期間向けに販売されました。[ 11 ] [ 12 ] [ 13 ]他のヨーロッパ諸国もすぐに独自の旅行プランナーで追随しました。
この傾向のさらなる発展として、旅行プランナーをモバイルデバイスなどのさらに小さなプラットフォームに展開する動きが見られました。1998年には、 HafasのWindows CE版がリリースされ、アプリケーションとドイツ鉄道の時刻表全体を6メガバイトに圧縮し、スタンドアロンアプリケーションとして動作するようになりました。
インターネットの発展により、HTMLベースのユーザーインターフェースが追加され、一般の人々が旅行計画システムに直接問い合わせることができるようになった。HaFAsのテストWebインターフェースは、 1995年にドイツ鉄道の公式鉄道旅行プランナーとして公開され、時を経てドイツ鉄道のメインWebサイトへと発展した。2001年、ロンドン交通局は、ロンドンのすべての交通モードとロンドンへの鉄道ルートを網羅する、世界都市向けの世界初の大規模マルチモーダル旅行プランナーを公開した。これは、1990 年代後半に TfL 独自のメインフレーム内部旅行プランナーに Web インターフェースを追加しようと試みたものの、拡張性に失敗したため、ミュンヘンの Mentz GmbH が開発しました。国鉄や大都市などの主要交通ネットワーク向けのインターネット旅行プランナーは、非常に高いクエリレートを維持する必要があり、そのため、そのようなトラフィックを維持するように最適化されたソフトウェア アーキテクチャが必要です。世界初の大都市圏向けモバイル旅行プランナーは、Mentz エンジンを使用したロンドンへの WAP ベースのインターフェースで、2001 年にロンドンのスタートアップ企業 Kizoom Ltd によってリリースされました。同社はまた、2000 年に英国初のモバイル インターネット向け鉄道旅行プランナーを WAP サービスとしてリリースし、その後 SMS サービスもリリースしました。2000 年より Traveline [ 14 ]サービスは、英国全土でバス、コーチ、鉄道の地域マルチモーダル旅行プランニングを提供しました。英国の鉄道向け Web ベースの旅行プランナーは、2003 年に UK National Rail Enquiriesによってリリースされました。
初期の公共交通機関の経路検索アプリでは、通常、終点として停留所または駅を指定する必要がありました。また、観光名所やその他の人気スポットの名前を入力できるアプリもあり、目的地に最も近い停留所の一覧表が用意されていました。その後、住所や座標を追加できる機能が追加され、真の意味での地点間経路検索が可能になりました。
1990年代後半から2000年代初頭にかけて、大規模な複合交通手段による旅行計画の開発において重要だったのは、多くの異なる事業者からの停留所と時刻表データのエンコードに関する標準規格を並行して開発し、データを定期的に集約・配信するためのワークフローを確立することだった。これは、バスや長距離バスのように、多数の小規模事業者が存在する交通手段では、鉄道のように、ネットワークを運用するための交換フォーマットやプロセスが既に確立されている少数の大規模事業者しか関与しない交通手段よりも、より困難な課題である。高度で複雑な公共交通ネットワークを有するヨーロッパでは、国内および国際的に標準フォーマットを作成・調和させるプロセスを支援するために、公共交通機関向けのCEN Transmodel参照モデルが開発された。
2000年代には、いくつかの主要プロジェクトで分散型旅行計画アーキテクチャが開発され、それぞれが特定の地域をカバーする個別の旅行計画システムを統合して、非常に広い地域をカバーする複合エンジンを作成することが可能になった。
公共交通機関の旅行プランナーは非常に人気が高く（例えば、2005 年までにドイツ鉄道は1 日あたり 280 万件のリクエストを既に処理しており[ 7 ]、旅行プランニングサイトは、そのようなサイトがあるすべての国で最もトラフィックの多い情報サイトの一つとなっています。見つけた旅行のチケットを購入できる機能は、サイトの利便性と人気をさらに高めました。英国の Trainline のような初期の実装では、チケットを郵送で提供していました。これは、ほとんどのヨーロッパ諸国で、セルフサービスによる印刷とモバイルによる履行方法によって補完されています。インターネットの旅行プランナーは現在、ほとんどの鉄道および航空輸送事業者にとって主要な販売チャネルとなっています。
Google は2005 年に Google Transit のバージョンで製品セットに旅行計画機能を追加し始めました。これは、TriMet の代理店マネージャー [ 18 ] Bibiana McHugh が説明したように、ポートランド地域の旅行を対象としていました。これが、旅行プランナーで使用するために公共交通データを収集するフォーマットである General Transit Feed Specification (GTFS) の開発につながり、多くの異なる国をカバーするPT データフィードのエコシステムの開発に大きな影響を与えました。多くの国の大手事業者が利用可能な出力フォーマットとして GTFS をうまく採用したことで、Google は旅行プランナーのカバー範囲を世界中のより多くの地域に拡大することができました。Google Transit の旅行計画機能は、2012 年に Google マップ製品に統合されました。
旅行計画エンジンのさらなる進化により、リアルタイムデータが統合され、直近の旅行計画にリアルタイムの遅延や運行障害が反映されるようになりました。英国国鉄（National Rail Enquiries）は2007年に鉄道旅行計画システムにリアルタイム機能を追加しました。また、運行障害通知、混雑状況、CO2排出量など、他の種類のデータを旅行計画結果に統合することも重要です。ロンドン交通局（Transport for London）の旅行計画システムなど、一部の大都市の旅行計画システムは、個々の駅や路線全体を動的に停止させる機能を備えており、大規模な運行障害発生時に、利用できない区間を除外した修正された旅行計画を作成できます。さらに、アクセシビリティデータの追加や、車椅子でのアクセスなど、特定の障害を持つ人々のニーズを考慮して計画を最適化するアルゴリズム機能も開発されました。
2012年ロンドンオリンピックに向けて、改良されたロンドン旅行プランナーが作成されました。これにより、提案された旅行結果が、さまざまなルートの利用可能な容量を管理し、交通量を混雑の少ないルートに分散させるように調整できるようになりました。もう一つの革新的な点は、すべてのオリンピック会場への出入り口（公共交通機関の停留所から各競技場の入り口まで）を詳細にモデル化し、セキュリティチェックやその他の遅延を考慮した予測待ち時間と実際の待ち時間を推奨移動時間に反映させたことです。
オープンソースの旅行プランナーである OpenTripPlanner [ 19 ]を開発するイニシアチブは、 2009 年に オレゴン州ポートランドの交通機関TriMetによって開始され、米国とヨーロッパの機関や事業者の参加を得て開発されました。2016 年 9 月にリリースされた完全版 1.0 により、小規模な交通機関や事業者が独自のライセンス料を支払うことなく旅行計画を提供できるようになりました。
公共交通機関ルートプランナーは、利用可能な公共交通機関の情報を提供する、ウェブ経由でアクセスする複合交通機関ルートプランナーです。このアプリケーションは、ユーザーに出発地と目的地を入力するよう促し、アルゴリズムを使用して両者間の最適な公共交通機関ルートを検索します。移動時間は出発時刻または到着時刻のいずれかに制限することができ、その他のルート設定も指定できます。
複合交通プランナーは、自転車、公共交通機関、バス、フェリーなど、複数の交通手段を組み合わせた複合交通旅行をサポートします。多くのルートプランナーはドアツードアのプランニングをサポートしていますが、駅、空港、バス停など、交通ネットワーク上の停留所間のみを機能させるものもあります。
公共交通機関の経路検索では、旅行プランナーは到着時刻または出発時刻によって制約されます。また、最短ルート、乗り換え回数の最小化、アクセスの良さなど、さまざまな最適化基準をサポートする場合もあります。価格による最適化（最安値、最も柔軟な運賃など）は通常、別のアルゴリズムまたはエンジンによって行われますが、検索結果の運賃を返すことができる旅行プランナーは、価格や商品タイプによる結果の並べ替えやフィルタリングを提供する場合もあります。価格が重要な要素となる長距離鉄道や航空旅行の計画では、旅行プランナーは、旅行時間に柔軟性のある顧客に対して、最も安い旅行日を提案する場合があります。
道路区間の計画は、旅程プランナー内の別のサブシステムによって行われることもありますが、単一モードの旅行計算と複合モードのシナリオ (パークアンドライド、キスアンドライドなど) の両方を考慮する場合があります。自動車のルーティングの典型的な最適化は、最短ルート、最速ルート、最安ルート、および特定のウェイポイントの制約付きルートです。eモビリティの台頭は、ルート計画に新たな課題をもたらしています。たとえば、まばらな充電インフラ、限られた航続距離、長い充電を考慮する必要があり、最適化の余地があります。[ 20 ]一部の高度な旅程プランナーは、道路区間の平均移動時間、または道路区間のリアルタイム予測平均移動時間を考慮に入れることができます。
理想的な経路検索ツールは、停留所、駅、観光スポットなどへの歩行者アクセスに関する詳細なルートを提供します。これには、「段差なし」、「車椅子対応」、「エレベーターなし」など、さまざまな利用者のアクセシビリティ要件を考慮したオプションが含まれます。
一部の経路計画システムは自転車ルートを計算できます[ 21 ]。自転車でアクセス可能なすべての経路を統合し、地形、交通状況、路上自転車インフラなどの追加情報も含まれることがよくあります。これらのシステムは、静かで安全な道路、最小限の標高変化、自転車レーンなどの好みを想定するか、ユーザーが指定できるようにします。
旅行プランナーは様々な種類のデータに依存しており、そのデータの質と量によって機能が制限されます。旅行プランナーの中には、多数の情報源から様々な種類のデータを統合するものもあれば、空港間のフライトスケジュールなど、単一のモードのみで動作するものや、運転ルート案内に住所と道路網のみを使用するものもあります。
乗客は特定の駅や停留所に行きたいから旅行するのではなく、スポーツアリーナ、観光名所、ショッピングセンター、公園、裁判所など、興味のある目的地に行きたいから旅行します。多くの旅行プランナーでは、ユーザーが名前またはカテゴリ（博物館、スタジアム、刑務所など）でそのような「興味のある地点」を検索できます。体系的に命名され、ジオコーディングされ、カテゴリ分けされた人気の目的地のデータセットは、たとえば英国の PointX [ 22 ]データセットのように市販で入手することも、 OpenStreetMapなどのオープンソースのデータセットから派生させることもできます。ロンドン交通局やナショナル レールなどの大手事業者は、これまで顧客コールセンターで使用するために、最寄りの停留所へのリンク情報とともに、このようなデータセットを十分に開発してきました。公園、カントリーハウス、スタジアムなど、広い範囲をカバーする興味のある地点については、入口の正確なジオコーディングが重要です。
旅行計画のユーザーインターフェースは、地名辞典データを統合することで、より使いやすくなります。これは、特に停留所の検索を支援するために停留所と関連付けることができます。たとえば、曖昧さを解消するためです。米国にはニューポートという名前の場所が33か所、英国には14か所あります。地名辞典を使用すると、どちらがどちらであるかを区別したり、場合によっては、交通機関の乗り換え地点と乗客が目指す町や都市中心部との関係を示すことができます。たとえば、ロンドンにある約5つの空港のうち、実際にロンドンにあるのは1つだけです。この目的のためのデータは通常、Esri、Ordnance Survey、Navtechなどが提供する地図データセットの追加レイヤー、または英国公共交通機関地名辞典などの特定のデータセットから取得されます。
道路旅行プランナー（ルートプランナーとも呼ばれる）は、道路や歩道のネットワークデータを使用して、ネットワークの接続性のみに基づいてルートを計算します（つまり、旅行はいつでも実行でき、時刻表に制約されません）。このようなデータは、TIGER、Esri、OpenStreetMapなどの1つ以上の公開、商用、またはクラウドソーシングされたデータセットから取得できます。このデータは、公共交通機関の停留所に到達するためのアクセス区間を計算するため、および道路旅行自体を計算するために不可欠です。基本的な表現は、ノードとエッジ（つまり、ポイントとリンク）のグラフです。データには、さまざまなモードの旅行計画を支援するために、さらに注釈が付けられる場合があります。
高度な道路ルートプランナーは、ネットワークのリアルタイムの状態を考慮に入れています。そのために、Datex IIやUTMCなどのインターフェースを介して道路データサービスから取得される、主に2種類のデータフィードを使用します。
公共交通機関の経路計画システムが機能するためには、運行スケジュールデータが常に最新の状態に保たれている必要があります。異なる経路計画システム間でのデータ交換と相互運用性を促進するために、いくつかの標準データ形式が登場しました。
2006年に開発された一般交通フィード仕様[ 18 ]は、現在世界中の数百の交通機関で使用されています。
欧州連合では、すべての公共旅客輸送事業者は、EU鉄道時刻表データ交換フォーマットに基づいて情報を提供する義務がある。[ 23 ] [ 24 ] [ 25 ]世界の他の地域にも同様の交換基準がある。[ 26 ]
バス、路面電車、長距離バスの停留所、駅、空港、フェリー乗り場、港などの公共交通機関のアクセスポイントの位置と識別情報は、旅行計画の基本であり、停留所データセットは交通データインフラストラクチャの重要なレイヤーです。停留所を空間検索や道路経路検索エンジンと統合するために、ジオコーディングが行われます。時刻表や経路と統合するために、交通ネットワーク内で一意の識別子が割り当てられます。乗客が認識できるように、停留所には正式名称が付けられ、インターフェースで使用するための公開ショートコード（たとえば、空港の3文字のIATAコード）が付けられる場合もあります。従来、異なる事業者が同じ停留所に対して異なる識別子を使用することがよくあり、停留所番号は国や地域内でも一意ではありませんでした。国際鉄道連合（UIC）の駅位置コードセットや英国のNaPTAN（National Public Transport Access Point）停留所番号システムなどの停留所データ管理システムは、番号の一意性と停留所の完全な記述を保証する手段を提供し、データの統合を大幅に容易にします。GTFS、TransXChange、NeTExなどの時刻表交換フォーマットには停留所データが含まれており、 OpenStreetMapなどの空間データセットでは停留所識別子をジオコーディングすることができます。
都市圏や都心バスサービスなど、運行頻度が非常に高い公共交通ネットワークでは、特定の出発時刻ではなく平均間隔を仮定することで、ネットワークのトポロジーを経路計画に利用することもできます。列車やバスのルートに関するデータは、例えば地図上に列車のルートをプロットするなど、結果を視覚化するためにも役立ちます。英国のOrdnance Surveyなどの国の地図作成機関は、通常、データセットに交通レイヤーを含めており、欧州のINSPIREフレームワークは、戦略的デジタルデータセットに公共交通インフラリンクを含めています。CEN NeTExフォーマットでは、交通インフラの物理レイヤー（道路や鉄道の線路インフラリンクなど）と論理レイヤー（特定の路線上の予定された停車地点間のリンクなど）の両方を交換できます。
英国では、オンライン旅程プランナー（OJP）は、ナショナルレールがルートを計画し、運賃を計算し、チケットの空き状況を確認するために使用するエンジンです。OJPは、シルバーレールのIPTIS（統合旅客輸送情報システム）として知られる計画エンジンからルート情報を取得します。ナショナルレールのウェブサイトでは、企業がオンラインデータフィードのXMLファイルを介してこのデータに直接アクセスする方法に関する情報を提供しています。[ 27 ]しかし、OJPは2023年に停止され、現在nationalrail.co.ukに統合されている新しい旅程プランナーが採用されました。
公共交通機関の時刻表データは、旅行プランナーが特定の時間に利用可能な移動手段を決定するために使用されます。歴史的に、鉄道データは国内フォーマットで広く利用可能であり、多くの国では、VDV 452 (ドイツ)、TransXChange (英国)、Neptune (フランス) などの国内フォーマットでバスやその他の交通手段のデータも提供されています。時刻表データは、GTFSやNeTExなどの国際フォーマットでもますます利用可能になっています。ルートを地図上に投影できるようにするために、GTFS では単純な形状のプロットを指定できます。一方、 CEN NeTExやTransXChangeなどのTransmodelベースの標準では、構成要素のリンクを認識し、複数の異なる意味レイヤーを区別できる、より詳細な表現も可能です。[ 1 ]
旅行プランナーは、リアルタイム情報をデータベースに組み込み、近い将来の最適な旅行ルートの選択にそれを考慮に入れることができる。自動車両位置情報（AVL）システム[ 2 ]は、 GPSシステムを使用して車両の位置を監視し、リアルタイム情報と予測情報を旅行計画システムに渡すことができる。[ 1 ]旅行プランナーは、リアルタイム情報用のCENサービスインターフェースなどのリアルタイムインターフェースを使用してこのデータを取得することができる。
状況とは、輸送ネットワークに影響を与えている、または影響を与える可能性のある事象や出来事をソフトウェア上で表現したものです。旅行プランナーは状況情報を統合し、それを利用して旅行計画の計算を修正したり、テキストと地図の両方でユーザーに情報を提供するように応答に注釈を付けたりすることができます。旅行プランナーは通常、SIRI、TPEG、Datex IIなどの標準インターフェースを使用して状況情報を取得します。
事故は、さまざまな事業者や関係者（例えば、運輸事業者の管制室、放送局、緊急サービス機関など）によって、事故記録システム（ICS）を通じて記録されます。テキスト情報と画像情報は、運行結果と組み合わせることができます。最近の事故は、経路設定に反映されるだけでなく、インタラクティブマップ上で視覚化することも可能です。
一般的に、経路プランナーは、ネットワークと時刻表を効率的にメモリ上に表現することで、多数の経路を高速に検索できるようにします。経路計算に必要なノード数が少ない場合や、経路に関連する補助情報にアクセスする必要がある場合は、データベースクエリを使用することもできます。単一のエンジンに輸送ネットワーク全体とそのスケジュールを格納することも、JourneyWebやDelfi Protocolなどの分散経路計画プロトコルを使用して経路の分散計算を可能にすることもできます。経路計画エンジンには、経路クエリ専用のソフトウェアプロトコルまたはアプリケーションプログラミングインターフェースを使用して、さまざまなフロントエンドからアクセスでき、さまざまな種類のデバイスでユーザーインターフェースを提供できます。
旅程計画エンジンの開発は、ネットワークの停留所、経路、時刻表を表すためのデータ標準の開発と並行して進められてきました。これらの標準は、TransXChange、NaPTAN、Transmodel、GTFSなど、これらの標準が互いに整合するようにしています。旅程計画アルゴリズムは、計算複雑性理論の分野における問題の典型的な例です。実際の実装では、計算リソースの精度、回答の完全性、計算に必要な時間の間でトレードオフが発生します。[ 4 ]
経路計画のサブ問題は、一般的にデータが少なく制約も少ないため、解決しやすい問題です[ 28 ]。しかし、1日のさまざまな時間帯に道路リンクのさまざまな移動時間を関連付ける「道路時刻表」の開発により、移動時間は経路計画者にとってもますます重要になっています。
経路プランナーは、輸送ネットワークを表すグラフを検索するためにルーティングアルゴリズムを使用します。ルーティングが時間に依存しない最も単純なケースでは、グラフは（有向）エッジを使用して道路/経路セグメントを表し、ノードを使用して交差点を表します。このようなグラフでのルーティングは、ダイクストラ法、A*、フロイド-ウォーシャル法、ジョンソン法などの多数のルーティングアルゴリズムのいずれかを使用して効果的に実行できます。[ 29 ]距離、コスト、アクセシビリティなどの異なる重みが各エッジに関連付けられる場合があり、場合によってはノードにも関連付けられます。
公共交通機関などの時間依存の要素が含まれる場合、輸送ネットワークをグラフとして表現する方法がいくつか提案されており、RAPTOR [ 30 ]などのさまざまなアルゴリズムが使用される可能性があります。
自動旅行プランナーは、提供された情報に基づいて旅程を自動的に生成します。1つの方法は、希望の目的地、旅行の日付、興味のあることを入力すると、しばらくするとプランが作成されます。もう1つの方法は、航空会社、ホテル、レンタカー会社からの確認メールを転送して必要な情報を提供することです。 [ 31 ]
カスタム旅行プランナーでは、ユーザーはデータベースから適切なアクティビティを選択することで、独自の旅行プランを個別に作成できます。Triphobo.comのようなウェブサイトの中には、あらかじめ構築された観光スポットのデータベースを提供しているものもあれば、ユーザーが作成したコンテンツに依存しているものもあります。CoMapsなど、コミュニティによって開発されたモバイル向け旅行プランナーの多くは、 OpenStreetMapからダウンロードした地図からルートプランを作成し、オフラインで使用しています。
2017年、GoogleはGoogle Tripsというモバイルアプリをリリースしました。[ 32 ] 2018年、データサイエンス、AI、音声技術の登場により、カスタム旅行プランニングのスタートアップは投資家から再び注目を集めています。AIベースの旅行プランニングスタートアップであるLola.comとHopper.comは、旅行プランニングアプリの開発のために多額の資金を調達することに成功しました。[ 33 ] [ 34 ]
モバイル旅行プランナーアプリに予約と支払い機能が追加されると、それはモビリティ・アズ・ア・サービスとみなされる。
多くの配送・物流企業は、業務効率向上のため、車両管理システムの一部としてルートプランニングソフトウェアを利用しています。これらのシステムは、 GPS追跡機能やテレマティクス機能を統合していることが多く、配車担当者は車両をリアルタイムで監視し、レポートツールでパフォーマンスを分析し、必要に応じてルートを調整することができます。その主な目的は、走行距離とアイドリング時間の削減、燃料消費量の削減、配送信頼性の向上などです。