Package google.maps.routeoptimization.v1

インデックス

RouteOptimization

車両ツアーを最適化するサービス。

特定のタイプのフィールドの有効性:

  • google.protobuf.Timestamp
    • 時刻は Unix 時間(1970-01-01T00:00:00+00:00 からの秒数)で表されます。
    • seconds は [0, 253402300799]、つまり [1970-01-01T00:00:00+00:00, 9999-12-31T23:59:59+00:00] の範囲内である必要があります。
    • nanos は設定解除するか、0 に設定する必要があります。
  • google.protobuf.Duration
    • seconds は [0, 253402300799]、つまり [1970-01-01T00:00:00+00:00, 9999-12-31T23:59:59+00:00] の範囲内である必要があります。
    • nanos は設定解除するか、0 に設定する必要があります。
  • google.type.LatLng
    • 緯度は [-90.0, 90.0] の範囲内になければなりません。
    • 経度は [-180.0, 180.0] の範囲内になければなりません。
    • 緯度と経度の少なくとも 1 つは 0 以外である必要があります。
BatchOptimizeTours

rpc BatchOptimizeTours(BatchOptimizeToursRequest) returns (Operation)

1 つ以上の OptimizeToursRequest メッセージの車両ツアーをバッチで最適化します。

このメソッドは、長時間実行オペレーション(LRO)です。最適化の入力(OptimizeToursRequest メッセージ)と出力(OptimizeToursResponse メッセージ)は、ユーザーが指定した形式で Cloud Storage から読み取られ、Cloud Storage に書き込まれます。OptimizeTours メソッドと同様に、各 OptimizeToursRequest には ShipmentModel が含まれており、ShipmentRoute フィールドを含む OptimizeToursResponse を返します。これは、全体的な費用を最小限に抑えるために車両が実行する一連のルートです。

ユーザーは operations.get をポーリングして、LRO のステータスを確認できます。

LRO の done フィールドが false の場合、1 つ以上のリクエストがまだ処理されています。他のリクエストは正常に完了し、その結果は Cloud Storage で確認できます。

LRO の done フィールドが true の場合、すべてのリクエストが処理されています。正常に処理されたリクエストの結果は Cloud Storage で確認できます。失敗したリクエストの結果は Cloud Storage で使用できません。LRO の error フィールドが設定されている場合、失敗したリクエストのいずれかのエラーが含まれます。

認可スコープ

次の OAuth スコープが必要です。

  • https://www.googleapis.com/auth/cloud-platform
IAM 権限

parent リソースに対する次の IAM 権限が必要です。

  • routeoptimization.operations.create

詳細については、IAM のドキュメントをご覧ください。

OptimizeTours

rpc OptimizeTours(OptimizeToursRequest) returns (OptimizeToursResponse)

ShipmentModel を含む OptimizeToursRequest を送信し、ShipmentRoute(車両が実行するルートのセットで、全体的な費用を最小限に抑える)を含む OptimizeToursResponse を返します。

ShipmentModel モデルは、主に実行する必要がある Shipment と、Shipment の転送に使用できる Vehicle で構成されます。ShipmentRouteShipmentVehicle に割り当てます。具体的には、一連の Visit を各車両に割り当てます。ここで、VisitVisitRequest に対応します。これは、Shipment の集荷または配達です。

目標は、ShipmentModel で定義された多くのコンポーネントを含む総費用を最小限に抑える ShipmentRouteVehicle の割り当てを提供することです。

認可スコープ

次の OAuth スコープが必要です。

  • https://www.googleapis.com/auth/cloud-platform
IAM 権限

parent リソースに対する次の IAM 権限が必要です。

  • routeoptimization.locations.use

詳細については、IAM のドキュメントをご覧ください。

OptimizeToursLongRunning

rpc OptimizeToursLongRunning(OptimizeToursRequest) returns (Operation)

これは、大きなタイムアウト値での最適化用に設計された OptimizeTours メソッドのバリエーションです。数分以上かかる最適化には、OptimizeTours メソッドよりも優先して使用する必要があります。

返される long-running operation(LRO)の名前は <parent>/operations/<operation_id> 形式で、計算の進行状況を追跡するために使用できます。metadata フィールドの型は OptimizeToursLongRunningMetadata です。成功した場合、response フィールドの型は OptimizeToursResponse です。

試験運用版: 詳しくは、https://developers.google.com/maps/tt/route-optimization/experimental/otlr/make-request をご覧ください。

認可スコープ

次の OAuth スコープが必要です。

  • https://www.googleapis.com/auth/cloud-platform
IAM 権限

parent リソースに対する次の IAM 権限が必要です。

  • routeoptimization.operations.create

詳細については、IAM のドキュメントをご覧ください。

OptimizeToursUri

rpc OptimizeToursUri(OptimizeToursUriRequest) returns (Operation)

これは、大きなタイムアウト値と大きな入出力サイズでの最適化用に設計された OptimizeToursLongRunning メソッドのバリアントです。

クライアントは Google Cloud Storage に保存されている OptimizeToursRequest の URI を指定し、サーバーはクライアントが指定した Google Cloud Storage URI に OptimizeToursResponse を書き込みます。

このメソッドは、数分以上かかる最適化や、8 MB を超える入出力サイズの場合に OptimizeTours メソッドよりも優先して使用する必要がありますが、より短時間で小規模な最適化にも使用できます。

返される long-running operation(LRO)の名前は <parent>/operations/<operation_id> 形式で、計算の進行状況を追跡するために使用できます。metadata フィールドの型は OptimizeToursLongRunningMetadata です。成功した場合、response フィールドの型は OptimizeToursUriResponse です。

試験運用版: 詳しくは、https://developers.google.com/maps/tt/route-optimization/experimental/otlr/make-request をご覧ください。

認可スコープ

次の OAuth スコープが必要です。

  • https://www.googleapis.com/auth/cloud-platform
IAM 権限

parent リソースに対する次の IAM 権限が必要です。

  • routeoptimization.operations.create

詳細については、IAM のドキュメントをご覧ください。

AggregatedMetrics

ShipmentRoute(すべての TransitionVisit(すべての ShipmentRoute)要素の OptimizeToursResponse)の集計指標。

フィールド
performed_shipment_count

int32

実施された発送の数。集荷と配達のペアは 1 回のみカウントされます。

travel_duration

Duration

ルートまたはソリューションの合計移動時間。

wait_duration

Duration

ルートまたはソリューションの合計待機時間。

delay_duration

Duration

ルートまたはソリューションの合計遅延時間。

break_duration

Duration

ルートまたはソリューションの合計休憩時間。

visit_duration

Duration

ルートまたはソリューションの合計訪問時間。

total_duration

Duration

合計時間は、上記のすべての時間の合計と等しくなるはずです。ルートの場合、次のようにも対応します。

[ShipmentRoute.vehicle_end_time][google.maps.routeoptimization.v1.ShipmentRoute.vehicle_end_time] - [ShipmentRoute.vehicle_start_time][google.maps.routeoptimization.v1.ShipmentRoute.vehicle_start_time]
travel_distance_meters

double

ルートまたはソリューションの合計移動距離。

max_loads

map<string, VehicleLoad>

ルート(ソリューション)全体の最大負荷。このルート(ソリューション)の各数量について、すべての Transition.vehicle_loadsShipmentRoute.metrics.max_loads

performed_mandatory_shipment_count

int32

実施された必須の発送の数。

試験運用版: このフィールドの動作または存在は、今後変更される可能性があります。

performed_shipment_penalty_cost_sum

double

実行された配送の Shipment.penalty_cost の合計。

試験運用版: このフィールドの動作または存在は、今後変更される可能性があります。

BatchOptimizeToursMetadata

この型にはフィールドがありません。

BatchOptimizeToursRequest 呼び出しのオペレーション メタデータ。

BatchOptimizeToursRequest

ツアーを非同期オペレーションとしてバッチ最適化するリクエスト。各入力ファイルには 1 つの OptimizeToursRequest が含まれ、各出力ファイルには 1 つの OptimizeToursResponse が含まれます。リクエストには、ファイルの読み取り/書き込みと解析を行うための情報が含まれています。入力ファイルと出力ファイルはすべて同じプロジェクトに配置する必要があります。

フィールド
parent

string

必須。呼び出しを行うターゲット プロジェクトとロケーション。

形式:

  • projects/{project-id}
  • projects/{project-id}/locations/{location-id}

ロケーションが指定されていない場合、リージョンが自動的に選択されます。

model_configs[]

AsyncModelConfig

必須。各購入モデルの入出力情報(ファイルパスやデータ形式など)。

AsyncModelConfig

1 つの最適化モデルを非同期で解決するための情報。

フィールド
display_name

string

省略可。ユーザー定義のモデル名。ユーザーがモデルを追跡するためのエイリアスとして使用できます。

input_config

InputConfig

必須。入力モデルに関する情報。

output_config

OutputConfig

必須。目的の出力場所情報。

BatchOptimizeToursResponse

この型にはフィールドがありません。

BatchOptimizeToursRequest へのレスポンス。これは、オペレーションの完了後に長時間実行オペレーションで返されます。

BreakRule

車両の休憩時間(昼食休憩など)を生成するルール。休憩とは、車両が現在の位置でアイドル状態を維持し、訪問を実行できない連続した期間のことです。休憩は次の場合に発生する可能性があります。

  • 2 回の訪問の間の移動中(訪問の直前または直後の時間を含みますが、訪問の途中は含みません)。この場合、訪問間の対応する移動時間が延長されます。
  • または車両の始動前(休憩中に車両が始動しない場合もあります)。この場合、車両の始動時間に影響はありません。
  • または車両終了後(車両終了時刻も同様)。
フィールド
break_requests[]

BreakRequest

休憩の順序。BreakRequest メッセージをご覧ください。

frequency_constraints[]

FrequencyConstraint

複数の FrequencyConstraint を適用できます。これらはすべて、この BreakRuleBreakRequest によって満たされる必要があります。FrequencyConstraint をご覧ください。

BreakRequest

各車両に適用される休憩の順序(休憩の数と順序)は、事前に把握しておく必要があります。繰り返される BreakRequest は、発生する順序でシーケンスを定義します。時間枠(earliest_start_time / latest_start_time)は重複する可能性がありますが、順序と互換性がある必要があります(これはチェックされます)。

フィールド
earliest_start_time

Timestamp

必須。休憩の開始の下限(この値を含む)。

latest_start_time

Timestamp

必須。ブレークの開始の上限(この値を含む)。

min_duration

Duration

必須。休憩の最小時間。正の値である必要があります。

FrequencyConstraint

「12 時間ごとに 1 時間以上の休憩を必ず取らなければならない」など、最小休憩頻度を強制することで、上記の休憩の頻度と時間をさらに制限できます。これを「12 時間のスライディング時間枠内に、少なくとも 1 時間の休憩が 1 回以上必要」と解釈すると、この例は次の FrequencyConstraint に変換されます。

{
   min_break_duration { seconds: 3600 }         # 1 hour.
   max_inter_break_duration { seconds: 39600 }  # 11 hours (12 - 1 = 11).
}

ソリューションの休憩のタイミングと期間は、BreakRequest で指定された時間枠と最小期間に加えて、このような制約をすべて考慮します。

実際には、FrequencyConstraint は連続していない休憩にも適用されることがあります。たとえば、次のスケジュールは「12 時間ごとに 1 時間」の例に従っています。

  04:00 vehicle start
   .. performing travel and visits ..
  09:00 1 hour break
  10:00 end of the break
   .. performing travel and visits ..
  12:00 20-min lunch break
  12:20 end of the break
   .. performing travel and visits ..
  21:00 1 hour break
  22:00 end of the break
   .. performing travel and visits ..
  23:59 vehicle end
フィールド
min_break_duration

Duration

必須。この制約の最小休憩時間。非負。FrequencyConstraint の説明をご覧ください。

max_inter_break_duration

Duration

必須。duration >= min_break_duration の休憩を少なくとも一部含まないルート内の任意の時間間隔の最大許容スパン。正の値である必要があります。

DataFormat

入力ファイルと出力ファイルのデータ形式。

列挙型
DATA_FORMAT_UNSPECIFIED 値が無効です。形式は UNSPECIFIED にすることはできません。
JSON JavaScript Object Notation。
PROTO_TEXT プロトコル バッファのテキスト形式。https://protobuf.dev/reference/protobuf/textformat-spec/ をご覧ください。

DistanceLimit

移動可能な最大距離を定義する制限。ハードまたはソフトのいずれかになります。

ソフト上限が定義されている場合、soft_max_meterscost_per_kilometer_above_soft_max の両方を定義し、非負の値にする必要があります。

フィールド
max_meters

int64

距離を最大 max_meters に制限するハードリミット。上限値は負の値にできません。

soft_max_meters

int64

最大距離制限を強制しないソフト制限。違反すると、モデルで定義された他の費用と同じ単位で、費用が加算されます。

定義されている場合、soft_max_meters は max_meters より小さく、負でない値である必要があります。

cost_per_kilometer_below_soft_max

double

発生した 1 キロメートルあたりの費用。soft_max_meters まで増加します。式は次のとおりです。

  min(distance_meters, soft_max_meters) / 1000.0 *
  cost_per_kilometer_below_soft_max.

この費用は route_distance_limit ではサポートされていません。

cost_per_kilometer_above_soft_max

double

距離が soft_max_meters の上限を超えた場合に発生する 1 キロメートルあたりの費用。距離が上限を下回る場合は追加費用は 0 です。それ以外の場合は、費用の計算に使用される式は次のとおりです。

  (distance_meters - soft_max_meters) / 1000.0 *
  cost_per_kilometer_above_soft_max.

費用は負の値にできません。

GcsDestination

出力ファイルが書き込まれる Google Cloud Storage のロケーション。

フィールド
uri

string

必須。Google Cloud Storage URI。

GcsSource

入力ファイルの読み取り元となる Google Cloud Storage のロケーション。

フィールド
uri

string

必須。gs://bucket/path/to/object 形式の Google Cloud Storage オブジェクトの URI。

InjectedSolutionConstraint

リクエストに挿入されたソリューション。制約する必要がある訪問と、制約する方法に関する情報が含まれます。

フィールド
routes[]

ShipmentRoute

挿入するソリューションのルート。一部のルートは元のソリューションから除外される場合があります。ルートとスキップされた配送は、injected_first_solution_routes に記載されている基本的な有効性の前提条件を満たしている必要があります。

skipped_shipments[]

SkippedShipment

挿入するソリューションのスキップされた配送。一部は元のソリューションから省略される場合があります。routes フィールドをご覧ください。

constraint_relaxations[]

ConstraintRelaxation

車両の 0 個以上のグループについて、制約を緩和するタイミングと緩和量を指定します。このフィールドが空の場合、空でないすべての車両ルートが完全に制約されます。

ConstraintRelaxation

車両のグループについて、訪問の制約が緩和されるしきい値と緩和されるレベルを指定します。skipped_shipment フィールドにリストされている配送はスキップされるように制約されます。つまり、実行できません。

フィールド
relaxations[]

Relaxation

vehicle_indices の車両を含むルートのルートに適用されるすべての訪問制約の緩和。

vehicle_indices[]

int32

訪問制約 relaxations が適用される車両インデックスを指定します。空の場合、これはデフォルトとみなされ、他の constraint_relaxations で指定されていないすべての車両に relaxations が適用されます。デフォルトは 1 つまでです。つまり、制約緩和フィールドを空の vehicle_indices にできるのは 1 つまでです。車両インデックスは、複数の constraint_relaxations 内であっても 1 回しか登録できません。

interpret_injected_solutions_using_labels が true の場合、車両インデックスは ShipmentRoute.vehicle_index と同様にマッピングされます(fields のコメントを参照)。

リラクゼーション

relaxations が空の場合、routes のすべての訪問の開始時間と順序が完全に制約され、これらのルートに新しい訪問を挿入または追加することはできません。また、車両が空の場合(つまり、訪問がなく、モデルで used_if_route_is_empty が false に設定されている場合)を除き、routes の車両の開始時刻と終了時刻は完全に制約されます。

relaxations(i).level は、次の条件を満たす訪問 #j に適用される制約緩和レベルを指定します。

  • route.visits(j).start_time >= relaxations(i).threshold_time AND
  • j + 1 >= relaxations(i).threshold_visit_count

同様に、次の条件を満たす場合、車両の始動は relaxations(i).level に緩和されます。

  • vehicle_start_time >= relaxations(i).threshold_time AND
  • relaxations(i).threshold_visit_count == 0 と車両の終了は、次の条件を満たす場合に relaxations(i).level に緩和されます。
  • vehicle_end_time >= relaxations(i).threshold_time AND
  • route.visits_size() + 1 >= relaxations(i).threshold_visit_count

訪問が threshold_visit_count または threshold_time を満たす場合に緩和レベルを適用するには、同じ level を持つ 2 つの relaxations を追加します。1 つは threshold_visit_count のみ設定し、もう 1 つは threshold_time のみ設定します。1 回のアクセスが複数の relaxations の条件を満たしている場合は、最も制限の緩いレベルが適用されます。その結果、車両の出発からルートの訪問順序を経て車両の終了まで、緩和レベルはより緩和されます。つまり、ルートの進行に伴って緩和レベルは低下しません。

relaxations のしきい値条件を満たさないルート訪問のタイミングと順序は完全に制約され、これらの順序に訪問を挿入することはできません。また、車両が空でない限り、車両の開始または終了が緩和条件を満たしていない場合、時間は固定されます。

フィールド
level

Level

threshold_time 以降の条件と少なくとも threshold_visit_count の条件が満たされた場合に適用される制約緩和レベル。

threshold_time

Timestamp

緩和 level を適用できる時刻。

threshold_visit_count

int32

緩和 level を適用できる訪問回数。threshold_visit_count が 0(または未設定)の場合、level は車両の起動時に直接適用されることがあります。

route.visits_size() + 1 の場合、level は車両の末尾にのみ適用できます。route.visits_size() + 1 を超える場合、そのルートには level は適用されません。

レベル

しきい値条件を満たした場合に、1 回の訪問とその後の訪問に適用されるさまざまな制約緩和レベルを表します。

次の列挙型は、緩和の度合いが低い順に並んでいます。

列挙型
LEVEL_UNSPECIFIED

暗黙的なデフォルトの緩和レベル: 制約は緩和されません。つまり、すべての訪問が完全に制約されます。

この値は level で明示的に使用しないでください。

RELAX_VISIT_TIMES_AFTER_THRESHOLD 訪問の開始時刻と車両の開始時刻/終了時刻は緩和されますが、各訪問は同じ車両にバインドされたままで、訪問の順序は維持されます。訪問の間に訪問を挿入したり、訪問の前に訪問を挿入したりすることはできません。
RELAX_VISIT_TIMES_AND_SEQUENCE_AFTER_THRESHOLD RELAX_VISIT_TIMES_AFTER_THRESHOLD と同じですが、訪問順序も緩和されます。訪問はこの車両でのみ実行できますが、実行されない可能性もあります。
RELAX_ALL_AFTER_THRESHOLD RELAX_VISIT_TIMES_AND_SEQUENCE_AFTER_THRESHOLD と同じですが、車両も緩和されます。しきい値時間以降の訪問は完全に無料になり、実行されない可能性があります。

InputConfig

[BatchOptimizeTours][google.maps.routeoptimization.v1.RouteOptimizationService.BatchOptimizeTours] の入力を指定します。

フィールド
data_format

DataFormat

必須。入力データ形式。

共用体フィールド source。必須。source は次のいずれかになります。
gcs_source

GcsSource

Google Cloud Storage のロケーション。これは単一のオブジェクト(ファイル)にする必要があります。

場所

位置情報(地理的な地点と、必要に応じて見出し)をカプセル化します。

フィールド
lat_lng

LatLng

経由地の地理座標。

heading

int32

交通の流れの方向に関連付けられたコンパス方位。この値は、乗車と降車に使用する道路の側を指定するために使用されます。見出しの値は 0 ~ 360 の範囲で、0 は真北の見出し、90 は真東の見出しなどを指定します。

OptimizeToursLongRunningMetadata

この型にはフィールドがありません。

OptimizeToursLongRunning 呼び出しのオペレーション メタデータ。

OptimizeToursRequest

ツアー最適化ソルバーに渡されるリクエスト。解決する配送モデルと最適化パラメータを定義します。

フィールド
parent

string

必須。呼び出しを行うターゲット プロジェクトまたはロケーション。

形式:

  • projects/{project-id}
  • projects/{project-id}/locations/{location-id}

ロケーションが指定されていない場合、リージョンが自動的に選択されます。

timeout

Duration

このタイムアウトが設定されている場合、サーバーはタイムアウト期間が経過する前、または同期リクエストのサーバーの期限に達する前のいずれか早いほうでレスポンスを返します。

非同期リクエストの場合、サーバーはタイムアウトが経過する前に解決策を生成します(可能な場合)。

model

ShipmentModel

解決する配送モデル。

solving_mode

SolvingMode

デフォルトでは、解決モードは DEFAULT_SOLVE(0)です。

search_mode

SearchMode

リクエストの解決に使用された検索モード。

injected_first_solution_routes[]

ShipmentRoute

最適化アルゴリズムが以前のソリューションに類似した最初のソリューションを見つけるようにガイドします。

モデルは、最初のソリューションが構築されるときに制約されます。ルートで実行されなかった配送は、最初のソリューションでは暗黙的にスキップされますが、後続のソリューションでは実行される可能性があります。

このソリューションは、基本的な有効性の仮定を満たしている必要があります。

  • すべてのルートで、vehicle_index は範囲内で重複しないようにする必要があります。
  • すべての訪問について、shipment_indexvisit_request_index は範囲内である必要があります。
  • 1 つの配送は 1 つのルートでのみ参照できます。
  • 集荷配送の荷物の集荷は、配送の前に行う必要があります。
  • 1 回の配送につき、集荷または配送の代替手段を 1 つのみ実施できます。
  • すべてのルートで所要時間が増加している(つまり、vehicle_start_time <= visits[0].start_time <= visits[1].start_time ... <= vehicle_end_time)。
  • 配送は、許可された車両でのみ行うことができます。Shipment.allowed_vehicle_indices が空であるか、vehicle_indexShipment.allowed_vehicle_indices に含まれている場合、車両は許可されます。

挿入されたソリューションが実現可能でない場合、検証エラーが必ずしも返されるとは限りません。代わりに、実現不可能であることを示すエラーが返されることがあります。

injected_solution_constraint

InjectedSolutionConstraint

最適化アルゴリズムを制約して、以前のソリューションと類似した最終的なソリューションを見つけます。たとえば、完了済みのルートや、完了予定だが変更してはならないルートの一部をフリーズするために使用できます。

挿入されたソリューションが実現可能でない場合、検証エラーが必ずしも返されるとは限りません。代わりに、実現不可能であることを示すエラーが返されることがあります。

refresh_details_routes[]

ShipmentRoute

空でない場合、指定されたルートが更新されます。基盤となる訪問順序や移動時間は変更されず、その他の詳細のみが更新されます。これはモデルを解決しません。

2020 年 11 月の時点では、この関数は空でないルートのポリラインのみを入力し、populate_polylines が true である必要があります。

渡されたルートの route_polyline フィールドがルート transitions と一致しないことがあります。

このフィールドは、injected_first_solution_routes または injected_solution_constraint と同時に使用できません。

Shipment.ignoreVehicle.ignore は動作に影響しません。関連する配送や車両が無視されるかどうかに関係なく、空でないすべてのルートのすべての訪問の間にポリラインが入力されます。

interpret_injected_solutions_using_labels

bool

該当する場合:

この解釈は、injected_first_solution_routesinjected_solution_constraintrefresh_details_routes フィールドに適用されます。これは、リクエスト内の配送または車両のインデックスがソリューションの作成時から変更された場合に使用できます。たとえば、リクエストから配送または車両が削除されたり、リクエストに追加されたりした場合です。

true の場合、次のカテゴリのラベルは、カテゴリ内で 1 回だけ表示されます。

挿入されたソリューションの vehicle_label がリクエスト車両に対応していない場合、対応するルートとその訪問はソリューションから削除されます。挿入されたソリューションの shipment_label がリクエストされた配送に対応していない場合、対応する訪問はソリューションから削除されます。挿入されたソリューションの SkippedShipment.label がリクエストの発送に対応していない場合、SkippedShipment はソリューションから削除されます。

挿入されたソリューションからルートの訪問やルート全体を削除すると、暗黙的な制約に影響する可能性があり、ソリューションの変更、検証エラー、実行不能につながる可能性があります。

注: 呼び出し元は、各 Vehicle.label(または Shipment.label)は、2 つの関連するリクエスト(挿入されたソリューションで使用される OptimizeToursResponse を生成した過去のリクエストと、挿入されたソリューションを含む現在のリクエスト)で使用される車両(または配送)エンティティを一意に識別します。上記のユニーク性チェックだけでは、この要件を満たすことはできません。

consider_road_traffic

bool

ShipmentRoute フィールド Transition.travel_durationVisit.start_timevehicle_end_time の計算、ShipmentRoute.has_traffic_infeasibilities フィールドの設定、OptimizeToursResponse.total_cost フィールドの計算では、トラフィックの見積もりを考慮します。

populate_polylines

bool

true の場合、ポリラインがレスポンス ShipmentRoute に入力されます。

populate_transition_polylines

bool

true の場合、ポリラインとルートトークンがレスポンス ShipmentRoute.transitions に入力されます。

allow_large_deadline_despite_interruption_risk

bool

この設定を行うと、リクエストの期限を最大 60 分に設定できます(https://grpc.io/blog/deadlines を参照)。それ以外の場合、最大期限は 30 分のみです。長時間実行されるリクエストは、中断のリスクが大幅に高くなります(ただし、リスク自体は小さいままです)。

use_geodesic_distances

bool

true の場合、移動距離は Google マップの距離ではなく測地線距離を使用して計算され、移動時間は geodesic_meters_per_second で定義された速度で測地線距離を使用して計算されます。

label

string

このリクエストの識別に使用できるラベル。OptimizeToursResponse.request_label でレポートされます。

geodesic_meters_per_second

double

use_geodesic_distances が true の場合、このフィールドを設定する必要があります。このフィールドは、移動時間の計算に使用される速度を定義します。値は 1.0 メートル/秒以上にする必要があります。

max_validation_errors

int32

返される検証エラーの数を切り捨てます。通常、これらのエラーは、solving_mode=VALIDATE_ONLY でない限り、BadRequest エラーの詳細(https://cloud.google.com/apis/design/errors#error_details)として INVALID_ARGUMENT エラー ペイロードに付加されます。OptimizeToursResponse.validation_errors フィールドをご覧ください。デフォルトは 100 で、上限は 10,000 です。

SearchMode

レイテンシとソリューションの品質のトレードオフを考慮して、検索の動作を定義するモード。どのモードでも、グローバル リクエストの期限が適用されます。

列挙型
SEARCH_MODE_UNSPECIFIED 検索モードが指定されていません(RETURN_FAST と同等)。
RETURN_FAST 最初の適切な解決策が見つかったら検索を停止します。
CONSUME_ALL_AVAILABLE_TIME 利用可能な時間をすべて費やして、より良い解決策を探します。

SolvingMode

ソルバーがリクエストを処理する方法を定義します。VALIDATE_ONLY 以外のすべてのモードで、リクエストが無効な場合は INVALID_REQUEST エラーが返されます。返されるエラーの数を制限するには、max_validation_errors をご覧ください。

列挙型
DEFAULT_SOLVE モデルを解きます。警告は [OptimizeToursResponse.validation_errors][google.cloud.optimization.v1.OptimizeToursResponse.validation_errors] で発行されることがあります。
VALIDATE_ONLY モデルを検証するだけで、解決はしません。可能な限り多くの OptimizeToursResponse.validation_errors を入力します。
DETECT_SOME_INFEASIBLE_SHIPMENTS

OptimizeToursResponse.validation_errors または OptimizeToursResponse.skipped_shipments のみを入力し、リクエストの残りの部分(statusroutes はレスポンスで設定解除)は実際には解決しません。injected_solution_constraint ルートで実現不可能性が検出されると、OptimizeToursResponse.validation_errors フィールドに入力され、OptimizeToursResponse.skipped_shipments は空のままになります。

重要: ここでは、実現不可能なすべての配送が返されるわけではありません。前処理中に実現不可能と検出された配送のみが返されます。

TRANSFORM_AND_RETURN_REQUEST

このモードは、ShipmentModel.objectives が空でない場合にのみ機能します。リクエストは解決されていません。検証され、指定された目標に対応する費用が入力されるだけです。ShipmentModel.objectives のドキュメントもご覧ください。結果のリクエストは OptimizeToursResponse.processed_request として返されます。

試験運用版: 詳しくは、https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request をご覧ください。

OptimizeToursResponse

ツアー最適化問題の解決後に返されるレスポンス。各車両がたどったルート、スキップされた荷物、ソリューションの全体的な費用が含まれます。

フィールド
routes[]

ShipmentRoute

各車両に対して計算されたルート。i 番目のルートはモデル内の i 番目の車両に対応します。

request_label

string

リクエストでラベルが指定された場合は、OptimizeToursRequest.label のコピー。

skipped_shipments[]

SkippedShipment

スキップされたすべての配送のリスト。

validation_errors[]

OptimizeToursValidationError

個別に検出できたすべての検証エラーのリスト。OptimizeToursValidationError メッセージについては、「複数のエラー」の説明を参照してください。エラーではなく、solving_modeDEFAULT_SOLVE の場合は警告が含まれます。

processed_request

OptimizeToursRequest

場合によっては、受信したリクエストを解決する前に変更(費用の追加など)します。solving_mode == TRANSFORM_AND_RETURN_REQUEST の場合、変更されたリクエストがここで返されます。

試験運用版: 詳しくは、https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request をご覧ください。

metrics

Metrics

このソリューションの期間、距離、使用状況の指標。

指標

すべてのルートで集計された全体的な指標。

フィールド
aggregated_route_metrics

AggregatedMetrics

ルート全体で集計されます。各指標は、同じ名前のすべての ShipmentRoute.metrics フィールドの合計(または負荷の場合は最大値)です。

skipped_mandatory_shipment_count

int32

スキップされた必須の配送の数。

used_vehicle_count

int32

使用された車両の数。注: 車両ルートが空で Vehicle.used_if_route_is_empty が true の場合、車両は使用中と見なされます。

earliest_vehicle_start_time

Timestamp

中古車の最も早い開始時間。すべての中古車の ShipmentRoute.vehicle_start_time の最小値として計算されます。

latest_vehicle_end_time

Timestamp

中古車の最新の終了時間。すべての中古車の ShipmentRoute.vehicle_end_time の最大値として計算されます。

costs

map<string, double>

ソリューションの費用(費用関連のリクエスト フィールド別に分類)。キーは、入力 OptimizeToursRequest に相対的な proto パス(例: 「model.shipments.pickups.cost」)で、値は対応する費用フィールドによって生成された合計費用で、ソリューション全体で集計されます。つまり、costs["model.shipments.pickups.cost"] は、ソリューション全体のすべての集荷費用の合計です。モデルで定義されたすべての費用がここに詳細にレポートされます。ただし、2022 年 1 月の時点では、TransitionAttributes に関連する費用は集計された形でしかレポートされません。

total_cost

double

ソリューションの合計費用。費用マップ内のすべての値の合計。

OptimizeToursUriMetadata

この型にはフィールドがありません。

OptimizeToursUri 呼び出しのオペレーション メタデータ。

OptimizeToursUriRequest

OptimizeToursUri メソッドで使用されるリクエスト。

フィールド
parent

string

必須。呼び出しを行うターゲット プロジェクトまたはロケーション。

形式:

  • projects/{project-id}
  • projects/{project-id}/locations/{location-id}

ロケーションが指定されていない場合、リージョンが自動的に選択されます。

input

Uri

必須。OptimizeToursRequest を含む Cloud Storage オブジェクトの URI。

output

Uri

必須。OptimizeToursResponse を含む Cloud Storage オブジェクトの URI。

OptimizeToursUriResponse

OptimizeToursUri メソッドによって返されるレスポンス。

フィールド
output

Uri

省略可。JSON または textproto としてエンコードされた OptimizeToursResponse を含む Cloud Storage オブジェクトの URI。オブジェクトが JSON としてエンコードされている場合、オブジェクト名の拡張子は .json になります。オブジェクトが textproto としてエンコードされている場合、オブジェクト名の拡張子は .txtpb になります。

リソースの crc32_checksum を使用して、リソースの内容が変更されていないことを確認できます。

OptimizeToursValidationError

OptimizeToursRequest の検証時に発生したエラーまたは警告について説明します。

フィールド
code

int32

検証エラーは、常に存在するペア(codedisplay_name)で定義されます。

このセクションの後のフィールドには、エラーに関する詳細なコンテキストが示されます。

複数のエラー: 複数のエラーがある場合、検証プロセスは複数のエラーを出力しようとします。コンパイラと同様に、これは完璧なプロセスではありません。検証エラーの中には「致命的」なものがあり、検証プロセス全体が停止します。これは、display_name="UNSPECIFIED" エラーなどの場合に該当します。エラーによっては、検証プロセスで他のエラーがスキップされることがあります。

安定性: codedisplay_name は非常に安定している必要があります。ただし、新しいコードと表示名が時間の経過とともに表示されることがあります。この場合、新しいエラーによって古いエラーが隠されるため、特定の(無効な)リクエストで異なる(codedisplay_name)ペアが生成されることがあります。たとえば、「複数のエラー」をご覧ください。

display_name

string

エラーの表示名。

fields[]

FieldReference

エラー コンテキストには、0 個、1 個(ほとんどの場合)、または複数のフィールドが含まれる場合があります。たとえば、車両 #4 と配送 #2 の最初の集荷を参照するには、次のようにします。

fields { name: "vehicles" index: 4}
fields { name: "shipments" index: 2 sub_field {name: "pickups" index: 0} }

ただし、特定のエラーコードの fields のカーディナリティは変更しないでください。

error_message

string

エラーを説明する、人が読める形式の文字列。codeerror_message は 1 対 1 で対応しています(code != "UNSPECIFIED" の場合)。

安定性: 安定していません。特定の code に関連付けられたエラー メッセージは、時間の経過とともに変更される可能性があります(明確化されることが望まれます)。代わりに display_namecode を使用してください。

offending_values

string

フィールドの値を 1 つ以上含めることができます。この機能は常に利用できるとは限りません。この機能に依存することは絶対に避けてください。手動のモデル デバッグにのみ使用してください。

FieldReference

検証エラーのコンテキストを指定します。FieldReference は常にこのファイル内の特定のフィールドを参照し、同じ階層構造に従います。たとえば、車両 #5 の start_time_windows の要素 #2 を指定するには、次のようにします。

name: "vehicles" index: 5 sub_field { name: "end_time_windows" index: 2 }

ただし、メッセージが煩雑になるのを避けるため、OptimizeToursRequestShipmentModel などの最上位エンティティは省略します。

フィールド
name

string

フィールドの名前(例: "vehicles"。

sub_field

FieldReference

必要に応じて、再帰的にネストされたサブフィールド。

共用体フィールド index_or_key

index_or_key は次のいずれかになります。

index

int32

繰り返しの場合のフィールドのインデックス。

key

string

フィールドがマップの場合のキー。

OutputConfig

[BatchOptimizeTours][google.maps.routeoptimization.v1.RouteOptimizationService.BatchOptimizeTours] の結果の宛先を指定します。

フィールド
data_format

DataFormat

必須。出力データ形式。

共用体フィールド destination。必須。destination は次のいずれかになります。
gcs_destination

GcsDestination

出力を書き込む Google Cloud Storage の場所。

RouteModifiers

車両ルートの計算時に満たす必要がある一連のオプション条件をカプセル化します。これは、Google Maps Platform Routes Preferred API の RouteModifiers と同様です。https://developers.google.com/maps/documentation/routes/reference/rest/v2/RouteModifiers をご覧ください。

フィールド
avoid_tolls

bool

有料道路を避けるかどうかを指定します。有料道路を含まないルートが優先されます。電動の移動手段にのみ適用されます。

avoid_highways

bool

可能な限り高速道路を回避するかどうかを指定します。高速道路を含まないルートが優先されます。電動の移動手段にのみ適用されます。

avoid_ferries

bool

可能な限りフェリーを避けるかどうかを指定します。フェリーでの移動を含まないルートが優先されます。電動の移動手段にのみ適用されます。

avoid_indoor

bool

省略可。屋内ナビゲーションを可能な限り避けるかどうかを指定します。屋内ナビゲーションを含まないルートが優先されます。WALKING の移動手段にのみ適用されます。

配送

1 つのアイテムの配送。集荷から配達まで。配送が完了したと見なされるには、固有の車両が 1 つの集荷場所を訪れ(それに応じて予備容量が減少)、その後 1 つの配送場所を訪れる(それに応じて予備容量が再び増加)必要があります。

フィールド
display_name

string

荷物のユーザー定義の表示名。最大 63 文字で、UTF-8 文字を使用できます。

pickups[]

VisitRequest

配送に関連付けられた集荷の代替手段のセット。指定しない場合、車両は配達に対応する場所のみに立ち寄る必要があります。

deliveries[]

VisitRequest

配送に関連付けられた配送方法の代替案のセット。指定しない場合、車両は集荷に対応する場所のみに立ち寄る必要があります。

load_demands

map<string, Load>

荷物の積載要件(重量、容積、パレット数など)。マップ内のキーは、対応する負荷のタイプを説明する識別子である必要があります。単位も指定することが望ましいです。例: 「weight_kg」、「volume_gallons」、「pallet_count」など。指定されたキーがマップに表示されない場合、対応する読み込みは null と見なされます。

allowed_vehicle_indices[]

int32

この配送を行う可能性のある車両のセット。空の場合、すべての車両が実行できます。車両は、ShipmentModelvehicles リストのインデックスで指定されます。

costs_per_vehicle[]

double

この配送が各車両で配達された場合に発生する費用を指定します。指定する場合は、次のいずれかが必要です。

  • costs_per_vehicle_indices と同じ数の要素が含まれます。costs_per_vehicle[i] は、モデルの車両 costs_per_vehicle_indices[i] に対応します。
  • モデル内の車両と同じ数の要素。i 番目の要素は、モデルの車両 #i に対応します。

これらの費用は penalty_cost と同じ単位で指定する必要があり、負の値は指定できません。そのような費用がない場合は、このフィールドを空のままにします。

costs_per_vehicle_indices[]

int32

costs_per_vehicle が適用される車両のインデックス。空でない場合は、costs_per_vehicle と同じ数の要素が含まれている必要があります。車両インデックスは複数回指定できません。車両が costs_per_vehicle_indices から除外されている場合、費用は 0 になります。

pickup_to_delivery_absolute_detour_limit

Duration

集荷から配達までの最短経路と比較した、最大絶対迂回時間を指定します。指定する場合は、非負の値にする必要があります。また、配送には少なくとも集荷と配達が含まれている必要があります。

たとえば、t を選択した受け取り方法から選択した配送方法に直接移動するのにかかる最短時間とします。pickup_to_delivery_absolute_detour_limit を設定すると、次のことが強制されます。

start_time(delivery) - start_time(pickup) <=
t + pickup_to_delivery_absolute_detour_limit

同じ配送で相対的な上限と絶対的な上限の両方が指定されている場合は、可能な集荷/配達のペアごとに、より制約の厳しい上限が使用されます。2017 年 10 月の時点で、迂回は移動時間が車両に依存しない場合にのみサポートされています。

pickup_to_delivery_time_limit

Duration

荷物の集荷開始から配達開始までの最大期間を指定します。指定する場合は、非負の値にする必要があります。また、配送には少なくとも集荷と配達が含まれている必要があります。これは、受け取りと配送に選択された代替手段や車両の速度には依存しません。これは、最大迂回制約とともに指定できます。ソリューションは両方の仕様を尊重します。

shipment_type

string

この配送の「タイプ」を指定する空でない文字列。この機能を使用して、shipment_types 間の非互換性や要件を定義できます(ShipmentModelshipment_type_incompatibilitiesshipment_type_requirements を参照)。

1 回の訪問に対して指定される visit_types とは異なります。同じ配送に属するすべての集荷/配達で同じ shipment_type が共有されます。

label

string

この配送のラベルを指定します。このラベルは、対応する ShipmentRoute.Visitshipment_label のレスポンスで報告されます。

ignore

bool

true の場合、この配送をスキップしますが、penalty_cost は適用しません。

モデルに shipment_type_requirements がある場合、配送を無視すると検証エラーが発生します。

injected_first_solution_routes または injected_solution_constraint で実行された配送を無視することは許可されています。ソルバーは、関連する集荷/配達の訪問をルートから削除します。無視された配送を参照する precedence_rules も無視されます。

penalty_cost

double

配送が完了しなかった場合、このペナルティはルートの総費用に追加されます。受け取りと配達のいずれかの代替手段が選択された場合、配送は完了したとみなされます。費用は、モデル内の他のすべての費用関連フィールドで使用されているのと同じ単位で表すことができ、正の値である必要があります。

重要: このペナルティが指定されていない場合、無限と見なされます。つまり、配送を完了する必要があります。

pickup_to_delivery_relative_detour_limit

double

集荷から配達までの最短経路と比較した、相対的な迂回時間の最大値を指定します。指定する場合は、非負の値にする必要があります。また、配送には少なくとも集荷と配達が含まれている必要があります。

たとえば、t を選択した受け取り方法から選択した配送方法に直接移動するのにかかる最短時間とします。pickup_to_delivery_relative_detour_limit を設定すると、次のことが強制されます。

start_time(delivery) - start_time(pickup) <=
std::ceil(t * (1.0 + pickup_to_delivery_relative_detour_limit))

同じ配送で相対的な上限と絶対的な上限の両方が指定されている場合は、可能な集荷/配達のペアごとに、より制約の厳しい上限が使用されます。2017 年 10 月の時点で、迂回は移動時間が車両に依存しない場合にのみサポートされています。

読み込み

訪問を実行する際に、集荷の場合は車両の積載量に事前定義された量が追加され、配達の場合は減算されることがあります。このメッセージでそのような金額を定義します。load_demands をご覧ください。

フィールド
amount

int64

対応する訪問を行う車両の負荷が変動する量。整数であるため、精度が失われないように適切な単位を選択することをおすすめします。0 以上である必要があります。

VisitRequest

車両で訪問できるリクエスト: 地理的位置(または 2 つ、下記参照)、時間枠で表される開店時間と閉店時間、サービス時間(車両が商品の受け取りまたは配達に到着してから費やす時間)があります。

フィールド
arrival_location

LatLng

この VisitRequest を実行したときに車両が到着する地理的位置。配送モデルに所要時間距離行列がある場合、arrival_location を指定することはできません。

arrival_waypoint

Waypoint

この VisitRequest を実行したときに車両が到着する経由地。配送モデルに所要時間距離行列がある場合、arrival_waypoint を指定することはできません。

departure_location

LatLng

この VisitRequest の完了後に車両が出発する地理的位置。arrival_location と同じ場合は省略できます。配送モデルに所要時間距離行列がある場合、departure_location を指定することはできません。

departure_waypoint

Waypoint

この VisitRequest の完了後に車両が出発する経由地。arrival_waypoint と同じ場合は省略できます。配送モデルに所要時間距離行列がある場合、departure_waypoint を指定することはできません。

tags[]

string

アクセス リクエストに付加されたタグを指定します。空の文字列や重複する文字列は使用できません。

time_windows[]

TimeWindow

訪問の到着時刻を制約する時間枠。車両は到着時間枠外に出発する場合があります。つまり、到着時間 + 所要時間が時間枠内である必要はありません。車両が TimeWindow.start_time より前に到着した場合、待ち時間が発生する可能性があります。

TimeWindow がない場合は、車両がいつでもこの訪問を実行できることを意味します。

時間枠は重複しないようにする必要があります。つまり、別の時間枠と重複したり、隣接したりしないようにする必要があります。また、昇順で指定する必要があります。

cost_per_hour_after_soft_end_timesoft_end_time は、時間枠が 1 つの場合にのみ設定できます。

duration

Duration

訪問時間(車両が到着してから出発するまでの時間。待機時間に追加されます。time_windows を参照)。

cost

double

車両ルートでこの訪問リクエストに対応する費用。これは、配送の代替手段ごとに異なる費用を支払うために使用できます。この費用は Shipment.penalty_cost と同じ単位で指定する必要があり、負の値は指定できません。

load_demands

map<string, Load>

この訪問リクエストの需要を読み込みます。これは Shipment.load_demands フィールドと同じですが、Shipment 全体ではなく、この VisitRequest にのみ適用されます。ここに記載されているデマンドは、Shipment.load_demands に記載されているデマンドに追加されます。

visit_types[]

string

訪問のタイプを指定します。これは、車両がこの訪問を完了するために必要な追加時間を割り当てるために使用されることがあります(Vehicle.extra_visit_duration_for_visit_type を参照)。

型は 1 回しか指定できません。

label

string

この VisitRequest のラベルを指定します。このラベルは、対応する ShipmentRoute.Visitvisit_label としてレスポンスで報告されます。

avoid_u_turns

bool

この地点の運転ルートで U ターンを避けるかどうかを指定します。U ターン回避はベスト エフォートであり、完全な回避は保証されません。これは試験運用中の機能であり、動作は変更される可能性があります。

試験運用版: 詳しくは、https://developers.google.com/maps/tt/route-optimization/experimental/u-turn-avoidance/make-request をご覧ください。

ShipmentModel

配送モデルには、一連の車両で実行する必要がある一連の配送が含まれています。全体的な費用(次の合計)を最小限に抑える必要があります。

  • 車両のルート設定の費用(すべての車両の合計時間あたりの費用、移動時間あたりの費用、固定費用の合計)。
  • 未履行の配送に対するペナルティ。
  • 配送のグローバル期間のコスト
フィールド
shipments[]

Shipment

モデルで実行する必要がある配送のセット。

vehicles[]

Vehicle

訪問の実行に使用できる車両のセット。

objectives[]

Objective

このモデルの目標のセット。これは費用に変換されます。空でない場合、入力モデルは無料である必要があります。変更されたリクエストを取得するには、solving_mode = TRANSFORM_AND_RETURN_REQUEST を使用してください。なお、この場合、リクエストは解決されません。対応するドキュメントをご覧ください。

試験運用版: 詳しくは、https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request をご覧ください。

global_start_time

Timestamp

モデルのグローバルな開始時間と終了時間: この範囲外の時間は有効と見なされません。

モデルの期間は 1 年未満にする必要があります。つまり、global_end_timeglobal_start_time の差は 31,536,000 秒以内にする必要があります。

cost_per_*hour フィールドを使用する場合は、パフォーマンスを向上させるために、この期間をより短い間隔に設定することをおすすめします(たとえば、1 日をモデル化する場合は、グローバル時間制限をその日に設定する必要があります)。設定されていない場合、デフォルトとして 1970 年 1 月 1 日 00:00:00 UTC(秒: 0、ナノ秒: 0)が使用されます。

global_end_time

Timestamp

未設定の場合、デフォルトとして 1971 年 1 月 1 日 00:00:00 UTC(秒: 31536000、ナノ秒: 0)が使用されます。

global_duration_cost_per_hour

double

プラン全体の「グローバル期間」は、すべての車両の最も早い有効開始時刻と最も遅い有効終了時刻の差です。ユーザーは、その数量に 1 時間あたりの費用を割り当てて、ジョブの完了を最適化できます。この費用は Shipment.penalty_cost と同じ単位にする必要があります。

duration_distance_matrices[]

DurationDistanceMatrix

モデルで使用される所要時間と距離の行列を指定します。このフィールドが空の場合、use_geodesic_distances フィールドの値に応じて、Google マップまたは測地線距離が代わりに使用されます。空でない場合、use_geodesic_distances は true にできず、duration_distance_matrix_src_tagsduration_distance_matrix_dst_tags のどちらも空にできません。

使用例:

  • locA と locB の 2 つのロケーションがあります。
  • 1 台の車両が locA でルートを開始し、locA で終了します。
  • locB での 1 件の集荷訪問リクエスト。
model {
  vehicles { start_tags: "locA"  end_tags: "locA" }
  shipments { pickups { tags: "locB" } }
  duration_distance_matrix_src_tags: "locA"
  duration_distance_matrix_src_tags: "locB"
  duration_distance_matrix_dst_tags: "locA"
  duration_distance_matrix_dst_tags: "locB"
  duration_distance_matrices {
    rows {  # from: locA
      durations { seconds: 0 }   meters: 0    # to: locA
      durations { seconds: 100 } meters: 1000 # to: locB
    }
    rows {  # from: locB
      durations { seconds: 102 } meters: 990 # to: locA
      durations { seconds: 0 }   meters: 0   # to: locB
    }
  }
}
  • locA、locB、locC の 3 つのロケーションがあります。
  • locA でルートを開始し、locB で終了する 1 台の車両。マトリックス「fast」を使用します。
  • locB でルートを開始し、locB で終了する 1 台の車両。マトリックス「slow」を使用。
  • 1 台の車両が locB でルートを開始し、locB で終了する。マトリックス「fast」を使用する。
  • locC で 1 件の集荷訪問リクエスト。
model {
  vehicles { start_tags: "locA" end_tags: "locB" start_tags: "fast" }
  vehicles { start_tags: "locB" end_tags: "locB" start_tags: "slow" }
  vehicles { start_tags: "locB" end_tags: "locB" start_tags: "fast" }
  shipments { pickups { tags: "locC" } }
  duration_distance_matrix_src_tags: "locA"
  duration_distance_matrix_src_tags: "locB"
  duration_distance_matrix_src_tags: "locC"
  duration_distance_matrix_dst_tags: "locB"
  duration_distance_matrix_dst_tags: "locC"
  duration_distance_matrices {
    vehicle_start_tag: "fast"
    rows {  # from: locA
      durations { seconds: 1000 } meters: 2000 # to: locB
      durations { seconds: 600 }  meters: 1000 # to: locC
    }
    rows {  # from: locB
      durations { seconds: 0 }   meters: 0    # to: locB
      durations { seconds: 700 } meters: 1200 # to: locC
    }
    rows {  # from: locC
      durations { seconds: 702 } meters: 1190 # to: locB
      durations { seconds: 0 }   meters: 0    # to: locC
    }
  }
  duration_distance_matrices {
    vehicle_start_tag: "slow"
    rows {  # from: locA
      durations { seconds: 1800 } meters: 2001 # to: locB
      durations { seconds: 900 }  meters: 1002 # to: locC
    }
    rows {  # from: locB
      durations { seconds: 0 }    meters: 0    # to: locB
      durations { seconds: 1000 } meters: 1202 # to: locC
    }
    rows {  # from: locC
      durations { seconds: 1001 } meters: 1195 # to: locB
      durations { seconds: 0 }    meters: 0    # to: locC
    }
  }
}
duration_distance_matrix_src_tags[]

string

所要時間と距離の行列のソースを定義するタグ。duration_distance_matrices(i).rows(j) は、タグ duration_distance_matrix_src_tags(j) のある訪問から行列 i の他の訪問までの所要時間と距離を定義します。

タグは VisitRequest.tags または Vehicle.start_tags に対応します。指定された VisitRequest または Vehicle は、このフィールドのタグと完全に一致する必要があります。Vehicle の送信元、宛先、マトリックス タグは同じにできます。同様に、VisitRequest の送信元と宛先のタグも同じにできます。すべてのタグは異なっており、空の文字列にすることはできません。このフィールドが空でない場合、duration_distance_matrices は空にできません。

duration_distance_matrix_dst_tags[]

string

時間と距離のマトリックスの宛先を定義するタグ。duration_distance_matrices(i).rows(j).durations(k)(または duration_distance_matrices(i).rows(j).meters(k)) は、行列 i のタグ duration_distance_matrix_src_tags(j) の訪問からタグ duration_distance_matrix_dst_tags(k) の訪問までの移動時間(または距離)を定義します。

タグは VisitRequest.tags または Vehicle.start_tags に対応します。指定された VisitRequest または Vehicle は、このフィールドのタグと完全に一致する必要があります。Vehicle の送信元、宛先、マトリックス タグは同じにできます。同様に、VisitRequest の送信元と宛先のタグも同じにできます。すべてのタグは異なっており、空の文字列にすることはできません。このフィールドが空でない場合、duration_distance_matrices は空にできません。

transition_attributes[]

TransitionAttributes

モデルに追加された移行属性。

shipment_type_incompatibilities[]

ShipmentTypeIncompatibility

互換性のない shipment_type のセット(ShipmentTypeIncompatibility を参照)。

shipment_type_requirements[]

ShipmentTypeRequirement

shipment_type 要件のセット(ShipmentTypeRequirement を参照)。

precedence_rules[]

PrecedenceRule

モデルで適用する必要がある優先順位ルールのセット。

重要: 優先順位ルールを使用すると、最適化できる問題のサイズが制限されます。多くの配送を含む優先順位ルールを使用するリクエストは拒否される可能性があります。

max_active_vehicles

int32

アクティブな車両の最大数を制約します。車両がアクティブになるのは、そのルートで少なくとも 1 回の配送が行われた場合です。これは、車両よりもドライバーの数が少なく、車両のフリートが異種の場合に、ルートの数を制限するために使用できます。最適化により、使用する車両の最適なサブセットが選択されます。真に正である必要があります。

DurationDistanceMatrix

訪問と車両の出発地から訪問と車両の目的地までの所要時間と距離の行列を指定します。

フィールド
rows[]

Row

所要時間と距離のマトリックスの行を指定します。ShipmentModel.duration_distance_matrix_src_tags と同じ数の要素が必要です。

vehicle_start_tag

string

この所要時間と距離のマトリックスが適用される車両を定義するタグ。空の場合、すべての車両に適用され、マトリックスは 1 つのみになります。

各車両の出発地は、1 つの行列と完全に一致する必要があります。つまり、start_tags フィールドの 1 つだけが、行列の vehicle_start_tag(およびその行列のみ)と一致する必要があります。

すべての行列の vehicle_start_tag は異なる必要があります。

所要時間と距離の行列の行を指定します。

フィールド
durations[]

Duration

指定された行の期間の値。ShipmentModel.duration_distance_matrix_dst_tags と同じ数の要素が必要です。

meters[]

double

指定された行の距離の値。モデルで距離を参照する費用や制約がない場合は、空のままにできます。それ以外の場合は、durations と同じ数の要素が必要です。

目標

目標は費用モデルを完全に置き換えるため、既存の費用とは互換性がありません。各目標は、車両、配送、移行属性などの事前定義された費用にマッピングされます。

試験運用版: 詳しくは、https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request をご覧ください。

フィールド
type

Type

目標のタイプ。

weight

double

この目標が他の目標に対してどの程度の重要度を持つか。任意の非負の数値を指定できます。重みの合計が 1 になる必要はありません。重みのデフォルトは 1.0 です。

タイプ

費用のセットにマッピングされる目標タイプ。

列挙型
DEFAULT 妥当なソリューションを確保するため、デフォルトの費用のセットが使用されます。注: この目標は単独で使用できますが、ユーザーが指定した目標にまだ含まれていない場合は、常にベースラインとして重み 1.0 で追加されます。
MIN_DISTANCE 「MIN」目標。合計移動距離を最小限に抑えます。
MIN_WORKING_TIME すべての車両の合計作業時間を最小限に抑えます。
MIN_TRAVEL_TIME 上記と同じですが、移動時間のみに焦点を当てています。
MIN_NUM_VEHICLES 使用する車両の数を最小限に抑えます。

PrecedenceRule

2 つのイベント(各イベントは荷物の集荷または配達)間の優先順位ルール: 「2 番目」のイベントは、「1 番目」のイベントの開始から少なくとも offset_duration 後に開始する必要があります。

複数の優先順位で同じ(または関連する)イベントを参照できます。例: 「B の受け取りは A の配達後」、「C の受け取りは B の受け取り後」などです。

また、優先順位は両方の配送が実行された場合にのみ適用され、それ以外の場合は無視されます。

フィールド
first_is_delivery

bool

「最初」のイベントが配達かどうかを示します。

second_is_delivery

bool

「2 番目」のイベントが配信かどうかを示します。

offset_duration

Duration

「最初」のイベントと「2 番目」のイベントのオフセット。負の値になることもあります。

first_index

int32

「最初」のイベントの配送インデックス。このフィールドは指定する必要があります。

second_index

int32

「2 番目」のイベントの配送インデックス。このフィールドは指定する必要があります。

ShipmentRoute

車両のルートは、時間軸に沿って次のように分解できます(n 回の訪問があると仮定します)。

  |            |            |          |       |  T[2], |        |      |
  | Transition |  Visit #0  |          |       |  V[2], |        |      |
  |     #0     |    aka     |   T[1]   |  V[1] |  ...   | V[n-1] | T[n] |
  |  aka T[0]  |    V[0]    |          |       | V[n-2],|        |      |
  |            |            |          |       | T[n-1] |        |      |
  ^            ^            ^          ^       ^        ^        ^      ^
vehicle    V[0].start   V[0].end     V[1].   V[1].    V[n].    V[n]. vehicle
 start     (arrival)   (departure)   start   end      start    end     end

次の点に注意してください。

  • 車両の開始と終了、各訪問の開始と終了(到着と出発)などの「時間指定イベント」。特定の秒で発生します。
  • 「時間間隔」(訪問自体や訪問間の遷移など)。時間間隔の長さが 0 になることもありますが(開始と終了が同じ秒)、通常は正の長さになります。

不変条件:

  • n 回の訪問がある場合、n+1 回の遷移があります。
  • 訪問は常に、その前の遷移(同じインデックス)と、その後の遷移(インデックス + 1)で囲まれています。
  • 車両の起動後には、常にトランジション #0 が続きます。
  • 車両の終了は常にトランジション #n の前に発生します。

拡大すると、TransitionVisit の間に次の処理が行われます。

---+-------------------------------------+-----------------------------+-->
   |           TRANSITION[i]             |           VISIT[i]          |
   |                                     |                             |
   |  * TRAVEL: the vehicle moves from   |      PERFORM the visit:     |
   |    VISIT[i-1].departure_location to |                             |
   |    VISIT[i].arrival_location, which |  * Spend some time:         |
   |    takes a given travel duration    |    the "visit duration".    |
   |    and distance                     |                             |
   |                                     |  * Load or unload           |
   |  * BREAKS: the driver may have      |    some quantities from the |
   |    breaks (e.g. lunch break).       |    vehicle: the "demand".   |
   |                                     |                             |
   |  * WAIT: the driver/vehicle does    |                             |
   |    nothing. This can happen for     |                             |
   |    many reasons, for example when   |                             |
   |    the vehicle reaches the next     |                             |
   |    event's destination before the   |                             |
   |    start of its time window         |                             |
   |                                     |                             |
   |  * DELAY: *right before* the next   |                             |
   |    arrival. E.g. the vehicle and/or |                             |
   |    driver spends time unloading.    |                             |
   |                                     |                             |
---+-------------------------------------+-----------------------------+-->
   ^                                     ^                             ^
V[i-1].end                           V[i].start                    V[i].end

最後に、移行中に TRAVEL、BREAKS、DELAY、WAIT を配置する方法を説明します。

  • 重複していません。
  • DELAY は一意で、次の訪問(または車両の終了)の直前の連続した期間でなければなりません。したがって、開始時間と終了時間を知るには、遅延期間を知るだけで十分です。
  • BREAKS は、連続した重複しない期間です。レスポンスでは、各ブレークの開始時刻と期間を指定します。
  • TRAVEL と WAIT は「プリエンプト可能」です。この移行中に複数回中断される可能性があります。クライアントは、移動が「できるだけ早く」行われ、「待機」が残りの時間を埋めると想定できます。

(複雑な)例:

                               TRANSITION[i]
--++-----+-----------------------------------------------------------++-->
  ||     |       |           |       |           |         |         ||
  ||  T  |   B   |     T     |       |     B     |         |    D    ||
  ||  r  |   r   |     r     |   W   |     r     |    W    |    e    ||
  ||  a  |   e   |     a     |   a   |     e     |    a    |    l    ||
  ||  v  |   a   |     v     |   i   |     a     |    i    |    a    ||
  ||  e  |   k   |     e     |   t   |     k     |    t    |    y    ||
  ||  l  |       |     l     |       |           |         |         ||
  ||     |       |           |       |           |         |         ||
--++-----------------------------------------------------------------++-->
フィールド
vehicle_index

int32

ルートを実行する車両。ソース ShipmentModel のインデックスで識別されます。

vehicle_label

string

指定されている場合、このルートを実行する車両のラベル(ShipmentModel.vehicles(vehicle_index).label と同じ)。

vehicle_start_time

Timestamp

車両がルートを開始する時刻。

vehicle_end_time

Timestamp

車両がルートを完了する時刻。

visits[]

Visit

ルートを表す訪問の順序付きシーケンス。visits[i] はルート内の i 番目の訪問です。このフィールドが空の場合、車両は未使用と見なされます。

transitions[]

Transition

ルートの遷移の順序付きリスト。

has_traffic_infeasibilities

bool

OptimizeToursRequest.consider_road_traffic が true に設定されている場合、このフィールドは、交通状況に基づく移動時間の推定値を使用してルートのタイミングの不整合が予測されることを示します。訪問と車両の時間枠を満たしながら、最初の訪問前または最後の訪問後に、訪問間の交通状況に応じた移動、遅延、休憩を完了するのに十分な時間がない場合があります。次に例を示します。

  start_time(previous_visit) + duration(previous_visit) +
  travel_duration(previous_visit, next_visit) > start_time(next_visit)

交通状況により移動時間の推定値 travel_duration(previous_visit, next_visit) が増加したため、next_visit への到着は現在の時間枠よりも遅れる可能性があります。また、移動時間の見積もりが増加し、訪問時間または休憩時間のウィンドウの制限により、休憩が訪問と重複する可能性があります。

route_polyline

EncodedPolyline

ルートのエンコードされたポリライン表現。このフィールドは、OptimizeToursRequest.populate_polylines が true に設定されている場合にのみ入力されます。

breaks[]

Break

このルートを実行する車両の休憩予定。breaks シーケンスは時間間隔を表します。各間隔は対応する start_time で始まり、duration 秒間続きます。

metrics

AggregatedMetrics

このルートの所要時間、距離、負荷の指標。AggregatedMetrics のフィールドは、コンテキストに応じて、すべての ShipmentRoute.transitions または ShipmentRoute.visits で合計されます。

vehicle_fullness

VehicleFullness

上限付き指標がそれぞれの車両の上限にどの程度近いかを計算するための VehicleFullness フィールド。このフィールドは、上限付き指標フィールド(AggregatedMetrics.travel_distance_meters など)と関連する車両制限(Vehicle.route_distance_limit など)の比率です。

試験運用版: このフィールドの動作または存在は、今後変更される可能性があります。

route_costs

map<string, double>

ルートの費用。費用関連のリクエスト フィールド別に分類されます。キーは、入力 OptimizeToursRequest に相対的な proto パス(例: 「model.shipments.pickups.cost」)で、値は対応する費用フィールドによって生成された合計費用で、ルート全体で集計されます。つまり、costs["model.shipments.pickups.cost"] は、ルート上のすべての集荷費用の合計です。モデルで定義されたすべての費用がここに詳細にレポートされます。ただし、2022 年 1 月の時点では、TransitionAttributes に関連する費用は集計された形でしかレポートされません。

route_total_cost

double

ルートの合計費用。費用マップ内のすべての費用の合計。

休憩

休憩の実行を表すデータ。

フィールド
start_time

Timestamp

休憩の開始時間。

duration

Duration

休憩の長さ。

EncodedPolyline

ポリラインのエンコードされた表現。ポリライン エンコードの詳細については、https://developers.google.com/maps/documentation/utilities/polylinealgorithm https://developers.google.com/maps/documentation/javascript/reference/geometry#encoding をご覧ください。

フィールド
points

string

ポリラインのエンコードされた点を表す文字列。

移行

ルート上の 2 つのイベント間の遷移。ShipmentRoute の説明をご覧ください。

車両に start_locationend_location がない場合、対応する移動距離の指標は 0 になります。

フィールド
travel_duration

Duration

この移行期間中の移動時間。

travel_distance_meters

double

移行中に移動した距離。

traffic_info_unavailable

bool

OptimizeToursRequest.consider_road_traffic 経由で交通情報がリクエストされ、Transition の交通情報を取得できなかった場合、このブール値は true に設定されます。これは一時的なもの(リアルタイムの交通情報サーバーのまれなエラー)である場合もあれば、永続的なもの(この場所のデータがない)である場合もあります。

delay_duration

Duration

このトランジションに適用された遅延時間の合計。遅延がある場合、次のイベント(訪問または車両の終了)の delay_duration 秒前に開始します。TransitionAttributes.delayをご確認ください。

break_duration

Duration

この切り替え中に発生した休憩時間の合計(ある場合)。各休憩の開始時間と継続時間に関する詳細は、ShipmentRoute.breaks に保存されます。

wait_duration

Duration

この移行中に待機した時間。待機時間はアイドル時間に対応しており、休憩時間は含まれません。また、この待機時間は複数の連続しない間隔に分割される場合があります。

total_duration

Duration

便宜上、移行の合計時間も提供されます。これは次と同等です。

  • 次の訪問 start_time(これが最後の遷移の場合は vehicle_end_time) - この遷移の start_time
  • ShipmentRoute.has_traffic_infeasibilities が false の場合、さらに `total_duration = travel_duration + delay_duration` が成り立ちます。
  • break_duration + wait_duration`。
start_time

Timestamp

この遷移の開始時間。

route_polyline

EncodedPolyline

遷移中にたどったルートのエンコードされたポリライン表現。このフィールドは、populate_transition_polylines が true に設定されている場合にのみ入力されます。

route_token

string

出力専用。Navigation SDK に渡して、ナビゲーション中にルートを再構築できる不透明なトークン。ルートが作成されたときに、ルート変更が発生した場合に元の意図を尊重します。このトークンは不透明な blob として扱います。サービスがまったく同じルートを返した場合でも、値が変更される可能性があるため、リクエスト間で値を比較しないでください。このフィールドは、populate_transition_polylines が true に設定されている場合にのみ入力されます。

vehicle_loads

map<string, VehicleLoad>

この移行中の車両の積載量。この車両の Vehicle.load_limits に表示されるか、このルートで実行された一部の配送で Shipment.load_demands がゼロ以外の値になっている各タイプ。

最初のトランジションの負荷は、車両ルートの開始負荷です。その後、各訪問の load_demands は、訪問が集荷か配達かに応じて、次のトランジションの負荷を取得するために加算または減算されます。

VehicleLoad

特定のタイプ(Transition.vehicle_loads を参照)について、ルート上の特定の時点での車両の実際の積載量を報告します。

フィールド
amount

int64

特定の種類の車両の積載量。通常、負荷の単位は型で示されます。Transition.vehicle_loads をご覧ください。

アクセス

ルート中に実施された訪問。この訪問は、Shipment の集荷または配送に対応しています。

フィールド
shipment_index

int32

ソース ShipmentModelshipments フィールドのインデックス。

is_pickup

bool

true の場合、訪問は Shipment の受け取りに対応します。それ以外の場合は、配達に対応します。

visit_request_index

int32

Shipment の受け取りまたは配達フィールドの VisitRequest のインデックス(is_pickup を参照)。

start_time

Timestamp

訪問が開始された時刻。車両は、この時間よりも早く訪問場所に到着する可能性があります。時間は ShipmentModel と一致しています。

load_demands

map<string, Load>

配送と訪問リクエストの load_demands の合計として、訪問負荷の合計需要。訪問が配達の場合、値は負になります。デマンドは Transition.loads と同じタイプでレポートされます(このフィールドを参照)。

detour

Duration

訪問前にルート上の配送先を訪問したことと、時間枠によって発生する可能性のある待ち時間による迂回時間の増加。配達の場合、迂回は対応する集荷から計算され、次のようになります。

start_time(delivery) - start_time(pickup)
- (duration(pickup) + travel duration from the pickup location
to the delivery location).

それ以外の場合は、車両の start_location から計算され、次のようになります。

start_time - vehicle_start_time - travel duration from
the vehicle's `start_location` to the visit.
shipment_label

string

Shipment で指定されている場合は、対応する Shipment.label のコピー。

visit_label

string

VisitRequest で指定されている場合は、対応する VisitRequest.label のコピー。

injected_solution_location_token

int32

訪問場所に関する情報を表す不透明なトークン。

このフィールドは、この訪問で VisitRequest.avoid_u_turns が true に設定されている場合、またはリクエスト OptimizeToursRequestShipmentModel.avoid_u_turns が true に設定されている場合に、結果ルートの訪問で入力されることがあります。

試験運用版: 詳しくは、https://developers.google.com/maps/tt/route-optimization/experimental/u-turn-avoidance/make-request をご覧ください。

ShipmentTypeIncompatibility

shipment_type に応じて、配送間の非互換性を指定します。同じルートに互換性のない配送が表示されるのは、互換性のないモードに基づいて制限されます。

フィールド
types[]

string

互換性のないタイプのリスト。リストにある shipment_types が異なる 2 つの出荷は「互換性がない」と見なされます。

incompatibility_mode

IncompatibilityMode

非互換性に適用されるモード。

IncompatibilityMode

同じルートで互換性のない配送の表示を制限する方法を定義するモード。

列挙型
INCOMPATIBILITY_MODE_UNSPECIFIED 互換モードが指定されていません。この値は使用しないでください。
NOT_PERFORMED_BY_SAME_VEHICLE このモードでは、互換性のない 2 つの配送が同じ車両を共有することはありません。
NOT_IN_SAME_VEHICLE_SIMULTANEOUSLY

このモードでは、互換性のない 2 つの配送が同時に同じ車両に積載されることはありません。

  • 同じ車両を共有できるのは、一方の車両が納車されてから他方の車両が引き取りにくる場合のみです。
  • 両方の配送が受け取りのみ(配達なし)または配達のみ(受け取りなし)の場合、同じ車両を共有することはできません。

ShipmentTypeRequirement

shipment_type に基づいて、配送間の要件を指定します。要件の詳細は、要件モードによって定義されます。

フィールド
required_shipment_type_alternatives[]

string

dependent_shipment_types で必要な代替配送タイプのリスト。

dependent_shipment_types[]

string

dependent_shipment_types フィールドにタイプが指定されているすべての配送では、同じルートでタイプ required_shipment_type_alternatives の配送を少なくとも 1 回訪問する必要があります。

注: shipment_type がそれ自体に依存するような要件のチェーンは許可されません。

requirement_mode

RequirementMode

要件に適用されるモード。

RequirementMode

ルート上の依存する配送の表示を定義するモード。

列挙型
REQUIREMENT_MODE_UNSPECIFIED 要件モードが指定されていません。この値は使用しないでください。
PERFORMED_BY_SAME_VEHICLE このモードでは、すべての「依存」配送で、少なくとも 1 つの「必須」配送と同じ車両を使用する必要があります。
IN_SAME_VEHICLE_AT_PICKUP_TIME

IN_SAME_VEHICLE_AT_PICKUP_TIME モードでは、すべての「依存」発送で、集荷時に車両に少なくとも 1 つの「必須」発送が必要です。

したがって、「依存」する配送の集荷には、次のいずれかが必要です。

  • 配達のみの「必須」の配送が、ルートの後に配達された場合。
  • 「必須」の配送がその前にルートで集荷され、「必須」の配送に配達がある場合、この配達は「依存」の配送の集荷後に行う必要があります。
IN_SAME_VEHICLE_AT_DELIVERY_TIME 以前と同じですが、「依存」する配送は、配送時に車両に「必須」の配送がある必要があります。

SkippedShipment

ソリューションで実行されていない配送の詳細を指定します。些細なケースや、スキップの原因を特定できた場合は、その理由をここに報告します。

フィールド
index

int32

インデックスは、移行元 ShipmentModel の配送のインデックスに対応します。

label

string

Shipment で指定されている場合は、対応する Shipment.label のコピー。

reasons[]

Reason

配送がスキップされた理由を説明する理由のリスト。Reason の上のコメントを参照してください。配送がスキップされた理由を特定できない場合は、理由が設定されません。

penalty_cost

double

これは Shipment.penalty_cost のコピーです。スキップされた配送の重大度を簡単に確認できるようにするために、ここに含めました。

試験運用版: このフィールドの動作または存在は、今後変更される可能性があります。

estimated_incompatible_vehicle_ratio

double

以下の理由のいずれかにより、この配送を行えない車両の推定比率。注: これは、理由に車両が含まれる場合にのみ入力します。

試験運用版: このフィールドの動作または存在は、今後変更される可能性があります。

理由

配送がスキップされた理由を説明できる場合は、ここに理由が表示されます。すべての車両で理由が同じでない場合、reason には複数の要素が含まれます。スキップされた配送に重複する理由(example_vehicle_index 以外のすべてのフィールドが同じ)を指定することはできません。例:

reasons {
  code: DEMAND_EXCEEDS_VEHICLE_CAPACITY
  example_vehicle_index: 1
  example_exceeded_capacity_type: "Apples"
}
reasons {
  code: DEMAND_EXCEEDS_VEHICLE_CAPACITY
  example_vehicle_index: 3
  example_exceeded_capacity_type: "Pears"
}
reasons {
  code: CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DISTANCE_LIMIT
  example_vehicle_index: 1
}

スキップされた配送はすべての車両と互換性がありません。理由は車両ごとに異なる可能性がありますが、少なくとも 1 台の車両(車両 1 を含む)の「リンゴ」の容量が超過し、少なくとも 1 台の車両(車両 3 を含む)の「梨」の容量が超過し、少なくとも 1 台の車両(車両 1 を含む)の距離制限が超過します。

フィールド
code

Code

コードのコメントを参照してください。

example_vehicle_indices[]

int32

example_vehicle_index と同じですが、複数の識別された車両のリストを提供します。このリストはすべてを網羅したものではありません。これは、[fill_example_vehicle_indices_in_skipped_reasons][] が true の場合にのみ入力されます。

試験運用版: このフィールドの動作または存在は、今後変更される可能性があります。

example_exceeded_capacity_type

string

理由コードが DEMAND_EXCEEDS_VEHICLE_CAPACITY の場合は、超過した容量タイプを 1 つ文書化します。

example_vehicle_index

int32

理由が荷物と車両の互換性に関連している場合、このフィールドには関連する車両のインデックスが指定されます。

コード

理由のタイプを識別するコード。この順序は意味がありません。特に、両方の理由が該当する場合に、どちらの理由がソリューションで先に表示されるかについては示されません。

列挙型
CODE_UNSPECIFIED これは使用しないでください。
NO_VEHICLE モデルに、すべての配送を不可能にする車両がない。
DEMAND_EXCEEDS_VEHICLE_CAPACITY 一部の容量タイプ(example_exceeded_capacity_type など)で、配送の需要が車両の容量を超えています。
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DISTANCE_LIMIT

この配送を行うために必要な最小距離(車両の start_location から配送の集荷場所や配達場所、車両の最終目的地までの距離)が、車両の route_distance_limit を超えている。

この計算では、測地線距離を使用します。

CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT

この配送を行うために必要な最小時間(移動時間、待ち時間、サービス時間を含む)が、車両の route_duration_limit を超えています。

注: 所要時間は、最良のシナリオ(測地線距離 × 36 m/秒(約 130 km/時))で計算されます。

CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TRAVEL_DURATION_LIMIT 上記と同じですが、移動時間の最小値と車両の travel_duration_limit のみを比較します。
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TIME_WINDOWS 車両が最も早い開始時刻に開始した場合、この配送を最良のシナリオで実行することはできません(時間の計算については CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT を参照)。合計時間が、車両の最も遅い終了時刻を超えてしまうためです。
VEHICLE_NOT_ALLOWED 配送の allowed_vehicle_indices フィールドが空ではなく、この車両がその配送に属していない。
VEHICLE_IGNORED

車両の ignore フィールドが true である。

試験運用版: このフィールドの動作または存在は、今後変更される可能性があります。

SHIPMENT_IGNORED

配送の ignore フィールドが true である。

試験運用版: このフィールドの動作または存在は、今後変更される可能性があります。

SKIPPED_IN_INJECTED_SOLUTION_CONSTRAINT

injected_solution_constraint で配送がスキップされます。

試験運用版: このフィールドの動作または存在は、今後変更される可能性があります。

VEHICLE_ROUTE_IS_FULLY_SEQUENCE_CONSTRAINED

injected_solution_constraint で指定された車両ルートの緩和では、訪問の挿入が許可されていません。

試験運用版: このフィールドの動作または存在は、今後変更される可能性があります。

ZERO_PENALTY_COST

この配送にはペナルティ費用は発生しません。これは高度なモデリングの選択肢として役立つだけでなく、後から配送がスキップされた理由を説明するのにも役立ちます。

試験運用版: このフィールドの動作または存在は、今後変更される可能性があります。

TimeWindow

時間枠は、訪問の到着時間や車両の開始時間と終了時間など、イベントの時間を制約します。

ハード タイム ウィンドウの境界 start_timeend_time は、イベントの最も早い時刻と最も遅い時刻を強制します(start_time <= event_time <= end_time)。ソフト時間枠の下限 soft_start_time は、イベントが soft_start_time 以降に発生することを優先し、soft_start_time より前にイベントが発生した時間に応じてコストが発生することを表します。ソフト時間枠の上限 soft_end_time は、イベントが soft_end_time 以降に発生した場合に、その遅延時間に比例したコストが発生することで、イベントが soft_end_time 以前に発生することを優先的に表します。start_timeend_timesoft_start_timesoft_end_time は、グローバルな時間制限(ShipmentModel.global_start_timeShipmentModel.global_end_time を参照)内に収まる必要があり、次の点を考慮する必要があります。

  0 <= `start_time` <= `end_time` and
  0 <= `start_time` <= `soft_start_time` and
  0 <= `soft_end_time` <= `end_time`.
フィールド
start_time

Timestamp

ハード時間枠の開始時間。指定しない場合、ShipmentModel.global_start_time に設定されます。

end_time

Timestamp

ハード時間枠の終了時間。指定しない場合、ShipmentModel.global_end_time に設定されます。

soft_start_time

Timestamp

時間枠のソフト開始時間。

soft_end_time

Timestamp

時間枠のソフト終了時刻。

cost_per_hour_before_soft_start_time

double

イベントが soft_start_time より前に発生した場合に、モデルの他の費用に追加される 1 時間あたりの費用。次のように計算されます。

   max(0, soft_start_time - t.seconds)
                          * cost_per_hour_before_soft_start_time / 3600,
t being the time of the event.

この費用は正の値にする必要があります。このフィールドは、soft_start_time が設定されている場合にのみ設定できます。

cost_per_hour_after_soft_end_time

double

イベントが soft_end_time の後に発生した場合にモデルの他の費用に追加される 1 時間あたりの費用。次のように計算されます。

   max(0, t.seconds - soft_end_time.seconds)
                    * cost_per_hour_after_soft_end_time / 3600,
t being the time of the event.

この費用は正の値でなければなりません。また、このフィールドは soft_end_time が設定されている場合にのみ設定できます。

TransitionAttributes

ルート上の 2 つの連続する訪問間の移行の属性を指定します。同じトランジションに複数の TransitionAttributes が適用されることがあります。その場合、すべての追加費用が加算され、最も厳しい制約または上限が適用されます(自然な「AND」セマンティクスに従います)。

フィールド
src_tag

string

これらの属性が適用される(src->dst)遷移のセットを定義するタグ。

ソース訪問または車両の始動は、VisitRequest.tags または Vehicle.start_tags のいずれかに src_tag が含まれているか、excluded_src_tag が含まれていない場合に一致します(これらの 2 つのフィールドのどちらが空でないかによって異なります)。

excluded_src_tag

string

src_tag をご覧ください。src_tagexcluded_src_tag のいずれか 1 つのみが空でない必要があります。

dst_tag

string

VisitRequest.tags または Vehicle.end_tags のいずれかに dst_tag が含まれているか、excluded_dst_tag が含まれていない場合(これらの 2 つのフィールドのどちらが空でないかによって異なります)、目的地への訪問または車両の終了が一致します。

excluded_dst_tag

string

dst_tag をご覧ください。dst_tagexcluded_dst_tag のいずれか 1 つのみが空でない必要があります。

cost

double

このトランジションの実行コストを指定します。これはモデル内の他のすべての費用と同じ単位で、負の値にすることはできません。これは、他の既存のすべての費用に加えて適用されます。

cost_per_kilometer

double

このトランジションの実行中に移動した距離に適用される 1 キロメートルあたりの費用を指定します。車両に指定された Vehicle.cost_per_kilometer まで追加されます。

distance_limit

DistanceLimit

この遷移の実行中に移動する距離の上限を指定します。

2021 年 6 月の時点で、ソフト上限のみがサポートされています。

delay

Duration

このトランジションの実行時に発生する遅延を指定します。

この遅延は、常に参照元サイトへのアクセスが終了した、リンク先サイトへのアクセスが開始されるに発生します。

URI

Route Optimization API で読み取りと書き込みが可能なリソースを指すユニバーサル リソース識別子。

フィールド
uri

string

リソースの URI。リソースがまだ存在していない可能性があります。

リソースの内容は JSON または textproto としてエンコードされます。Google Cloud Storage リソースのみがサポートされています。リソースが JSON としてエンコードされている場合、リソース名の末尾に .json を付ける必要があります。リソースが textproto としてエンコードされている場合、リソース名の末尾に .txtpb を付ける必要があります。たとえば、JSON エンコード ファイルの Google Cloud Storage URI は gs://bucket/path/input/object.json のようになります。

車両

配送に関する問題の車両をモデル化します。配送の問題を解決すると、この車両の start_location から end_location までのルートが作成されます。ルートは訪問のシーケンスです(ShipmentRoute を参照)。

フィールド
display_name

string

車両のユーザー定義の表示名。最大 63 文字で、UTF-8 文字を使用できます。

travel_mode

TravelMode

車両が走行可能な道路とその速度に影響する移動モード。travel_duration_multiple もご覧ください。

route_modifiers

RouteModifiers

指定された車両のルートの計算方法に影響する、満たすべき条件のセット。

start_location

LatLng

車両が荷物を集荷する前に出発する地理的な場所。指定しない場合、車両は最初の乗車場所から開始します。配送モデルに所要時間と距離の行列がある場合、start_location は指定できません。

start_waypoint

Waypoint

車両が荷物を集荷する前に出発する地理的位置を表す経由地。start_waypointstart_location のどちらも指定されていない場合、車両は最初の乗車地点から出発します。配送モデルに所要時間と距離の行列がある場合、start_waypoint は指定できません。

end_location

LatLng

車両が最後の VisitRequest を完了した後の地理的位置。指定されていない場合、車両の ShipmentRoute は最後の VisitRequest が完了するとすぐに終了します。配送モデルに所要時間と距離の行列がある場合、end_location は指定できません。

end_waypoint

Waypoint

車両が最後の VisitRequest を完了した後に停止する地理的位置を表す経由地。end_waypointend_location のいずれも指定されていない場合、車両の ShipmentRoute は最後の VisitRequest を完了するとすぐに終了します。配送モデルに所要時間と距離の行列がある場合、end_waypoint は指定できません。

start_tags[]

string

車両のルートの開始位置に付加されるタグを指定します。

空の文字列や重複する文字列は使用できません。

end_tags[]

string

車両のルートの末尾に付加されるタグを指定します。

空の文字列や重複する文字列は使用できません。

start_time_windows[]

TimeWindow

車両が出発地を出発できる時間帯。グローバル タイムアウトの範囲内である必要があります(ShipmentModel.global_* フィールドを参照)。指定しない場合、グローバルな時間制限以外に制限はありません。

同じ繰り返しフィールドに属する時間枠は、互いに重複したり隣接したりしないように、時系列順に並べる必要があります。

cost_per_hour_after_soft_end_timesoft_end_time は、時間枠が 1 つの場合にのみ設定できます。

end_time_windows[]

TimeWindow

車両が最終目的地に到着する可能性のある時間帯。グローバル タイムアウトの範囲内である必要があります(ShipmentModel.global_* フィールドを参照)。指定しない場合、グローバルな時間制限以外に制限はありません。

同じ繰り返しフィールドに属する時間枠は、互いに重複したり隣接したりしないように、時系列順に並べる必要があります。

cost_per_hour_after_soft_end_timesoft_end_time は、時間枠が 1 つの場合にのみ設定できます。

unloading_policy

UnloadingPolicy

車両に適用される荷降ろしポリシー。

load_limits

map<string, LoadLimit>

車両の容量(重量、容積、パレット数など)。マップ内のキーは、Shipment.load_demands フィールドのキーと一致する、負荷のタイプの識別子です。このマップに特定のキーがない場合、対応する容量は無制限とみなされます。

cost_per_hour

double

車両費用: すべての費用を合計し、Shipment.penalty_cost と同じ単位にする必要があります。

車両ルートの 1 時間あたりの費用。この費用はルートの合計時間に適用され、移動時間、待ち時間、訪問時間が含まれます。cost_per_traveled_hour だけでなく cost_per_hour を使用すると、レイテンシが増加する可能性があります。

cost_per_traveled_hour

double

車両ルートの走行時間あたりの費用。この費用は、ルートの移動時間(ShipmentRoute.transitions で報告される時間)にのみ適用され、待ち時間と訪問時間は除外されます。

cost_per_kilometer

double

車両ルートの 1 キロメートルあたりの費用。この費用は ShipmentRoute.transitions で報告された距離に適用され、単一の VisitRequestarrival_location から departure_location まで暗黙的に移動した距離には適用されません。

fixed_cost

double

この車両が配送の処理に使用された場合に適用される固定費用。

used_if_route_is_empty

bool

このフィールドは、ルートに配送がない場合にのみ車両に適用されます。この場合、車両が使用済みと見なされるかどうかを示します。

true の場合、車両は荷物を配達しなくても出発地から目的地まで移動し、出発地から目的地までの移動による時間と距離のコストが考慮されます。

それ以外の場合、車両は出発地から目的地まで移動せず、この車両の break_rule や遅延(TransitionAttributes から)はスケジュールされません。この場合、車両の ShipmentRoute には、車両のインデックスとラベル以外の情報は含まれません。

route_duration_limit

DurationLimit

車両のルートの合計時間に適用される制限。特定の OptimizeToursResponse における車両のルート時間は、vehicle_end_timevehicle_start_time の差です。

travel_duration_limit

DurationLimit

車両のルートの移動時間に適用される制限。特定の OptimizeToursResponse では、ルートの移動時間はすべての transitions.travel_duration の合計です。

route_distance_limit

DistanceLimit

車両のルートの合計距離に適用される制限。特定の OptimizeToursResponse では、ルート距離はすべての transitions.travel_distance_meters の合計です。

extra_visit_duration_for_visit_type

map<string, Duration>

visit_types 文字列から期間へのマップを指定します。期間は、指定された visit_types での訪問時に VisitRequest.duration に加えてかかる時間です。この追加の訪問時間により、cost_per_hour が指定されている場合は費用が増加します。キー(visit_types など)は空の文字列にできません。

訪問リクエストに複数のタイプがある場合、マップ内の各タイプに期間が追加されます。

break_rule

BreakRule

この車両に適用される休憩スケジュールを説明します。空の場合、この車両の休憩はスケジュールされません。

label

string

この車両のラベルを指定します。このラベルは、対応する ShipmentRoutevehicle_label としてレスポンスで報告されます。

ignore

bool

true の場合、used_if_route_is_empty は false にする必要があります。この車両は未使用のままになります。

injected_first_solution_routes で無視された車両で配送が行われた場合、最初のソリューションではスキップされますが、レスポンスでは自由に行うことができます。

injected_solution_constraint で無視された車両によって配送が行われ、関連する集荷/配達が車両に残るように制約されている場合(つまり、レベル RELAX_ALL_AFTER_THRESHOLD に緩和されていない場合)、レスポンスでスキップされます。配送に空でない allowed_vehicle_indices フィールドがあり、許可されているすべての車両が無視される場合、レスポンスでスキップされます。

travel_duration_multiple

double

この車両の移動時間を増減するために使用できる乗数を指定します。たとえば、この値を 2.0 に設定すると、この車両は標準車両の 2 倍の移動時間を要する低速車両になります。この倍率はセッション時間には影響しません。cost_per_hour または cost_per_traveled_hour が指定されている場合は、費用に影響します。この値は [0.001, 1000.0] の範囲内である必要があります。設定しない場合、車両は標準とみなされ、この倍率は 1.0 とみなされます。

警告: 移動時間は、この倍数が適用された後、数値演算の前に最も近い秒に丸められます。そのため、倍数が小さいと精度が低下する可能性があります。

下記の extra_visit_duration_for_visit_type もご覧ください。

DurationLimit

車両のルートの最大所要時間を定義する上限。ハードまたはソフトのいずれかになります。

ソフト上限フィールドが定義されている場合は、ソフト上限のしきい値と関連する費用を両方とも定義する必要があります。

フィールド
max_duration

Duration

期間を最大 max_duration に制限するハードリミット。

soft_max_duration

Duration

最大期間の制限は適用されませんが、違反するとルートに費用が発生するソフト制限。この費用は、モデルで定義された他の費用と同じ単位で合計されます。

定義する場合、soft_max_duration は負以外にする必要があります。max_duration も定義されている場合、soft_max_duration は max_duration より小さくする必要があります。

quadratic_soft_max_duration

Duration

最大所要時間の上限を強制しないが、違反すると、所要時間の 2 乗に比例したコストが発生する上限。この費用は、モデルで定義された他の費用と同じ単位で合計されます。

定義する場合、quadratic_soft_max_duration は負以外にする必要があります。max_duration も定義されている場合、quadratic_soft_max_durationmax_duration より小さく、差は 1 日以下である必要があります。

max_duration - quadratic_soft_max_duration <= 86400 seconds

cost_per_hour_after_soft_max

double

soft_max_duration のしきい値を超えた場合に発生する 1 時間あたりの費用。期間がしきい値未満の場合、追加費用は 0 です。それ以外の場合、費用は期間に応じて次のように異なります。

  cost_per_hour_after_soft_max * (duration - soft_max_duration)

費用は負の値にできません。

cost_per_square_hour_after_quadratic_soft_max

double

quadratic_soft_max_duration のしきい値を超えた場合に発生する 1 平方時間あたりの費用。

期間がしきい値未満の場合、追加費用は 0 です。それ以外の場合、費用は期間に応じて次のように異なります。

  cost_per_square_hour_after_quadratic_soft_max *
  (duration - quadratic_soft_max_duration)^2

費用は負の値にできません。

LoadLimit

車両に適用される積載制限を定義します(例: 「このトラックは 3, 500 kg までしか積載できません」)。load_limits をご覧ください。

フィールド
soft_max_load

int64

負荷のソフトリミット。cost_per_unit_above_soft_max をご覧ください。

cost_per_unit_above_soft_max

double

この車両のルートに沿って積載量が soft_max_load を超えた場合、次のコスト ペナルティが適用されます(車両ごとに 1 回のみ)。(積載量 - soft_max_load)* cost_per_unit_above_soft_max。すべての費用は合計され、Shipment.penalty_cost と同じ単位で指定する必要があります。ソフト上限は、モデル全体で受け取りのみまたは配達のみに適用されるタイプでのみ定義できます。

start_load_interval

Interval

ルートの開始時の車両の許容可能な積載間隔。

end_load_interval

Interval

ルートの終点における車両の許容可能な積載間隔。

max_load

int64

許容できる最大負荷量。

cost_per_kilometer

LoadCost

この車両で 1 単位の荷物を 1 km 運ぶための費用。これは燃料消費量のプロキシとして使用できます。負荷が重量(ニュートン単位)の場合、負荷 × キロメートルはエネルギーの次元を持ちます。

試験運用版: 詳しくは、https://developers.google.com/maps/tt/route-optimization/experimental/load-cost/make-request をご覧ください。

cost_per_traveled_hour

LoadCost

この車両で 1 時間に 1 単位の荷物を運ぶ費用。

試験運用版: 詳しくは、https://developers.google.com/maps/tt/route-optimization/experimental/load-cost/make-request をご覧ください。

間隔

許容可能な負荷量の間隔。

フィールド
min

int64

許容できる最小負荷。0 以上である必要があります。両方が指定されている場合、minmax 以下である必要があります。

max

int64

許容できる最大負荷。0 以上である必要があります。指定されていない場合、このメッセージによる最大負荷の制限はありません。両方が指定されている場合、minmax 以下である必要があります。

LoadCost

Transition 中に 1 単位の負荷を移動するコスト。特定の負荷に対する費用は、次の 2 つの部分の合計です。

  • min(load, load_threshold) * cost_per_unit_below_threshold
  • max(0, load - load_threshold) * cost_per_unit_above_threshold

このコストにより、ソリューションは需要の高いものを優先的に配送するか、需要の高いものを最後に集荷します。たとえば、車両に

load_limit {
  key: "weight"
  value {
    cost_per_kilometer {
      load_threshold: 15
      cost_per_unit_below_threshold: 2.0
      cost_per_unit_above_threshold: 10.0
    }
  }
}

ルートは start、pickup、pickup、delivery、delivery、end で、次のように遷移します。

transition { vehicle_load['weight'] { amount: 0 }
             travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
             travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 20 }
             travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
             travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 0 }
             travel_distance_meters: 1000.0 }

この LoadCost で発生する費用は(cost_below * load_below * kilometers + cost_above * load_above * kms)になります。

  • transition 0: 0.0
  • 遷移 1: 2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
  • 遷移 2: 2.0 * 15 * 1.0 + 10.0 * (20 - 15) * 1.0 = 80.0
  • transition 3: 2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
  • transition 4: 0.0

したがって、ルート上の LoadCost は 120.0 です。

ただし、ルートが start,pickup,delivery,pickup,delivery,end で、トランジションがある場合は、

transition { vehicle_load['weight'] { amount: 0 }
             travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
             travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 0 }
             travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
             travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 0 }
             travel_distance_meters: 1000.0 }

この LoadCost で発生する費用は

  • transition 0: 0.0
  • 遷移 1: 2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
  • transition 2: 0.0
  • transition 3: 2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
  • transition 4: 0.0

このルートの LoadCost は 40.0 です。

LoadCost を使用すると、移行の負荷が高いソリューションの費用が高くなります。

試験運用版: 詳しくは、https://developers.google.com/maps/tt/route-optimization/experimental/load-cost/make-request をご覧ください。

フィールド
load_threshold

int64

単位の負荷を移動する費用が cost_per_unit_below_threshold から cost_per_unit_above_threshold に変化する負荷の量。0 以上である必要があります。

cost_per_unit_below_threshold

double

0 からしきい値までの各単位の負荷を移動する費用。有限値で、0 以上である必要があります。

cost_per_unit_above_threshold

double

しきい値を超える単位あたりの負荷を移動する費用。特殊なケースとして、しきい値が 0 の場合は、単位あたりの固定費になります。有限値で、0 以上である必要があります。

TravelMode

車両で使用できる移動手段。

これらは Google Maps Platform Routes API の移動手段のサブセットである必要があります。https://developers.google.com/maps/documentation/routes/reference/rest/v2/RouteTravelMode をご覧ください。

注: WALKING ルートはベータ版であり、明確な歩道や歩行者用道路がない場合があります。アプリに表示するすべての徒歩ルートについて、この警告をユーザーに表示する必要があります。

列挙型
TRAVEL_MODE_UNSPECIFIED 移動手段が指定されていません(DRIVING と同等)。
DRIVING 運転ルートに対応する移動手段(車など)。
WALKING 徒歩経路に対応する移動手段。

UnloadingPolicy

車両の荷降ろし方法に関するポリシー。集荷と配送の両方がある荷物にのみ適用されます。

その他の出荷は、unloading_policy に関係なく、ルート上の任意の場所で発生する可能性があります。

列挙型
UNLOADING_POLICY_UNSPECIFIED 荷降ろしポリシーが指定されていません。配達は、対応する集荷の後にのみ行う必要があります。
LAST_IN_FIRST_OUT 配達は集荷の逆順で行う必要があります
FIRST_IN_FIRST_OUT 配達は集荷と同じ順序で行う必要があります

VehicleFullness

VehicleFullness は、車両の空き状況を計算する指標です。各 VehicleFullness フィールドは 0 ~ 1 の範囲で、上限付きの指標フィールド(AggregatedMetrics.travel_distance_meters など)と関連する車両制限(Vehicle.route_distance_limit など)の比率として計算されます(存在する場合)。それ以外の場合、充実度比率は設定されません。上限が 0 の場合、フィールドは 1 に設定されます。注: ルートが交通の実行不可能性の影響を受ける場合、一部の生の充足率が 1.0 を超えることがあります(車両が距離制限を超えるなど)。このような場合、満腹度の値は 1.0 に制限されます。

フィールド
max_fullness

double

このメッセージ内の他のすべてのフィールドの最大値。

distance

double

AggregatedMetrics.travel_distance_metersVehicle.route_distance_limit の比率。Vehicle.route_distance_limit が設定されていない場合、このフィールドは設定されません。

travel_duration

double

[AggregatedMetrics.travel_duration_seconds][] と Vehicle.travel_duration_limit の比率。Vehicle.travel_duration_limit が設定されていない場合、このフィールドは設定されません。

active_duration

double

[AggregatedMetrics.total_duration_seconds][] と Vehicle.route_duration_limit の比率。Vehicle.route_duration_limit が設定されていない場合、このフィールドは設定されません。

max_load

double

すべてのタイプの [AggregatedMetrics.max_load][] とそれぞれの Vehicle.load_limits の最大比率。すべての Vehicle.load_limits フィールドが設定されていない場合、このフィールドは設定されません。

active_span

double

特定の車両の比率(vehicle_end_time - vehicle_start_time)/(latest_vehicle_end_time - earliest_vehicle_start_time)。分母がない場合は、代わりに(ShipmentModel.global_end_time - ShipmentModel.global_start_time)を使用します。

ウェイポイント

経由地をカプセル化します。経由地は、VisitRequest の到着地と出発地、Vehicle の開始地と終了地を示します。

フィールド
side_of_road

bool

省略可。このウェイポイントの位置で、車両を優先的に道路の特定の側に停車することを指示します。この値を設定すると、ルートは位置情報を通過するため、車両は道路の中央から位置情報が偏っている側の路肩に停車できます。このオプションは、移動手段が「徒歩」の場合には機能しません。

vehicle_stopover

bool

ウェイポイントが車両の停車地点であり、乗車または降車を目的としていることを示します。このオプションは、交通手段が「運転」で、location_type が「location」の場合にのみ機能します。

試験運用版: このフィールドの動作または存在は、今後変更される可能性があります。

共用体フィールド location_type。場所を表すさまざまな方法。location_type は次のいずれかになります。
location

Location

地理座標を使用して指定されたポイント。オプションの見出しを含む。

place_id

string

経由地に関連付けられた POI のプレイス ID。

プレイス ID を使用して VisitRequest の到着地または出発地を指定する場合は、その場所へのナビゲーションの LatLng 位置を特定するのに十分なプレイス ID を使用します。たとえば、建物を示すプレイス ID は適切ですが、道路を示すプレイス ID は推奨されません。