交通情報モードを理解する
さまざまな交通状況を考慮してルート計画を調整すると、より効率的なナビゲーションが可能になります。HERE Tour Planning APIには4つの交通情報モード (liveOrHistorical、historicalOnly、automatic、disabled) があります。これらのモードでは、リアルタイムの交通量のデータ、過去の交通量のデータ、または交通量のデータがない場合に基づいてルート検索をカスタマイズでき、さまざまなユースケースやシナリオに対応できます。このチュートリアルでは各モードの意味とシナリオを掘り下げ、特定のニーズや好みに応じてルート計画を調整できるようにします。
交通情報モードを定義する
HERE Tour Planning APIで交通情報モードを定義するには、fleet.trafficパラメーターを使用します。このパラメーターを使用して、HERE Tour Planning APIで交通情報がどのように考慮されるかを指定できます。
次の交通情報モードのいずれかを指定できます。
automaticliveOrHistoricalhistoricalOnly
詳細については、「トラフィック」を参照してください。
最適化アルゴリズムがルート検索ソリューションを決定する際に交通情報を考慮しないようにするには、fleet.profiles.trafficをdisabledに設定します。
注
fleet.profiles.trafficを無効にすると、最適化アルゴリズムは交通状況を無視します。これは、各停車地間の最適な距離と所要時間を計算する場合や、停車地を訪れる順序を決定する場合に適用されます。これにより、最適化は交通状況以外の要因にのみ基づいて行われるようになります。
詳細については、「ルート検索プロファイル」を参照してください。
使用可能な交通情報モード
次の項では、HERE Tour Planning APIで使用可能な各交通情報モードの概要を示します。
liveOrHistorical
出発時間に基づいて、リアルタイムまたは過去の交通量のデータを考慮します。
車両プロファイルにある、オプションのdepartureTimeプロパティを使用して、特定の車両タイプの出発時間をカスタマイズできます。車両プロファイルの定義中にこのプロパティを省略すると、出発時間は、その特定のプロファイルに関連付けられているすべての車両タイプのうち、最も早いシフト開始時間に自動的にデフォルトで設定されます。
最適化アルゴリズムでは、出発時間を過去に指定したか未来に指定したかに応じて、後続の停車地間の距離と所要時間が異なる方法で計算されます。
-
現在の出発の場合:APIは出発が発生した特定の時点での、現在の交通状況を考慮します。
注
ルート検索問題の現在の出発時間を設定する場合は、次の設計原則と制限を考慮してください。
- リアルタイムの交通量のデータは、特定の瞬間における状況のスナップショットを提供します。ただし、たとえば1日のように長時間にわたる最適な移動距離と所要時間を計算する場合、リクエスト時間からかけ離れた交通状況は正確でない可能性があります。
- ルートの最初のルートを除くすべてのルートは後で通過されます。その後のルートを走行する頃には、交通状況がすでに変わっている可能性があります。
- 実際の交通状況を正確に考慮するため、出発時間を少し遅めに設定してください。これにより、潜在的なネットワークと処理の遅延、時間の不一致、交通量のデータのリアルタイム同期に影響を与える可能性のあるその他の要因が考慮されます。出発時刻を少し先に設定することで、ルート計算に反映される交通状況の信頼性を最大限に高めることができます。
-
今後の出発の場合:出発時間が未来の場合、APIは現在の時間と予定されている出発時間との間の時間差に基づいて、リアルタイムの交通量のデータと過去の交通量のデータのどちらを使用するかを決定します。出発がさらに未来に予定されている場合、APIがソリューションを計算する際に過去の交通量のデータに依存する可能性が高くなります。
-
過去の出発の場合:出発時間が過去に設定されている場合、最適化アルゴリズムでは特定の時点のリアルタイムの交通量のデータを使用せずに、時間間隔で集計された過去の交通量の傾向を反映します。
ユースケース
ルート検索シナリオに含まれるすべての場所が半径490 km以内にある場合は、liveOrHistorical交通情報モードを使用します。この設定を選択すると、特に指定された半径内の場所については、可能な限りリアルタイムの交通量のデータの使用が優先されます。
すべての場所の地理的範囲の合計が490 kmを超える場合、liveOrHistorical交通情報モードのリクエストは失敗します。失敗すると、問題に介入して適切に対応し、リクエストを再送信する機会が設けられます。たとえば、距離が離れすぎているジョブの場合、別の集配センターから割り当てたり、十分な運行管理リソースが利用可能になった後の段階で割り当てたりするなど、別の方法で処理できます。
注
別の方法として、HERE Tour Planning APIを使用して手動での介入をせずに各問題のリアルタイムの交通量のデータと過去の交通量のデータのバランスを自動的に調整する場合は、
automatic交通情報モードを使用します。
historicalOnly
この交通情報モードでは、最適化アルゴリズムは1日以上続く長期閉鎖を除き、時間依存の要因を考慮しません。そのため、このモードは出発時間や到着時間が事前に決まっていないルートを計画する際に便利です。
ユースケース
このモードは、リアルタイムのデータがルートに大きな影響を与えないと思われる都市間など、交通パターンが安定しているルートに最適です。たとえば、このモードは長距離輸送を伴うことが多く、潜在的にさまざまな地域を横断し、多様な交通状況に遭遇する可能性のある長距離配送のシナリオで有用です。このようなシナリオでは、過去の交通量のデータによって提供される安定性と予測可能性が重要になります。
また、リアルタイムの交通量のデータの使用を回避する場合にも、このモードが役立つ可能性があります。たとえば、朝の出発に向けて夜間に準備するなど、計画時のリアルタイムの交通量のデータはほとんど関係のない、かなり早い段階でルートを計画する場合に交通を無効にすることができます。
automatic
automatic問題座標の空間分布に基づいて、リアルタイムのデータと過去のデータを自動的に選択します。すべての場所が半径490 kmの円内に収まる場合、APIはリアルタイムの交通量のデータを使用します。それ以外の場合は過去のデータのみを使用します。問題のJSONで交通情報モードを明示的に指定しない場合、このモードがデフォルトになります。
ユースケース
このモードは、都市部と地方の両方にまたがるルートに適しており、サービスが最適なオプションを自動的に決定できます。
たとえば、この交通情報モードは、複雑なサプライチェーンネットワーク内で動的な都市物流と安定した地方配送のバランスを取ろうとしている小売業者に適しています。
disabled
disabledこのモードでは、ルート計画アルゴリズムは交通関連の情報を完全に無視し、長期閉鎖に関する情報を含むリアルタイムまたは過去の交通状況を考慮せずにルート提案を示します。
ヒント
交通条件を無効にするには、
fleet.profiles.trafficパラメーターを"disabled"に設定します。詳細については、「APIリファレンス」を参照してください。
ユースケース
この交通情報モードは、交通量のデータが限られているか信頼性が低いエリアや、到達可能性の制約などのために交通状況によって未割り当てのジョブが発生するようなソリューションを回避する場合に適しています。
たとえば、特に住宅街でのラストマイル配達のシナリオでは、交通障害を無効にすることで、ドライバーがその場で自由に意思決定を行うことができます。必要に応じて短い距離を歩くこともでき、最終配達先に効率的に到達できます。問題の実用的なデモンストレーションについては、「交通情報を無効にする」を参照してください。
サンプル問題
このセクションではHERE Tour Planning APIでの交通モード情報の選択がルート計画にどのように影響するかを示す実用的な例を示します。次の例では、リアルタイムの調整から過去データの分析まで、選択した交通情報モードが特定のユースケースのナビゲーションにどのように影響するかを説明します。
注
交通状況は常に変化するため、次の問題では一貫して同じソリューションを得られない可能性があります。
交通情報を無効にする
この例では、ルート検索の問題に交通情報モードを含めるか無効にするかによって、短距離のラストマイル配達シナリオでの結果ソリューションにどのような影響が及ぶかを示します。
サンプルルート検索問題を含む次のJSONスニペットを検討します。
Click to expand/collapse the sample JSON
{
"fleet": {
"types": [
{
"id": "A",
"profile": "Vehicle_A",
"costs": {
"fixed": 20,
"distance": 0.001,
"time": 0
},
"shifts": [
{
"start": {
"time": "2023-07-18T02:28:40-07:00",
"location": {
"lat": 48.833409,
"lng": 2.34858
}
}
}
],
"capacity": [
3
],
"amount": 5
}
],
"profiles": [
{
"name": "Vehicle_A",
"type": "car"
}
]
},
"plan": {
"jobs": [
{
"id": "Job_1",
"tasks": {
"deliveries": [
{
"places": [
{
"location": {
"lat": 48.826072,
"lng": 2.334607
},
"duration": 300
}
],
"demand": [
1
]
}
]
}
},
{
"id": "Job_2",
"tasks": {
"deliveries": [
{
"places": [
{
"location": {
"lat": 48.826876,
"lng": 2.334753
},
"duration": 300
}
],
"demand": [
1
]
}
]
}
},
{
"id": "Job_3",
"tasks": {
"deliveries": [
{
"places": [
{
"location": {
"lat": 48.830612,
"lng": 2.342853
},
"duration": 300
}
],
"demand": [
1
]
}
]
}
}
]
}
}前述の問題の仕様は大都市 (この場合はパリ) の中心部周辺で複数の短距離配達を行う1台の配達車両を含む運行管理で構成されています。交通情報の設定が明示的に指定されていないため、最適化アルゴリズムはデフォルトでautomatic交通情報モードを選択し、次のソリューションを生成します。
Click to expand/collapse the sample JSON
{
"statistic": {
"cost": 21.187,
"distance": 1187,
"duration": 554,
"times": {
"driving": 254,
"serving": 300,
"waiting": 0,
"stopping": 0,
"break": 0
}
},
"tours": [
{
"vehicleId": "A_2",
"typeId": "A",
"stops": [
{
"time": {
"arrival": "2023-07-18T09:28:40Z",
"departure": "2023-07-18T09:28:40Z"
},
"load": [
1
],
"activities": [
{
"jobId": "departure",
"type": "departure",
"location": {
"lat": 48.833409,
"lng": 2.34858
},
"time": {
"start": "2023-07-18T09:28:40Z",
"end": "2023-07-18T09:28:40Z"
}
}
],
"location": {
"lat": 48.833409,
"lng": 2.34858
},
"distance": 0
},
{
"time": {
"arrival": "2023-07-18T09:32:54Z",
"departure": "2023-07-18T09:37:54Z"
},
"load": [
0
],
"activities": [
{
"jobId": "Job_3",
"type": "delivery",
"location": {
"lat": 48.830612,
"lng": 2.342853
},
"time": {
"start": "2023-07-18T09:32:54Z",
"end": "2023-07-18T09:37:54Z"
}
}
],
"location": {
"lat": 48.830612,
"lng": 2.342853
},
"distance": 1187
}
],
"statistic": {
"cost": 21.187,
"distance": 1187,
"duration": 554,
"times": {
"driving": 254,
"serving": 300,
"waiting": 0,
"stopping": 0,
"break": 0
}
},
"shiftIndex": 0
}
],
"unassigned": [
{
"jobId": "Job_1",
"reasons": [
{
"code": "REACHABLE_CONSTRAINT",
"description": "location unreachable",
"details": [
{
"vehicleId": "A_2",
"shiftIndex": 0
}
]
}
]
},
{
"jobId": "Job_2",
"reasons": [
{
"code": "REACHABLE_CONSTRAINT",
"description": "location unreachable",
"details": [
{
"vehicleId": "A_2",
"shiftIndex": 0
}
]
}
]
}
]
}このソリューションが示すように、最適化アルゴリズムによって2つのジョブがlocation unreachableのステータスで未割り当てのままとなりました。次の図はそのソリューションを示しています。
この場合のlocation_unreachableステータスは、最適化アルゴリズムが現在の交通状況に基づいてJob1とJob2を完了できないと判断したという意味です。たとえば、ジョブの場所が到達不可能と指定される原因となる条件として、次のようなものがあります。
- 道路の閉鎖
- 特定の車両に対する制限または禁止 (特定の時間帯など)
- 交通渋滞が激しい地域で、ナビゲーションが困難な道路
このようなラストマイル配達のシナリオでは、交通情報を無効にすることで、ドライバーは最大限の柔軟性を持って移動し、道路状況に適応できるようになります。ドライバーが現地の知識を活用する場合もあります。状況に応じて別のルートを選択したり、他の判断を下したりする場合もあります。ルートが混雑していたり一時的に閉鎖されていたりしても、この状況は変わりません。
これを示すため、次のスニペットにあるように、交通情報を無効にすることで、前の例で使用した、車両が1台だけの運行管理の対応するプロファイルを変更しました。
"profiles": [
{
"name": "Vehicle_A",
"type": "car",
"traffic": {
"mode": "disabled"
}
}
]交通情報を無効にすると、次のレスポンスJSONに示すように、結果として得られるソリューションでは未割り当てのジョブがなくなります。
Click to expand/collapse the sample JSON
{
"statistic": {
"cost": 24.856,
"distance": 4856,
"duration": 1723,
"times": {
"driving": 823,
"serving": 900,
"waiting": 0,
"stopping": 0,
"break": 0
}
},
"tours": [
{
"vehicleId": "A_4",
"typeId": "A",
"stops": [
{
"time": {
"arrival": "2023-07-18T09:28:40Z",
"departure": "2023-07-18T09:28:40Z"
},
"load": [
3
],
"activities": [
{
"jobId": "departure",
"type": "departure",
"location": {
"lat": 48.833409,
"lng": 2.34858
},
"time": {
"start": "2023-07-18T09:28:40Z",
"end": "2023-07-18T09:28:40Z"
}
}
],
"location": {
"lat": 48.833409,
"lng": 2.34858
},
"distance": 0
},
{
"time": {
"arrival": "2023-07-18T09:32:19Z",
"departure": "2023-07-18T09:37:19Z"
},
"load": [
2
],
"activities": [
{
"jobId": "Job_3",
"type": "delivery",
"location": {
"lat": 48.830612,
"lng": 2.342853
},
"time": {
"start": "2023-07-18T09:32:19Z",
"end": "2023-07-18T09:37:19Z"
}
}
],
"location": {
"lat": 48.830612,
"lng": 2.342853
},
"distance": 1187
},
{
"time": {
"arrival": "2023-07-18T09:47:09Z",
"departure": "2023-07-18T09:52:09Z"
},
"load": [
1
],
"activities": [
{
"jobId": "Job_1",
"type": "delivery",
"location": {
"lat": 48.826072,
"lng": 2.334607
},
"time": {
"start": "2023-07-18T09:47:09Z",
"end": "2023-07-18T09:52:09Z"
}
}
],
"location": {
"lat": 48.826072,
"lng": 2.334607
},
"distance": 4767
},
{
"time": {
"arrival": "2023-07-18T09:52:23Z",
"departure": "2023-07-18T09:57:23Z"
},
"load": [
0
],
"activities": [
{
"jobId": "Job_2",
"type": "delivery",
"location": {
"lat": 48.826876,
"lng": 2.334753
},
"time": {
"start": "2023-07-18T09:52:23Z",
"end": "2023-07-18T09:57:23Z"
}
}
],
"location": {
"lat": 48.826876,
"lng": 2.334753
},
"distance": 4856
}
],
"statistic": {
"cost": 24.856,
"distance": 4856,
"duration": 1723,
"times": {
"driving": 823,
"serving": 900,
"waiting": 0,
"stopping": 0,
"break": 0
}
},
"shiftIndex": 0
}
]
}次の図は、すべてのジョブが割り当てられた更新されたソリューションを示しています。
結論
このセクションの例で示されているように、交通情報を有効または無効にすると、より実践的で適応性の高いアプローチが可能になります。ビジネスユースケースで、通常の交通情報の考慮事項で到達不能とマークされる可能性のある場所に到達することが多い場合であればなおさらです。
過去の交通状況を考慮する
長距離の配達ルートを考慮する場合、historicalOnly交通情報モードでは距離と時間の延長に伴う課題に関して特定の利点を得ることができます。たとえば、安定した予測可能な時間の推定値を提示して、短期的な交通情報の変動によって生じる可能性のある、過度に悲観的なソリューションのリスクを軽減します。
次の例では車両が1台だけの運行管理に対する10件のジョブで構成される問題について考えてみましょう。
注
次の問題ではデフォルトの
automatic交通情報モード設定を使用しています。
Click to expand/collapse the sample JSON
{
"fleet": {
"types": [
{
"id": "Vehicle_1",
"profile": "car",
"costs": {
"fixed": 10.0,
"distance": 0.001,
"time": 0.002
},
"shifts": [
{
"start": {
"time": "2024-01-23T08:00:00Z",
"location": {
"lat": 51.059188,
"lng": 13.540317
}
},
"end": {
"time": "2024-01-23T21:00:00Z",
"location": {
"lat": 51.059188,
"lng": 13.540317
}
}
}
],
"capacity": [
10
],
"amount": 1
}
],
"profiles": [
{
"type": "car",
"name": "car"
}
]
},
"plan": {
"jobs": [
{
"id": "Job_1",
"tasks": {
"pickups": [
{
"places": [
{
"location": {
"lat": 51.05238,
"lng": 13.74114
},
"duration": 1500
}
],
"demand": [
1
]
}
]
}
},
{
"id": "Job_2",
"tasks": {
"pickups": [
{
"places": [
{
"location": {
"lat": 51.06099,
"lng": 13.75245
},
"duration": 1500
}
],
"demand": [
1
]
}
]
}
},
{
"id": "Job_3",
"tasks": {
"pickups": [
{
"places": [
{
"location": {
"lat": 51.08511,
"lng": 13.76875
},
"duration": 1500
}
],
"demand": [
1
]
}
]
}
},
{
"id": "Job_4",
"tasks": {
"pickups": [
{
"places": [
{
"location": {
"lat": 51.1323847,
"lng": 13.7779515
},
"duration": 1500
}
],
"demand": [
1
]
}
]
}
},
{
"id": "Job_5",
"tasks": {
"pickups": [
{
"places": [
{
"location": {
"lat": 51.11716,
"lng": 13.73054
},
"duration": 1500
}
],
"demand": [
1
]
}
]
}
},
{
"id": "Job_6",
"tasks": {
"deliveries": [
{
"places": [
{
"location": {
"lat": 51.12308,
"lng": 13.76406
},
"duration": 1500
}
],
"demand": [
1
]
}
]
}
},
{
"id": "Job_7",
"tasks": {
"deliveries": [
{
"places": [
{
"location": {
"lat": 51.08588,
"lng": 13.72637
},
"duration": 1500
}
],
"demand": [
1
]
}
]
}
},
{
"id": "Job_8",
"tasks": {
"deliveries": [
{
"places": [
{
"location": {
"lat": 51.08588,
"lng": 13.72637
},
"duration": 1500
}
],
"demand": [
1
]
}
]
}
},
{
"id": "Job_9",
"tasks": {
"deliveries": [
{
"places": [
{
"location": {
"lat": 51.08588,
"lng": 13.72637
},
"duration": 1500
}
],
"demand": [
1
]
}
]
}
},
{
"id": "Job_10",
"tasks": {
"deliveries": [
{
"places": [
{
"location": {
"lat": 51.06866,
"lng": 13.77273
},
"duration": 1500
}
],
"demand": [
1
]
}
]
}
}
]
}
}ここでも同じ例について考えてみましょう。ただし、次のスニペットに示すように、交通情報モードがhistoricalOnlyに設定されている点が異なります。
"fleet": {
"traffic": "historicalOnly",
"types": [ ... ],
"profiles": [
{ ... }
]
},
//... (rest of the content)次のソリューションの比較は、前述のサンプル問題に対しautomaticまたはhistoricalOnly交通情報モードのいずれかを使用した場合にAPIレスポンスがどのように異なるかを示しています。
| 交通情報モード | コスト | 距離 (m) | 所要時間 (秒) | 運転時間 (秒) | サービス時間 (秒) |
|---|---|---|---|---|---|
| automatic | 113.779 | 63,071 | 20,354 | 5,354 | 15,000 |
| historicalOnly | 112.591 | 63,109 | 19,741 | 4,741 | 15,000 |
この比較からわかるように、それぞれのソリューションの主な違いはルートのコスト、距離、所要時間にあります。次の内訳は各ソリューションの値をユーロ、キロメートル、時間に変換した後のこれらの違いをまとめたものです。
| コスト | 距離 (km) | 所要時間 | |
|---|---|---|---|
historicalOnly | 112.591€ | 63.11 | 5時間29分 |
automatic | 113.779€ | 63.07 | 5時間39分 |
これらの異なる値は実際の交通状況に基づいて多少の遅延を考慮するために、場所が十分に近いことに起因します。その結果、automaticソリューションではルートの所要時間が長くなります。
結論
リアルタイムの交通量のデータを組み込むことで、多くの移動シナリオでより動的かつ正確な計画を立てることができます。過去の交通量のデータを使用すると、一般的な交通パターンをより静的に把握できます。リアルタイムの変動は考慮されていないため、過度に悲観的なルーティングソリューションにつながる可能性があります。これは、ルートの範囲が広大な地域に及ぶ可能性がある長距離シナリオでは特に重要です。ここでは過去の交通量のデータは一貫したツアー計画のための安定した予測可能なベースラインを提示します。交通状況の短期的な日々の変化にはあまり影響されません。
次のステップ
26 日前の更新