旅程プランナー

旅程プランナー、旅行プランナー、またはルートプランナーは、2つ以上の特定の場所の間を移動する最適な手段を見つけるために使用される特殊な検索エンジンであり、複数の交通手段が使用されることもあります。^{[1] [2]検索は、}最速、最短、乗り換えが少ない、最安など、さまざまな基準で最適化される場合があります。^[3]検索には、特定の時間に出発または到着すること、特定のウェイポイントを回避することなどの制約が課される場合があります。 1回の旅程で複数の交通手段のシーケンスが使用される場合があり、これはシステムが公共交通機関のサービスだけでなく、個人の交通手段のための交通ネットワークについても認識している可能性があることを意味します。 旅行計画または旅程計画は、ルート計画とは区別されることがあります。 ^{[4]ルート計画は通常、一度に1つのモードを使用する、}自転車、車、徒歩などの個人の交通手段を使用するものと考えられています。対照的に、旅行または旅程計画では、公開されたスケジュールに従って運行する少なくとも1つの公共交通機関を利用します。公共交通機関は特定の時間にしか出発しないため（いつでも出発できる民間の交通機関とは異なり）、アルゴリズムは目的地までの経路を見つけるだけでなく、各区間で発生する待ち時間を最小限に抑えるように最適化する必要があります。Transmodel などの欧州規格では、旅行計画は、乗客のルート計画を説明するために特に使用され、そのような旅行が行われる公共交通機関の車両による運用上の旅程を計画するという完全に別のプロセスとの混同を避けています。

旅行プランナーは、1970年代から旅行代理店によって旅行業界で広く使用されてきました。 ^[5]インターネットの成長、地理空間データの急増、情報技術の発展により、多くのセルフサービスアプリやブラウザベースのオンライン複合旅行プランナーが急速に開発されました。

旅行プランナーは、チケット発行システムや予約システムと組み合わせて使用​​できます。

1980 年代後半から 1990 年代前半にかけて、一部の国営鉄道会社と大都市圏の交通当局は、顧客問い合わせサービスをサポートするために独自の専用旅行プランナーを開発しました。これらは通常、メインフレームで実行され、顧客情報センター、コール センター、チケット カウンターのスタッフが端末を使用して内部的にアクセスし、顧客の問い合わせに回答しました。データは、印刷された時刻表の発行や運用管理に使用される時刻表データベースから取得され、簡単なルート プランニング機能を備えたものもありました。 1989年にドイツの会社^[6] Hacon（現在はSiemens AGの傘下）によって開発されたHAFAs時刻表情報システムは、そのようなシステムの一例であり、 1989年にスイス連邦鉄道（SBB）とドイツ鉄道によって採用されました。オンラインプランナーの開発前に使用されていたロンドン交通局（現在はTfL）の「ルート」システムは、ロンドンのすべての公共交通機関をカバーしており、メインフレームOLTP旅程プランナーのもう1つの例であり、ロンドンの観光名所や人気スポットの大規模なデータベースを含んでいました。

1990 年代には、旅行計画 (メモリとプロセッサの要件の点で計算的には比較的高価) を実行するのに十分なメモリとプロセッサ パワーを備えたパーソナル コンピュータの出現により、ミニコンピュータとパーソナル コンピュータにインストールして実行できるシステムが開発されました。マイクロコンピュータ用の最初のデジタル公共交通機関旅行プランナー システムは、アムステルダム大学の情報工学の学生であった Eduard Tulp によってAtari PC で開発されました。^{[7]彼は、列車サービス用のデジタル旅行プランナーを構築するため、}オランダ鉄道に雇われました。1990 年に、オランダ鉄道向けの最初のデジタル旅行プランナー (ディスケット) が、オフライン参照用に PC やコンピュータにインストールするために販売されました。^[8]彼のソフトウェア プログラムの原理は、1991 年にオランダの大学の論文で発表されました。 ^[9]これはすぐにオランダのすべての公共交通機関に拡大されました。

もう一人の先駆者はスイスのハンス・ヤコブ・トブラーです。彼の製品であるFinajourは、PC DOSとMS-DOSで動作し、スイス初の電子時刻表でした。最初の出版版は、1989/1990年の時刻表期間用に販売されました。^{[10] [11] [12]}他のヨーロッパ諸国もすぐに独自の旅程プランナーを発売しました。

この傾向はさらに発展し、モバイル デバイスなどのさらに小さなプラットフォームに旅行プランナーを展開するようになりました。1998 年には、アプリケーションとドイツ鉄道の鉄道時刻表全体を 6 メガバイトに圧縮し、スタンドアロン アプリケーションとして実行する Hafas の Windows CEバージョンがリリースされました。

インターネットの発達により、HTML ベースのユーザー インターフェイスを追加して、一般の人が旅行計画システムを直接照会できるようになりました。HaFA のテスト Web インターフェイスは、 1995 年にドイツ鉄道の公式鉄道旅行プランナーとして開始され、時間の経過とともにドイツ鉄道のメイン Web サイトへと進化しました。2001 年にロンドン交通局は、ロンドンへの鉄道ルートだけでなくロンドンのすべての交通モードをカバーする世界初の大規模なマルチモーダル旅行プランナーを世界都市向けに開始しました。これには、1990 年代後半に TfL 独自のメインフレーム内部旅行プランナーに Web インターフェイスを追加する試みが失敗した後、ミュンヘンの [1] Mentz Gmbh] が提供する旅行計画エンジンが使用されました。国営鉄道や大都市などの主要な交通ネットワーク向けのインターネット旅行プランナーは、非常に高いクエリ レートを維持する必要があるため、そのようなトラフィックを維持できるように最適化されたソフトウェア アーキテクチャが必要です。大都市圏向けの世界初のモバイル旅行プランナーは、メンツエンジンを使用したロンドンへのWAPベースのインターフェースで、ロンドンの新興企業であるKizoom Ltdによって2001年に開始されました。同社はまた、2000年に英国初のモバイルインターネット向け鉄道旅行プランナーをWAPサービスとして開始し、その後SMSサービスを開始しました。2000年からTraveline ^{[13]サービスは、英国全土にバス、長距離バス、鉄道の地域的なマルチモーダル旅行プランニングを提供しました。英国鉄道向けのウェブベースの旅行プランナーは、2003年に英国}国鉄問い合わせ局によって開始されました。

初期の公共交通機関の旅行プランナーでは、通常、終点として停留所または駅を指定する必要がありました。また、目的地に最も近い停留所の表を保持することで、観光名所やその他の人気のある目的地の名前の入力をサポートしているものもありました。これは後に、住所や座標を追加して、真のポイントツーポイントの計画を提供できるように拡張されました。

1990 年代後半から 2000 年代前半にかけての大規模なマルチモーダル旅行計画の策定に不可欠だったのは、多くの異なる運行会社からの停車駅とスケジュールのデータをエンコードするための標準規格の同時開発と、定期的にデータを集約して配信するためのワークフローの設定でした。これは、ネットワークを運用するために交換フォーマットとプロセスをすでに導入している少数の大規模運行会社が関与する鉄道よりも、多数の小規模運行会社が存在する傾向があるバスや長距離バスなどのモードではより困難です。高密度で洗練された公共交通ネットワークを持つヨーロッパでは、国内および国際的に標準フォーマットを作成し、調和させるプロセスをサポートするために、公共交通向け CENトランスモデル参照モデルが開発されました。

2000 年代には、いくつかの主要プロジェクトで分散旅行計画アーキテクチャが開発され、それぞれ特定のエリアをカバーする個別の旅行プランナーを統合して、非常に広いエリアをカバーする複合エンジンを作成できるようになりました。

• 2004 年に英国運輸省によって開始されたUK Transport Direct Portal は、 JourneyWebプロトコルを使用して、イングランド、スコットランド、ウェールズの 140 の地方運輸当局のデータをカバーする 8 つの個別の地域エンジンを 1 つの統合エンジンとしてリンクしました。このポータルは道路と公共交通機関の両方のプランナーを統合し、移動時間、 _CO2フットプリントなどのモード間の比較を可能にしました。
• ドイツのDelfi ^[14]プロジェクトは、ドイツの地域計画者を統合するために使用される分散型旅行計画アーキテクチャを開発し、2004年にプロトタイプとして立ち上げられました。インターフェースはドイツのTRIASプロジェクトによってさらに開発され、2017年に公開されたCEN標準[[ ^{[15] |分散型旅行計画のためのオープンAPI']] (CEN/TS 17118:2017)の開発につながりました。これは、JourneyWebとEU-Spiritの機能を組み込み、} SIRIプロトコルフレームワークとTransmodel参照モデルを利用して、旅行計画者に標準インターフェースを提供します。
• 欧州^[16] EUスピリットプロジェクトは、ヨーロッパのさまざまな地域間の長距離旅行プランナーを開発した。

公共交通機関の旅行プランナーは絶大な人気を博し（例えば、2005年までにドイツ鉄道は1日あたり280万件のリクエスト^[6]に対応しており）、旅行プランニングサイトは、サイトがあるすべての国で最もアクセス数の多い情報サイトのひとつとなっています。見つかった旅行のチケットを購入できる機能により、サイトの有用性と人気がさらに高まりました。英国のTrainlineなどの初期の実装では、チケットの郵送による配達が提供されていました。これは、ほとんどの欧州諸国でセルフサービスの印刷およびモバイルによるフルフィルメント方法によって補完されています。インターネットの旅行プランナーは現在、ほとんどの鉄道および航空輸送事業者にとって主要な販売チャネルとなっています。

Googleは、2005年にポートランド地域の旅行をカバーするGoogle Transitのバージョンで、製品セットに旅行計画機能を追加し始めました。これは、 TriMetの代理店マネージャー^[17] Bibiana McHughが説明したとおりです。これにより、 General Transit Feed Specifications （GTFS）が開発されました。これは、旅行計画で使用する交通データを収集するための形式であり、さまざまな国をカバーするPTデータフィードのエコシステムの開発に大きな影響を与えました。多くの国の大手事業者が利用可能な出力形式としてGTFSを採用したことで、Googleは旅行計画の対象範囲を世界中のさらに多くの地域に拡大することができました。Google Transitの旅行計画機能は、2012年にGoogleマップ製品に統合されました。

旅行計画エンジンのさらなる進化により、リアルタイム データが統合され、近い将来の旅行計画でリアルタイムの遅延や混乱が考慮されるようになりました。英国国鉄調査局は、 2007 年に鉄道旅行計画にリアルタイム機能を追加しました。また、混乱通知、混雑レベル、CO2 コストなど、他の種類のデータが旅行計画結果に統合されたことも重要です。_ロンドン交通局の旅行計画など、一部の大都市の旅行計画には、個々の駅や路線全体を動的に停止する機能があり、大規模な混乱時にはネットワークの利用不可部分を省略した変更済みの旅行計画が作成されます。もう 1 つの進歩は、アクセシビリティ データの追加と、車椅子でのアクセスなど、特定の障害の要件を考慮して計画を最適化するアルゴリズムの機能です。

2012 年ロンドン オリンピックでは、ロンドン旅行プランナーが強化され、提案された旅行結果を偏らせてさまざまなルートの利用可能な容量を管理し、交通が混雑していないルートに分散できるようになりました。もう 1 つの革新は、オリンピックの各会場への出入りのすべてのアクセス パス (公共交通機関の停留所から各アリーナの入口まで) を詳細にモデル化し、セキュリティ チェックやその他の遅延を考慮に入れて推奨移動時間に予測および実際の待ち時間を表示したことです。

オープンソースの旅行プランナーを開発する取り組みである^[18] OpenTripPlannerは、2009年にオレゴン州ポートランドの交通機関TriMetによって開始され、米国とヨーロッパの機関や運営者の参加を得て開発されました。2016年9月にリリースされたフルバージョン1.0では、小規模な交通機関や運営者が独自のライセンス料を支払うことなく旅行プランニングを提供できるようになっています。

公共交通ルート プランナーは、通常Web経由でアクセスされる複合旅行プランナーで、利用可能な公共交通サービスに関する情報を提供します。このアプリケーションは、ユーザーに出発地と目的地を入力するよう促し、その後、アルゴリズムを使用して、公共交通サービスで 2 つの地点間の最適なルートを検索します。移動時間は、出発または到着のいずれかの時刻に制限され、その他のルート設定も指定できます。

複合一貫輸送の旅程プランナーは、自転車、高速輸送、バス、フェリーなど、複数の輸送手段を使用する複合一貫輸送の旅程をサポートします。多くのルート プランナーはドアツードアの計画をサポートしますが、駅、空港、バス停など、輸送ネットワーク上の停留所間でのみ機能するプランナーもあります。

公共交通機関による経路指定の場合、旅行プランナーは到着時刻または出発時刻によって制約されます。また、さまざまな最適化基準(最速ルート、乗り換えが最も少ない、最もアクセスしやすいなど) をサポートする場合もあります。価格による最適化 (最も安い、最も柔軟な運賃など) は通常、別のアルゴリズムまたはエンジンによって行われますが、見つかった旅行の運賃を返すことができる旅行プランナーでは、価格や商品タイプによる結果の並べ替えやフィルタリングも提供される場合があります。価格が価格最適化の重要な考慮事項となる長距離鉄道および航空旅行の計画では、旅行時間に柔軟性がある顧客に対して、旅行するのに最も安い日付を旅行プランナーが提案する場合があります。

道路区間の計画は、旅程計画ツール内の別のサブシステムによって行われることもありますが、単一モードの旅行計算とインターモーダルシナリオ（パークアンドライド、キスアンドライドなど）の両方が考慮されることがあります。自動車ルートの一般的な最適化は、最短ルート、最速ルート、最安ルート、特定のウェイポイントの制約付きです。eモビリティの台頭により、ルート計画に新たな課題が生じています。たとえば、まばらな充電インフラ、限られた航続距離、長時間充電などを考慮し、最適化の余地を作る必要があります。^[19]一部の高度な旅程計画ツールでは、道路区間の平均移動時間や、道路区間の平均移動時間をリアルタイムで予測して考慮することができます。

理想的には、旅程プランナーは、停留所、駅、興味のある場所などへの歩行者アクセスの詳細なルートを提供します。これには、たとえば「階段なし」、「車椅子アクセス」、「エレベーターなし」など、さまざまなタイプのユーザーのアクセシビリティ要件を考慮するオプションが含まれます。

いくつかの旅程計画システムは自転車ルートを計算することができ、^{[20]自転車でアクセス可能なすべての経路を統合し、地形、交通、路上の自転車インフラなどの追加情報も含めることが多い。これらのシステムでは、静かな道路や安全な道路、標高差が最小限であること、}自転車レーンなどの 好みを前提としているか、ユーザーが指定できるようにしている。

旅行プランナーは、さまざまな種類のデータに依存しており、これらのデータの品質と範囲によって機能が制限されます。旅行プランナーの中には、多数のソースからさまざまな種類のデータを統合するものもあります。また、空港間のフライトの旅程など、1 つのモードのみで動作するものや、運転ルートに住所と街路網のみを使用するものもあります。

乗客が旅行するのは、特定の駅や停留所に行きたいからではなく、スポーツ競技場、観光地、ショッピングセンター、公園、裁判所などの興味のある目的地に行きたいからです。多くの旅行プランナーでは、ユーザーがそのような「興味のある場所」を名前またはカテゴリ（博物館、スタジアム、刑務所など）で検索できるようにしています。体系的に名前が付けられ、ジオコーディングされ、分類された人気の目的地のデータ セットは、たとえば UK PointX ^{[21]データ セットのように市販されているか、} OpenStreetMapなどのオープンソース データ セットから取得できます。ロンドン交通局やナショナル レールなどの大手事業者は、歴史的に、最寄りの停留所へのリンクに関する情報とともに、カスタマー コール センターで使用するために、そのようなデータのよく発達したセットを持っています。公園、カントリー ハウス、スタジアムなどの広いエリアをカバーする興味のある場所の場合、入口の正確なジオコーディングが重要です。

旅行計画のユーザー インターフェイスは、Gazetteerデータを統合することで、さらに使いやすくすることができます。このデータを停留所に関連付けると、たとえば曖昧さを解消するなど、停留所の検索に役立ちます。米国には Newport という名前の場所が 33 か所、英国には 14 か所あります。Gazetteer を使用すると、どの場所がどの場所であるかを区別できます。また、場合によっては、乗客が目指す町や都市中心部と交通機関の乗り換えの関係を示すこともできます。たとえば、ロンドンの 5 か所ほどの空港のうち、実際にロンドンにあるのは 1 か所だけです。この目的のためのデータは、通常、Esri、Ordnance Survey、Navtechなどが提供するマップ データ セットの追加レイヤー、または UK National Public Transport Gazetteerなどの特定のデータ セットから取得されます。

道路旅行プランナーは、ルートプランナーとも呼ばれ、道路と歩道のネットワークデータを使用して、ネットワークの接続性のみを使用してルートを計算します（つまり、旅行はいつでも実行でき、時刻表に制約されません）。このようなデータは、TIGER、Esri、OpenStreetMapなどの 1 つ以上の公開データセット、商用データセット、またはクラウドソーシングデータセットから取得できます。このデータは、公共交通機関の停留所に到達するためのアクセス区間を計算する場合と、道路旅行自体を計算する場合の両方で基礎となります。基本的な表現は、ノードとエッジ（つまり、ポイントとリンク）のグラフです。データには、さまざまなモードでの旅行計画を支援するためにさらに注釈が付けられる場合があります。

• 道路データは、道路の種類（高速道路、主要道路、副道路、線路など）、右左折制限、速度制限などのほか、さまざまな曜日（平日、週末、祝日など）のさまざまな時間帯の平均移動時間によって特徴付けられるため、正確な移動時間予測を提供できます。
• 自転車道路や自転車道のデータには、自転車ルート番号、交通量、路面、照明など、自転車利用者の使いやすさに影響する特性が注釈として付けられる場合があります。
• 歩道データには、階段、エレベーター、車椅子でのアクセス、スロープなどのアクセシビリティ特性や、安全性指標（照明、 CCTV 、ヘルプポイントなど）が注釈として付けられるため、アクセシビリティに制約のある旅行計画を計算できます。

高度な道路旅行プランナーは、ネットワークのリアルタイムの状態を考慮します。そのために、Datex IIやUTMCなどのインターフェースを使用して道路データ サービスから取得した 2 種類の主なフィードを使用します。

• 状況データは、ネットワークに関連付けることができる構造化された形式で、インシデント、イベント、計画されている道路工事を記述します。これは、現在のボトルネックやインシデントの場所を示すために、旅行計画や道路地図を装飾するために使用されます。
• リンク交通フローデータは、監視対象のネットワークの各リンクの現在のフローを定量的に測定します。これを使用して、予測される移動時間を計算する際に、実際の現在の状況を考慮に入れることができます。

交通ルート プランナーが機能するには、交通スケジュール データを常に最新の状態にしておく必要があります。異なる旅行プランナー間でのデータ交換と相互運用性を容易にするために、いくつかの標準データ形式が登場しています。

2006年に開発された一般交通フィード仕様^[22]は現在、世界中の何百もの交通機関で使用されています。

欧州連合では、すべての公共旅客旅行事業者は、EU鉄道時刻表データ交換フォーマットに従って情報を提供する義務がある。^{[23] [24] [25]}世界の他の地域でも同様の交換基準がある。^[26]

バス、路面電車、長距離バスの停留所、駅、空港、フェリー乗り場、港などの公共交通機関のアクセス ポイントの場所と ID は、旅行計画の基本であり、停留所データ セットは交通データ インフラストラクチャの重要なレイヤーです。停留所を空間検索や道路ルーティング エンジンと統合するために、停留所はジオコード化されます。停留所を時刻表やルートと統合するために、交通ネットワーク内で一意の識別子が与えられます。乗客が認識できるように、正式名称が与えられ、インターフェイスで使用するためのパブリック ショート コード (空港の 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 プロトコルなどの分散旅程計画プロトコルを使用して旅程を分散計算したりすることもできます。旅程計画エンジンには、旅程クエリ専用のソフトウェア プロトコルまたはアプリケーション プログラム インターフェイスを使用して、さまざまなフロント エンドからアクセスして、さまざまな種類のデバイスでユーザー インターフェイスを提供できます。

旅程計画エンジンの開発は、ネットワークの停車駅、ルート、時刻表を表すためのデータ標準の開発と並行して行われてきました。TransXChange 、NaPTAN、Transmodel、GTFSなど、これらが互いに適合することを保証します。旅程計画アルゴリズムは、計算複雑性理論の分野における問題の典型的な例です。実際の実装では、計算リソースの正確性、答えの完全性、計算に必要な時間の間でトレードオフが発生します。^[4]

ルート計画のサブ問題は、一般的にデータが少なく制約も少ないため、解決しやすい問題です^[28]。しかし、「道路時刻表」の開発により、一日の異なる時間帯の道路リンクの異なる移動時間が関連付けられるようになり、移動時間はルート計画者にとってもますます重要になっています。

旅行計画者は、ルーティング アルゴリズムを使用して、交通ネットワークを表すグラフを検索します。ルーティングが時間に依存しない最も単純なケースでは、グラフは (有向)エッジを使用して道路/パス セグメントを表し、ノードを使用して交差点を表します。このようなグラフでのルーティングは、ダイクストラ、A*、フロイド–ワーシャル、ジョンソンのアルゴリズムなど、いくつかのルーティング アルゴリズムのいずれかを使用して効果的に実行できます。 ^[29]距離、コスト、アクセス性などのさまざまな重み付けを各エッジに関連付けることができ、場合によってはノードにも関連付けることができます 。

公共交通機関などの時間依存の特徴が含まれる場合、交通ネットワークをグラフとして表現する方法がいくつか提案されており、RAPTOR ^{[30]などのさまざまなアルゴリズムが使用される可能性がある。}

自動旅行プランナーは、あなたが提供する情報に基づいて自動的に旅程を作成します。1つの方法は、希望する目的地、旅行の日付、興味のあるものを送信することです。しばらくすると計画が作成されます。別の方法は、航空会社、ホテル、レンタカー会社からの確認メールを転送して必要な情報を提供することです。 ^[31]

カスタム旅行プランナーを使用すると、ユーザーはデータベースから適切なアクティビティを選択して、独自の旅行計画を個別に作成できます。Triphobo.com などの一部の Web サイトでは、興味のある場所のデータベースがあらかじめ構築されていますが、他の Web サイトでは、ユーザーが作成したコンテンツに依存しています。

2017年、GoogleはGoogle Tripsというモバイルアプリをリリースしました。^[32]カスタム旅行プランニングのスタートアップは、2018年のデータサイエンス、AI、音声技術の登場により、投資家からの新たな関心を集めています。AIベースの旅行プランニングのスタートアップであるLola.comとHopper.comは、旅行プランニングアプリの開発のために多額の資金を調達することに成功しました。^{[33] [34]}

モバイル旅行プランナー アプリに予約と支払いが追加されると、その結果はサービスとしてのモビリティと見なされます。

配送会社は、ルート効率を最適化するために、車両管理システムにルート計画ソフトウェアを組み込むことがあります。配送会社のルート計画設定には、多くの場合、GPS 追跡機能と高度なレポート機能が含まれており、ディスパッチャは予定外の停止を防ぎ、走行距離を減らし、より燃料効率の高いルートを計画できます。

• 自動車ナビゲーションシステム
• インテリジェント交通システム
• 複合輸送
• 旅行や休暇のためのオンライン日記プランナー
• パスファインディング
• 公共交通機関のルートプランナー
• リアルタイム情報のためのサービスインターフェース
• テペグ
• トランスモデル
• 旅行技術
• 旅行ウェブサイト
• 公共交通機関の時刻表
• 持続可能な輸送
• 交通地区