ガイドAPIリファレンス
ガイド
  1. 開発者ガイド

よくある質問への回答

APIの機能と制限

質問回答
同期および非同期のリクエストフローの車両数、車両タイプ、ジョブ数に制限はありますか？はい。各リクエストタイプの制限の詳細については、「同期エンドポイントと非同期エンドポイントの比較」を参照してください。
Tour Planningでは、ルート検索の計算で交通情報をどのように処理しますか？HERE Tour Planningでは、交通情報は自動、ライブデータまたは履歴データ、履歴データのみの3つの方法で考慮されます。詳細については、「APIリファレンス」でtrafficパラメーターを検索してください (configuration.fleet.traffic)。
HERE Tour Planning APIには、問題定義に含まれる場所の地理的分布に関する制限 (車両または作業場所間の最大距離など) がありますか？Tour Planningには、ルート検索の最大距離に関する制限はありません。ただし、半径490 km (つまりバウンディングボックスの直径980 km) を超える場合、デフォルトではライブ交通情報が考慮されません (「APIリファレンス」のtrafficパラメーターを参照)。ライブ交通情報の取得を常に強制することはできますが、その場合は指定したすべての場所が半径490 km以下の円内に収まる必要があります。収まらない場合は、ステータスコード400、エラーコードE613429とともに、次のエラーメッセージが返されます。「地域の半径が大きすぎるため、交通情報を含めることができません」。この場合、問題となっているいくつかの場所を削除 (ジョブを削除するなど) し、すべての場所が上述の半径490 km以下の円内に収まるようにすることで、問題を解消してライブ交通情報を取得できるようになります。
HERE Tour Planningは車両ルート検索問題 (VRP) の解決をサポートしていますか？はい。VRPを解決するための最も一般的なHERE Tour Planningの使用方法の詳細については、「開発者ガイド」を参照してください。
HERE Tour Planning APIは、オープンVRPをサポートしていますか。はい。詳細については、「オープンな車両ルート検索問題を解決する」を参照してください。
HERE Tour Planning APIは車両ごとに複数のシフトをサポートしていますか？はい。詳細については、「複数のシフトと休憩を伴うVRP」を参照してください。
カスタムの時間距離マトリックスの使用はサポートされていますか？いいえ。リクエストでは、HEREが提供するデフォルトの時間距離マトリックスのみを使用できます。ただし、カスタムのルーティングマトリックスは使用できます。詳細については、「ルート検索プロファイル」を参照してください。
APIは、タスクが同じジョブに属している場合にのみ、集荷タスクを配達タスクの前に必ず処理しますか？はい。集荷と配送が同じジョブの一部である場合 (マルチジョブ)、すべての集荷は常にすべての配達よりも先にスケジュールされます。このルールは、positionフィーチャーでも変更できません。positionフィーチャーは、集荷フェーズ内または配送フェーズ内、または異なるジョブに属するタスクの順序にのみ影響を与えます。詳細については、「ジョブタスク位置を制御する」を参照してください。
配送と集荷の両方のアクティビティを含むシナリオでは、容量はどのように計算されますか？マルチジョブ (集荷作業と配達作業を含むジョブ) の場合、APIは各アクティビティ後の積載量を計算し、過積載が発生しないようにします。集荷の場合、アクティビティの需要値に基づいて車両の積載量を増やします。配達の場合、APIは需要に応じて積載量を減らします。ツアー中のどの時点においても、車両の積載量が容量を超えることはありません。

たとえば、2つのマルチジョブタスクがあり、それぞれが2回の集荷 (demand = 1) と1回の配達 (demand = 2) を行うとします。車両容量が4の場合、ソリューション例は次のようになります。

Tour Start (0) → 1st Pickup job_1 (+1, load = 1) → 2nd Pickup job_1 (+1, load = 2) → 1st Pickup job_2 (+1, load = 3) → 2nd Pickup job_2 (+1, load = 4) → Delivery job_1 (-2, load = 2) → Delivery job_2 (-2, load = 0)

独立した集荷と配達のジョブが混在する場合は、ツアー中に車両の積載量が動的に変化します。たとえば、車両容量が5の場合のソリューション例を考えてみましょう。

Tour Start (0) → Pickup job_1 (+2) → Pickup job_2 (+3) → Delivery job_2 (−3) → Delivery job_1 (−2) → Tour End (0)

容量制限が適用されると、総需要が車両容量を超えた場合、そのツアーでは未割り当てのジョブが発生する可能性があります。次の例では、車両容量が5であるため、job_1などのジョブは割り当てられません。

Tour Start (job_2 + job_3, load = 5) → Delivery job_2 (-2, load = 3) → Pickup job_4 (+1, load = 4) → Pickup job_5 (+1, load = 5) → Delivery job_3 (−3, load = 2) → Tour End (job_4 + job_5, load = 2)

配達のみの場合、初期積載量は需要の合計値と等しくなり、最終積載量は0になります。

集荷のみの場合、初期積載量は0で、最終積載量は割り当てられたすべての需要の合計値と等しくなります。

詳細については、「容量制約付き配送計画問題 (CVRP) を解決する」を参照してください。
未割り当てのジョブはどうなりますか？APIレスポンスには、すべての未割り当てジョブのリストが、割り当てられなかった理由とともに表示されます。

一般的な技術的詳細

質問回答
車両のシフトが数日にわたることはありますか？はい、技術的にはシフトの長さに制限はありません。
「休憩」が1日を超えることはありますか？いいえ、休憩時間は24時間以内に制限されています。
同じ問題を複数回実行すると、ソリューションが若干異なることがあるのはなぜですか？HERE Tour Planning APIが使用するアルゴリズムは非決定的であるためです。
1つのジョブに追加できる集荷または配達のタスクの数はいくつですか？1つのマルチジョブには、最大3つの集荷タスクと3つの配達タスクを追加できます。集荷または配達のタスクをさらに追加する必要がある場合は、問題の作成方法を変える必要があります。集荷が1つの場所で行われ、複数の配達がある場合は、集荷場所を車両のシフト開始場所としてクライアント側で処理し、各配達を個別のジョブとして追加します。これにより問題の複雑さが軽減され、より効率的なツアーを作成できます。
ツアーですべての車両が使用されるようにすることはできますか？はい。optimizeTourCount.maximize目標を使用して、ツアー内のジョブに割り当てられる車両の数を最大化できます。詳細については、「目標」を参照してください。ただし、HERE Tour Planning APIは目標の階層順を使用しており、optimizeTourCount目標の前に他の目標を指定する必要があります。
objectives配列にminimizeCost目標を含める必要がありますか？また、デフォルトのコスト定義で時間を優先する場合、minimizeDurationをobjectivesリストに明示的に追加する必要はありませんか？objectives配列にminimizeCost目標を含めることは、minimizeUnassignedとともに必須です。デフォルトの目標は、未割り当てのジョブの最小化、ツアー数の最適化、コストの最小化の順に優先されます。

最適化で時間 (所要時間) を優先する必要がある場合は、minimizeDuration目標を目標リストに追加し、ビジネス目標に従って考慮されるようにする必要があります。詳細については、「目標」を参照してください。
顧客が2つのパーセルを受け取る場合、それぞれを個別のジョブタスクとして問題に指定する必要がありますか？はい。各パーセルの配達を個別のタスクとして指定し、対応する需要値を指定できます。ただし、HEREでは、事前処理でこれら2つのタスクを1つのタスクに統合し、需要値が個々のタスクの需要の合計と等しくなるようにすることを推奨しています。統合されたタスクは、そのタスクを処理する車両タイプの容量を超えないようにしてください。
place.durationとvehicle.shift.stopBaseDurationの違いは何ですか？place.durationは、タスクを実行するのに必要なサービス時間を表します。たとえば、エレベーターのない5階に冷蔵庫を持ち上げる作業(所要時間：20～30分)や、郵便ポストに手紙を投函する作業(所要時間：数秒～1分)などのタスクが含まれます。

vehicle.shift.stopBaseDurationは、駐車や積み込み/積み下ろしの準備などのタスクを考慮して、車両の各停車地に対して1回追加される所要時間です。これは車両ごとに設定され、車両が停止するたびに適用されます。たとえば、トラックが複数の集荷作業を行うために、ある場所に停車するシナリオを考えてみましょう。トラックのstopBaseDurationは3600秒です。各集荷作業 (place.duration) には300秒かかります。この停車地で5件の集荷があった場合、所要時間は合計1時間25分 (基本の停止時間の3600秒+集荷あたり300秒*5件) となります。詳細については、「APIリファレンス」を参照してください。

配達する特定のアイテム (パーセルや手紙など) ではなく、受取人 (顧客) に基づいて停車地のdurationを決定するには、ジョブクラスタリングにserviceTimeStrategyを使用し、それをmaxDurationStrategyに設定します。このような戦略は、同じ顧客に配達するという事実が重要であり、タスクあたりのサービス時間はそれほど重要ではない配達シナリオで特に役立ちます。たとえば、郵便物の配達では、1つの宛先への配達が手紙1通でも5通でも、タスクを完了するのにかかる時間はほぼ同じです。

maxDurationStrategyは、クラスター内のジョブの合計所要時間が最も長いジョブの所要時間と等しくなるようにします。たとえば、1つの宛先に3通の手紙 (それぞれ60秒の所要時間) と1個のパーセル (120秒の所要時間) を配達する場合、maxDurationStrategyを使用すると、クラスター化されたジョブの所要時間は、クラスターに属するジョブの中で最長の所要時間である120秒になります。詳細については、「クラスタリング」を参照してください。
車両に順序を事前割り当てするにはどうすればよいですか？HERE Tour Planning APIでは、ツアー中に特定の車両に特定のジョブを割り当てるための複数の方法が用意されています。

たとえば、スキルを使用する方法 (推奨) では、ジョブの順序が事前に決まっていない場合でも特定の車両に特定のジョブを事前に割り当てることができます。このアプローチでは、必要なスキル (heavy-duty、refrigeratior、air-conditionedなど) を備えた車両のみがジョブを実行することを保証します。詳細については、「スキルに基づいてジョブを割り当てる」を参照してください。

別の方法では、テリトリーを使用して、地理的領域に基づいて、特定のジョブの実行で使用できる、または優先される車両を制御できます。詳細については、「テリトリー別に旅程を最適化する」を参照してください。

任意のrelationsパラメーターを使用して、特定の車両にジョブを事前に割り当てることもできます。このパラメーターを使用すると、特定の車両にジョブ完了のルールと順序を定義でき、ツアーの再計画プロセスでアルゴリズムの動作に影響を与えます。詳細については、「ツアーの再計画にリレーションを使用する」を参照してください。
合計時間を最小限に抑えることが目標である場合、車両のコスト属性を空のままにするか、デフォルトの小さい値 (0など) に設定できますか？costs属性は0に設定できますが、HEREでは、ツアーの合計時間を効果的に最小限に抑えるために、timeコストに明示的に高い値を設定することを推奨しています。さらに、目標を達成するために、次の階層順で旅程の目標を定義することもできます：minimizeUnassigned、minimizeDuration、optimizeTourCount、minimizeCost。

詳細については、「コストに合わせて旅程を最適化する」を参照してください。
HERE Tour Planning APIで、異なる容量とスキルを持つ2つの異なる荷室を備えた車両を、単一の運行管理タイプとして設定できますか？はい。複数の荷室を備えた車両に対して、異なる容量設定とスキルを持つ単一の運行管理タイプを使用することは可能です。推奨されるアプローチは、運行管理をgeneralやspecialなどのスキルで定義し、それぞれの容量を設定することです。ルートを計画する際に、請求書に特別な製品が含まれているかをどうか確認し、それに応じて車両の選択を調整できます。この方法を使用すると、輸送時の容量と必要なスキルを異なる製品ごとに効果的に管理できます。

詳細については、「スキルに基づいてジョブを割り当てる」を参照してください。

アクセスとライセンス

質問回答
HERE Tour Planning APIを試用する場合、評価契約に署名する必要がありますか？はい。
HERE Tour Planning APIへの評価アクセスを取得するにはどうすればよいですか？地域のHERE担当者に連絡するか、プラットフォームポータルから直接、アクセスをリクエストしてください。
HERE Tour Planning APIへの商用アクセスを取得するにはどうすればよいですか？各地域のHERE担当者にお問い合わせいただくか、直接プラットフォームポータルに進み、アカウントを作成して基本プランを選択してください。

認証と資格情報

質問回答
Tour Planning APIにアクセスするためのトークンまたはAPIキーのリクエスト方法に関する情報はどこで入手できますか？「資格情報を取得する」、「Identity and Access Management」を参照してください。
信頼されるドメインが有効になっているAPIキーを使用している場合、ルートポリラインのリクエストがrouteDetailsUnauthorizedで失敗する失敗するのはなぜでしょうか。"routeDetails": ["polyline"]を使用してルートポリラインをリクエストすると、Tour Planning APIは内部的にRouting API v8 を呼び出します。信頼されるドメインでは、ブラウザーからのHTTPリファラーヘッダーを使用してリクエストを検証します。

フロントエンドがAPIキーをサーバーに渡し、サーバーがTour Planning APIを呼び出す場合、内部のRouting API v8リクエストはサーバーコンテキストから発信されます。サーバー間リクエストには通常、設定済みの信頼されるドメインと照合するために必要なリファラーヘッダーが欠落しているため、routeDetailsUnauthorizedエラーが発生します。

これは、同じAPIキーをフロントエンドから直接使用した場合は正常に動作するものの、サーバーを経由すると失敗する理由を説明するものです。

この問題を解決するには、信頼されるドメインが有効になっていないAPIキーを使用するか、サーバー間リクエストでOAuth認証を使用してください。詳細については、「OAuth 2.0資格情報を取得する」と「旅程のルートポリラインを取得する」を参照してください。

パフォーマンスとレート制限

質問回答
トランザクションの定義は何ですか？リクエストに対して請求されるトランザクション数は、すべての場所の合計です。場所には、作業場所、車両タイプの開始位置と終了位置、休憩 (ドライバーの休憩、充電、その他の計画された停止など) が含まれます。詳細については、「Tour Planningの料金」を参照してください。
HERE Tour Planningのレート制限はどのようになっていますか？レルム (顧客) につき、1秒あたり2リクエストです。これは、同期エンドポイントと非同期エンドポイントの両方に適用されます。この制限を超えるリクエストに対しては、429エラーレスポンスが返されます。
非同期の問題を計算する際のコンピューティングリソースは、各ユーザー間でどのように分配されますか？各ユーザーにはコンピューティングリソースが公平に割り当てられます。他のユーザーと比較してリソースの消費量が極めて多い場合、いくつかの問題の計算が完了するまで、一部の問題の計算を終わるまでに待機が発生する可能性があります。この動作は単に、1人または数人のパワーユーザーが一定期間、すべてのコンピューティングリソースを消費することがないようにするものです。実際には、これに気付くことはありません。非常に多くの問題を非同期計算に同時送信した場合にのみ、これらの問題の計算の一部が通常よりも長く保留状態のままになることがあります。これが問題になる可能性があると思われる場合は、解決策についてHERE担当者にご相談ください。

同期エンドポイントと非同期エンドポイントの比較

同期非同期
最大500か所のタスクの場所最大7,000か所のタスクの場所
最大35件の車両タイプ最大150件の車両タイプ
車両タイプごとに最大350台の車両車両タイプごとに最大350台の車両
maxTime：最大 - 240秒、デフォルト - 240秒maxTime：最大 - 3,600秒、デフォルト - 3,600秒
stagnationTime：最大 - 240、デフォルト - 10stagnationTime：最大 - 3600、デフォルト - 600

26 日前の更新