索引
RouteOptimization（接口）AggregatedMetrics（消息）BatchOptimizeToursMetadata（消息）BatchOptimizeToursRequest（消息）BatchOptimizeToursRequest.AsyncModelConfig（消息）BatchOptimizeToursResponse（消息）BreakRule（消息）BreakRule.BreakRequest（消息）BreakRule.FrequencyConstraint（消息）DataFormat（枚举）DistanceLimit（消息）GcsDestination（消息）GcsSource（消息）InjectedSolutionConstraint（消息）InjectedSolutionConstraint.ConstraintRelaxation（消息）InjectedSolutionConstraint.ConstraintRelaxation.Relaxation（消息）InjectedSolutionConstraint.ConstraintRelaxation.Relaxation.Level（枚举）InputConfig（消息）Location（消息）OptimizeToursRequest（消息）OptimizeToursRequest.SearchMode（枚举）OptimizeToursRequest.SolvingMode（枚举）OptimizeToursResponse（消息）OptimizeToursResponse.Metrics（消息）OptimizeToursValidationError（消息）OptimizeToursValidationError.FieldReference（消息）OutputConfig（消息）Shipment（消息）Shipment.Load（消息）Shipment.VisitRequest（消息）ShipmentModel（消息）ShipmentModel.DurationDistanceMatrix（消息）ShipmentModel.DurationDistanceMatrix.Row（消息）ShipmentModel.PrecedenceRule（消息）ShipmentRoute（消息）ShipmentRoute.Break（消息）ShipmentRoute.EncodedPolyline（消息）ShipmentRoute.Transition（消息）ShipmentRoute.VehicleLoad（消息）ShipmentRoute.Visit（消息）ShipmentTypeIncompatibility（消息）ShipmentTypeIncompatibility.IncompatibilityMode（枚举）ShipmentTypeRequirement（消息）ShipmentTypeRequirement.RequirementMode（枚举）SkippedShipment（消息）SkippedShipment.Reason（消息）SkippedShipment.Reason.Code（枚举）TimeWindow（消息）TransitionAttributes（消息）Vehicle（消息）Vehicle.DurationLimit（消息）Vehicle.LoadLimit（消息）Vehicle.LoadLimit.Interval（消息）Vehicle.TravelMode（枚举）Vehicle.UnloadingPolicy（枚举）Waypoint（消息）
RouteOptimization
用于优化车辆行程的服务。
特定类型字段的有效性：
google.protobuf.Timestamp- 时间采用 Unix 时间：自 1970-01-01T00:00:00+00:00 以来的秒数。
- 秒数必须介于 [0, 253402300799] 之间，即介于 [1970-01-01T00:00:00+00:00, 9999-12-31T23:59:59+00:00] 之间。
- nanos 必须取消设置或设置为 0。
google.protobuf.Duration- 秒数必须介于 [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] 范围内。
- 经度和纬度中至少有一个必须不为零。
| BatchOptimizeTours |
|---|
|
批量优化一个或多个 此方法是一项长时间运行的操作 (LRO)。优化输入（ 用户可以轮询 如果 LRO 的 如果 LRO 的
|
| OptimizeTours |
|---|
|
发送包含
目标是为
|
AggregatedMetrics
ShipmentRoute（对于所有 Transition 和/或 Visit 的 OptimizeToursResponse，分别为所有 ShipmentRoute 的 OptimizeToursResponse）的汇总指标。
| 字段 | |
|---|---|
performed_shipment_count |
已完成的配送次数。请注意，一个取件和送货对只会计一次。 |
travel_duration |
路线或解决方案的总行程时长。 |
wait_duration |
路线或解决方案的总等待时长。 |
delay_duration |
路线或方案的总延迟时长。 |
break_duration |
路线或方案的总休息时长。 |
visit_duration |
某条路线或某个解决方案的总访问时长。 |
total_duration |
总时长应等于上述所有时长的总和。对于路线，它还对应于： |
travel_distance_meters |
路线或解决方案的总行驶距离。 |
max_loads |
整个路线（或解决方案）上实现的最大载荷，对于此路线（或解决方案）上的每个数量，计算方式为所有 |
BatchOptimizeToursMetadata
此类型没有字段。
BatchOptimizeToursRequest 调用的操作元数据。
BatchOptimizeToursRequest
以异步操作的形式请求批量优化行程。每个输入文件都应包含一个 OptimizeToursRequest，每个输出文件都将包含一个 OptimizeToursResponse。该请求包含用于读取/写入和解析文件的信息。所有输入和输出文件都应位于同一项目下。
| 字段 | |
|---|---|
parent |
必需。定位项目和位置以进行呼叫。 格式：* 如果未指定位置，则系统将自动选择区域。 |
model_configs[] |
必需。每个购买模型的输入/输出信息，例如文件路径和数据格式。 |
AsyncModelConfig
用于异步求解一个优化模型的信息。
| 字段 | |
|---|---|
display_name |
可选。用户定义的模型名称，可供用户用作别名来跟踪模型。 |
input_config |
必需。输入模型的相关信息。 |
output_config |
必需。所需的输出位置信息。 |
BatchOptimizeToursResponse
此类型没有字段。
对 BatchOptimizeToursRequest 的响应。此值会在操作完成后在“长时间运行的操作”中返回。
BreakRule
用于为车辆生成时间休息时段（例如午餐休息时段）的规则。休息时间是指车辆在其当前位置保持空闲状态且无法执行任何访问的连续时间段。中断可能会发生在以下情况下：
- 在两次访问之间的行程中（包括访问前后的时间，但不包括访问期间），在这种情况下，它会延长两次访问之间的相应转接时间；
- 或在车辆启动之前（车辆可能不会在休息期间启动），在这种情况下，它不会影响车辆启动时间。
- 或在车辆结束时间之后（同上，使用车辆结束时间）。
| 字段 | |
|---|---|
break_requests[] |
休息时间序列。查看 |
frequency_constraints[] |
可能有多个 |
BreakRequest
必须事先知道适用于每辆车的休息点序列（即数量和顺序）。重复的 BreakRequest 定义了该序列，并按其必须出现的顺序排列。它们的时间范围 (earliest_start_time / latest_start_time) 可能会重叠，但必须与订单兼容（系统会进行检查）。
| 字段 | |
|---|---|
earliest_start_time |
必需。休息时间开始的下限（包括该时间）。 |
latest_start_time |
必需。休息时间开始的上限（包括该时间）。 |
min_duration |
必需。广告插播时长下限。必须为正值。 |
FrequencyConstraint
您可以通过强制执行最小休息频率（例如“每 12 小时必须至少休息 1 小时”）来进一步约束上述休息时间的频率和时长。假设这可以解释为“在任何 12 小时的滑动时间窗口内，必须至少有一次至少 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 |
必需。此限制条件的最短插播时长。非负数。请参阅 |
max_inter_break_duration |
必需。路线中任何时间间隔（不包含至少部分 |
DataFormat
输入和输出文件的数据格式。
| 枚举 | |
|---|---|
DATA_FORMAT_UNSPECIFIED |
值无效，格式不得为“UNSPECIFIED”。 |
JSON |
JavaScript 对象表示法。 |
PROTO_TEXT |
协议缓冲区文本格式。请参阅 https://protobuf.dev/reference/protobuf/textformat-spec/ |
DistanceLimit
用于定义可行驶的最大距离的限制。它可以是硬的，也可以是软的。
如果定义了软上限，则必须定义 soft_max_meters 和 cost_per_kilometer_above_soft_max，并且它们必须为非负值。
| 字段 | |
|---|---|
max_meters |
一个硬限制，用于限制距离不得超过 max_meters。上限必须是非负数。 |
soft_max_meters |
软限制不会强制执行最短距离限制，但如果违反了此限制，则会产生费用，该费用会与模型中定义的其他费用相加，并采用相同的单位。 如果已定义 soft_max_meters，则其值必须小于 max_meters 且是非负数。 |
cost_per_kilometer_above_soft_max |
如果距离超出 费用必须为非负数。 |
GcsDestination
将在其中写入输出文件的 Google Cloud Storage 位置。
| 字段 | |
|---|---|
uri |
必需。Google Cloud Storage URI。 |
GcsSource
将从中读取输入文件的 Google Cloud Storage 位置。
| 字段 | |
|---|---|
uri |
必需。格式为 |
InjectedSolutionConstraint
注入到请求中的解决方案，其中包含有关必须限制哪些访问以及如何限制这些访问的信息。
| 字段 | |
|---|---|
routes[] |
要注入的解决方案的路线。原始解决方案中可能会省略一些路线。路线和跳过的运输必须满足为 |
skipped_shipments[] |
跳过了要注入的解决方案的提交。原始解决方案中可能会省略一些步骤。请参阅 |
constraint_relaxations[] |
对于零个或多个车辆组，指定何时以及如何放宽约束条件。如果此字段为空，则所有非空车辆路线均完全受限。 |
ConstraintRelaxation
对于一组车辆，指定在达到什么阈值时会放宽对访问次数的限制，以及放宽到什么级别。skipped_shipment 字段中列出的运单会被强制跳过；即无法执行。
| 字段 | |
|---|---|
relaxations[] |
|
vehicle_indices[] |
指定要应用访问限制条件 如果 |
娱乐
如果 relaxations 为空，则 routes 上的所有到访的开始时间和顺序都受到完全约束，并且无法向这些路线插入或添加新的到访。此外，除非车辆为空（即没有任何访问，并且在模型中将 used_if_route_is_empty 设置为 false），否则 routes 中的车辆开始时间和结束时间是完全受限的。
relaxations(i).level 指定应用于满足以下条件的访问 #j 的约束条件放宽级别：
route.visits(j).start_time >= relaxations(i).threshold_time和j + 1 >= relaxations(i).threshold_visit_count
同样，如果车辆启动满足以下条件，则会放宽为 relaxations(i).level：
vehicle_start_time >= relaxations(i).threshold_time和relaxations(i).threshold_visit_count == 0，并且如果车辆端满足以下条件，则将其放宽为relaxations(i).level：vehicle_end_time >= relaxations(i).threshold_time和route.visits_size() + 1 >= relaxations(i).threshold_visit_count
如需在访问符合 threshold_visit_count 或 threshold_time 时应用放宽级别，请添加两个具有相同 level 的 relaxations：一个仅设置了 threshold_visit_count，另一个仅设置了 threshold_time。如果某次访问满足多个 relaxations 的条件，则应用最宽松的级别。因此，从车辆启动到沿路线访问各个地点再到车辆结束，放松级别会越来越高，即放松级别会随着路线的推进而增加。
不满足任何 relaxations 阈值条件的路线访问的具体时间和顺序受到完全约束，并且无法在这些顺序中插入任何访问。此外，如果车辆的开始或结束时间不满足任何放宽条件，则时间固定不变，除非车辆为空。
| 字段 | |
|---|---|
level |
当满足 |
threshold_time |
可在该时间或之后应用放宽 |
threshold_visit_count |
达到或超过此次数后，系统可能会应用放宽 如果为 |
级别
表示不同的约束条件放宽级别，这些级别会应用于一次访问，以及在满足阈值条件后对后续访问应用的级别。
以下枚举按放松程度从低到高排列。
| 枚举 | |
|---|---|
LEVEL_UNSPECIFIED |
隐式默认放宽级别：不放宽任何约束条件，即所有访问都受到完全约束。 不得在 |
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 |
必需。输入数据格式。 |
联合字段 source。必需。source 只能是下列其中一项： |
|
gcs_source |
Google Cloud Storage 位置。此参数必须是单个对象（文件）。 |
位置
封装位置（地理点和可选的标题）。
| 字段 | |
|---|---|
lat_lng |
航点的地理坐标。 |
heading |
与交通流方向相关联的罗盘方向。此值用于指定上车点和下车点所在的道路边。航向值介于 0 到 360 之间，其中 0 指定正北，90 指定正东，依此类推。 |
OptimizeToursRequest
要提供给行程优化求解器的请求，该求解器会定义要解决的运输模型以及优化参数。
| 字段 | |
|---|---|
parent |
必需。定位项目或位置以进行呼叫。 格式：* 如果未指定位置，则系统将自动选择区域。 |
timeout |
如果设置了此超时，服务器会在超时期限或同步请求的服务器截止时间（以时间较短者为准）到达之前返回响应。 对于异步请求，服务器会在超时之前生成解决方案（如果可能）。 |
model |
要解决的配送模型。 |
solving_mode |
默认情况下，求解模式为 |
search_mode |
用于解决请求的搜索模式。 |
injected_first_solution_routes[] |
引导优化算法找到与上一个解决方案类似的第一个解决方案。 在构建第一个解决方案时，模型会受到约束。在第一个解决方案中，系统会隐式跳过未在某个路线上执行的任何配送，但可能会在后续解决方案中执行这些配送。 该解决方案必须满足一些基本有效性假设：
如果注入的解决方案不可行，则不一定会返回验证错误，而可能会返回指示不可行性的错误。 |
injected_solution_constraint |
限制优化算法，以找到与上一个解决方案类似的最终解决方案。例如，这可用于冻结已完成或即将完成但不得修改的路线的部分。 如果注入的解决方案不可行，则不一定会返回验证错误，而可能会返回指示不可行性的错误。 |
refresh_details_routes[] |
如果不为空，系统会刷新给定路线，而不会更改其底层的访问顺序或行程时间：只有其他详细信息会更新。这并不能解决模型问题。 自 2020 年 11 月起，此方法仅填充非空路线的多段线，并且要求 传入路线的 此字段不得与
|
interpret_injected_solutions_using_labels |
如果为真：
此解释适用于 如果为 true，则以下类别中的标签在其类别中最多只能显示一次：
如果注入的解决方案中的 从注入的解决方案中移除路线访问或整个路线可能会影响隐含约束条件，从而导致解决方案发生变化、出现验证错误或不可行。 注意：调用方必须确保每个 |
consider_road_traffic |
在计算 |
populate_polylines |
如果为 true，系统会在响应 |
populate_transition_polylines |
如果为 true，系统会在响应 |
allow_large_deadline_despite_interruption_risk |
如果设置此值，则请求可以设置最长 60 分钟的截止期限（请参阅 https://grpc.io/blog/deadlines）。否则，最长期限只有 30 分钟。请注意，长时间运行的请求中断的风险要高得多（但仍然很小）。 |
use_geodesic_distances |
如果为 true，则将使用地理距离（而非 Google 地图距离）计算行程距离，并使用由 |
label |
可用于标识此请求的标签，会在 |
geodesic_meters_per_second |
当 |
max_validation_errors |
截断返回的验证错误数量。这些错误通常附加到 INVALID_ARGUMENT 错误载荷中，作为 BadRequest 错误详情 (https://cloud.google.com/apis/design/errors#error_details)，除非 solving_mode=VALIDATE_ONLY：请参阅 |
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
解决巡回优化问题后的响应，其中包含每辆车行驶的路线、已跳过的运输以及解决方案的总费用。
| 字段 | |
|---|---|
routes[] |
为每辆车辆计算的路线；第 i 条路线对应于模型中的第 i 辆车辆。 |
request_label |
|
skipped_shipments[] |
所有已跳过的配送的列表。 |
validation_errors[] |
我们能够独立检测到的所有验证错误的列表。请参阅 |
metrics |
此解决方案的时长、距离和使用情况指标。 |
指标
汇总所有路线的整体指标。
| 字段 | |
|---|---|
aggregated_route_metrics |
按路线汇总。每个指标都是同名所有 |
skipped_mandatory_shipment_count |
跳过的强制性发货数量。 |
used_vehicle_count |
使用的车辆数量。注意：如果车辆路线为空且 |
earliest_vehicle_start_time |
二手车的开始时间最早，计算方法为所有二手车的 |
latest_vehicle_end_time |
二手车的最新结束时间，计算方式为所有二手车的 |
costs |
解决方案的费用，按与费用相关的请求字段细分。键是相对于输入 OptimizeToursRequest 的 proto 路径，例如“model.shipments.pickups.cost”，值是相应费用字段生成的总费用，涵盖整个解决方案。换句话说，costs["model.shipments.pickups.cost"] 是解决方案的所有上门取件费用的总和。此处会详细报告模型中定义的所有费用，但与 TransitionAttributes 相关的费用除外，自 2022 年 1 月起，这些费用仅以汇总方式报告。 |
total_cost |
解决方案的总费用。费用映射中所有值的总和。 |
OptimizeToursValidationError
描述验证 OptimizeToursRequest 时遇到的错误或警告。
| 字段 | |
|---|---|
code |
验证错误由始终存在的对 ( 其他字段（见下文）可提供有关错误的更多背景信息。 MULTIPLE ERRORS：如果存在多个错误，验证流程会尝试输出其中的多个错误。与编译器类似，这并不是一个完美的流程。某些验证错误会是“严重”错误，这意味着它们会停止整个验证流程。 稳定性： 参考：所有（代码、名称）对的列表：
|
display_name |
错误的显示名称。 |
fields[] |
错误上下文可能涉及 0、1（大多数情况下）或多个字段。例如，如需引用车辆 4 和运输 2 的首次上门取件，可以按如下方式操作： 不过，请注意，对于给定错误代码， |
error_message |
用于描述错误的直观易懂的字符串。 稳定性：不稳定：与给定 |
offending_values |
可能包含字段的值。此功能并不总是可用。您绝不应依赖它，只能将其用于手动模型调试。 |
FieldReference
为验证错误指定上下文。FieldReference 始终引用此文件中的给定字段，并遵循相同的层次结构。例如，我们可以使用以下代码指定车辆 #5 的 start_time_windows 的元素 #2：
name: "vehicles" index: 5 sub_field { name: "end_time_windows" index: 2 }
不过，我们会省略 OptimizeToursRequest 或 ShipmentModel 等顶级实体，以免消息过于拥挤。
| 字段 | |
|---|---|
name |
字段的名称，例如“vehicles”。 |
sub_field |
递归嵌套的子字段（如有必要）。 |
联合字段
|
|
index |
如果重复，则为字段的索引。 |
key |
如果字段是映射，则为键。 |
OutputConfig
为 [BatchOptimizeTours][google.maps.routeoptimization.v1.RouteOptimizationService.BatchOptimizeTours] 结果指定目的地。
| 字段 | |
|---|---|
data_format |
必需。输出数据格式。 |
联合字段 destination。必需。destination 只能是下列其中一项： |
|
gcs_destination |
要将输出内容写入的 Google Cloud Storage 位置。 |
发货
单个商品从取件到送达的运输过程。为了将运输作业视为已完成，唯一车辆必须先访问其某个取件地点（并相应地减少其空闲运力），然后稍后访问其某个送货地点（并相应地重新增加其空闲运力）。
| 字段 | |
|---|---|
display_name |
用户为运输订单定义的显示名称。此字符串不得超过 63 个字符，且可以使用 UTF-8 字符。 |
pickups[] |
与运输订单关联的一组取件选项。如果未指定，车辆只需访问与送货点对应的地点即可。 |
deliveries[] |
与运输订单关联的一组配送替代方案。如果未指定，车辆只需访问与上车点对应的地点即可。 |
load_demands |
运输的载荷需求（例如重量、体积、托盘数量等）。映射中的键应为描述相应负载类型的标识符，最好还包含单位。例如：“weight_kg”“volume_gallons”“pallet_count”等。如果给定键未出现在映射中，则相应的载荷会被视为 null。 |
allowed_vehicle_indices[] |
可能执行此运输的车辆组。如果为空，则所有车辆都可以执行此操作。车辆是根据 |
costs_per_vehicle[] |
指定使用每辆车辆运送此运输时产生的费用。如果指定了，则必须具有以下任一属性：
这些费用必须与 |
costs_per_vehicle_indices[] |
应用 |
pickup_to_delivery_absolute_detour_limit |
指定与从上车点到下车点的最短路径相比的绝对绕道时间上限。如果指定，则必须为非负数，并且运输必须至少包含一个上门取件和一个送货。 例如，设 t 为从所选的取件替代方案直接前往所选的送货替代方案所需的最短时间。然后，设置 如果同一运输中同时指定了相对上限和绝对上限，系统会对每个可能的取件/送货对使用更严格的上限。自 2017 年 10 月起，只有在行程时长不依赖于车辆时，才支持绕道。 |
pickup_to_delivery_time_limit |
指定从取件开始到送货开始的最长时长。如果指定，则必须为非负数，并且运输必须至少包含一个上门取件和一个送货。这不取决于为上门取件和送货选择了哪些替代方案，也不取决于车辆速度。此参数可与最大绕行限制一起指定：解决方案将遵循这两项规范。 |
shipment_type |
非空字符串，用于指定此运输的“类型”。此功能可用于定义 与仅针对单次访问指定的 |
label |
为此配送指定标签。此标签会在响应的相应 |
ignore |
如果为 true，则跳过此配送，但不应用 如果模型中存在任何 允许忽略在 |
penalty_cost |
如果未能完成运输，此处罚金将计入路线的总费用。如果客户选择了某个取件和送货选项，并已前往该选项的取件点或送货地址，则系统会将相应运单视为已完成。费用可以采用与模型中所有其他与费用相关的字段相同的单位表示，并且必须为正值。 重要提示：如果未指定此处罚，则视为无限期，即必须完成发货。 |
pickup_to_delivery_relative_detour_limit |
指定与从上车点到下车点的最短路径相比，绕路的最大相对时间。如果指定，则必须为非负数，并且运输必须至少包含一个上门取件和一个送货。 例如，设 t 为从所选的取件替代方案直接前往所选的送货替代方案所需的最短时间。然后，设置 如果同一运输中同时指定了相对上限和绝对上限，系统会对每个可能的取件/送货对使用更严格的上限。自 2017 年 10 月起，只有在行程时长不依赖于车辆时，才支持绕道。 |
加载
执行访问时，如果是上门自提，系统可能会向车辆载重添加预定义数量；如果是送货，则会从车辆载重中减去预定义数量。此消息定义了此金额。请参阅 load_demands。
| 字段 | |
|---|---|
amount |
执行相应访问的车辆的载重量会有所不同。由于它是整数，因此建议用户选择适当的单位，以免精度丢失。必须大于等于 0。 |
VisitRequest
请求由车辆完成的访问：它具有一个（或两个，见下文）地理位置、由时间范围表示的开业和打烊时间，以及服务时长（车辆到达取件或送货地点后所花的时间）。
| 字段 | |
|---|---|
arrival_location |
执行此 |
arrival_waypoint |
车辆执行此 |
departure_location |
车辆完成此 |
departure_waypoint |
车辆完成此 |
tags[] |
指定附加到访问请求的标记。不允许使用空字符串或重复的字符串。 |
time_windows[] |
用于约束到达时间的访问时间窗口。请注意，车辆可能会在到达时间范围之外出发，即到达时间 + 时长不必在时间范围内。如果车辆在 如果没有 时间窗口必须互不相交，即任何时间窗口都不能与其他时间窗口重叠或相邻，并且必须按升序排列。 只有在只有一个时间窗口时，才能设置 |
duration |
访问时长，即车辆在到达和离开之间所花的时间（应添加到可能的等待时间；请参阅 |
cost |
在车辆路线上处理此访问请求的费用。您可以使用此属性为每笔订单的每种备选自提或外卖服务支付不同的费用。此费用必须与 |
load_demands |
此访问请求的加载需求。这与 |
visit_types[] |
指定访问类型。此参数可用于分配车辆完成此访问所需的额外时间（请参阅 一种类型只能出现一次。 |
label |
为此 |
avoid_u_turns |
指定在此位置的驾车路线中是否应避免 U 形转弯。系统会尽力避免 U 型转弯，但无法保证完全避免。这是一项实验性功能，其行为可能会发生变化。 |
ShipmentModel
运输模型包含一组必须由一组车辆执行的运输，同时尽可能降低总费用，总费用是以下各项的总和：
- 车辆路线规划费用（所有车辆的总时间费用、行驶时间费用和固定费用的总和）。
- 未履行发货义务的处罚。
- 运输全程的费用
| 字段 | |
|---|---|
shipments[] |
必须在模型中执行的一组配送。 |
vehicles[] |
可用于执行访问的一组车辆。 |
global_start_time |
模型的全局开始时间和结束时间：超出此范围的时间均不视为有效。 模型的时间跨度不得超过 1 年，即 使用 |
global_end_time |
如果未设置，系统会默认使用 1971 年 1 月 1 日 00:00:00 UTC（即秒数：31536000，纳秒数：0）。 |
global_duration_cost_per_hour |
整个方案的“总时长”是指所有车辆的最早有效开始时间与最晚有效结束时间之间的差值。例如，用户可以为该数量分配每小时费用，以尝试优化以尽快完成作业。此费用必须与 |
duration_distance_matrices[] |
指定模型中使用的时长和距离矩阵。如果此字段为空，系统将改用 Google 地图或大地距离，具体取决于 用法示例：
|
duration_distance_matrix_src_tags[] |
用于定义时长和距离矩阵来源的标记； 标记对应于 |
duration_distance_matrix_dst_tags[] |
用于定义时长和距离矩阵目的地的标记； 标记对应于 |
transition_attributes[] |
添加到模型的转换属性。 |
shipment_type_incompatibilities[] |
不兼容的 shipment_type 集合（请参阅 |
shipment_type_requirements[] |
一系列 |
precedence_rules[] |
必须在模型中强制执行的一组优先级规则。 |
max_active_vehicles |
限制有效车辆的数量上限。如果车辆的路线至少执行了一次运输，则该车辆处于活跃状态。如果驾驶员数量少于车辆数量，并且车队是异构的，则可以使用此参数来限制路线数量。然后，优化功能会选择最佳车辆子集。必须为严格正值。 |
DurationDistanceMatrix
指定从到访地点和车辆起始位置到到访地点和车辆终止位置的持续时间和距离矩阵。
| 字段 | |
|---|---|
rows[] |
指定时长和距离矩阵的行。其元素数量必须与 |
vehicle_start_tag |
用于定义此时长和距离矩阵适用于哪些车辆的标记。如果为空，则应用于所有车辆，并且只能有一个矩阵。 每项车辆启动都必须与一个矩阵完全匹配，即其中只有一个 所有矩阵都必须具有不同的 |
行
指定时长和距离矩阵的行。
| 字段 | |
|---|---|
durations[] |
指定行的时长值。其元素数量必须与 |
meters[] |
给定行的距离值。如果模型中没有任何费用或约束条件涉及距离，则可以将此值留空；否则，其元素数量必须与 |
PrecedenceRule
两项事件（每项事件都是商品的取件或送达）之间的优先级规则：“第二”事件必须在“第一”事件开始后至少 offset_duration 才会开始。
多个优先级可以引用同一（或相关）事件，例如“B 的送达发生在 A 的送达之后”和“C 的送达发生在 B 的送达之后”。
此外，优先级仅在同时发货时才适用，否则会被忽略。
| 字段 | |
|---|---|
first_is_delivery |
指明“第一个”事件是否为传送事件。 |
second_is_delivery |
指示“第二个”事件是否为传送事件。 |
offset_duration |
“first”和“second”事件之间的偏移。可以为负数。 |
first_index |
“first”事件的配送指数。必须指定此字段。 |
second_index |
“第二个”事件的配送编号。必须指定此字段。 |
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
请注意，我们会区分以下两种情况：
- “准时事件”，例如车辆启动和停止以及每次访问的开始和结束（也称为到达和离开）。它们会在指定的秒数发生。
- “时间间隔”，例如访问本身以及访问之间的转换。虽然时间间隔有时可能为零时长（即开始和结束时间相同），但通常为正时长。
不变量：
- 如果有 n 次访问，则有 n+1 次转化。
- 每次访问始终由前面的转换（相同的索引）和后面的转换（索引 + 1）包围。
- 车辆启动后面总是跟着转换 #0。
- 车辆结束始终位于转换 #n 之前。
下面详细介绍了 Transition 和 Visit 期间会发生的情况：
---+-------------------------------------+-----------------------------+-->
| 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 |
执行路线的车辆，通过其在来源 |
vehicle_label |
执行此路线的车辆的标签，等于 |
vehicle_start_time |
车辆开始行驶路线的时间。 |
vehicle_end_time |
车辆完成行程的时间。 |
visits[] |
表示路线的访问有序序列。visits[i] 是路线中的第 i 次访问。如果此字段为空，则车辆会被视为未使用。 |
transitions[] |
相应路线的转换的有序列表。 |
has_traffic_infeasibilities |
如果 由于交通拥堵导致预计行程时间 |
route_polyline |
路线的编码多段线表示法。只有当 |
breaks[] |
为执行此路线的车辆安排的休息时间。 |
metrics |
此路线的时长、距离和载荷指标。系统会对所有 |
route_costs |
路线费用，按费用相关的请求字段细分。键是相对于输入 OptimizeToursRequest 的 proto 路径，例如“model.shipments.pickups.cost”，值是相应费用字段生成的总费用，涵盖整个路线。换句话说，costs["model.shipments.pickups.cost"] 是整个路线上的所有上门取件费用的总和。此处会详细报告模型中定义的所有费用，但与 TransitionAttributes 相关的费用除外，自 2022 年 1 月起，这些费用仅以汇总方式报告。 |
route_total_cost |
路线的总费用。费用图中所有费用的总和。 |
休息时间
表示执行 break 的数据。
| 字段 | |
|---|---|
start_time |
广告插播时间的开始时间。 |
duration |
休息时长。 |
EncodedPolyline
多段线的编码表示法。如需详细了解多段线编码，请参阅：https://developers.google.com/maps/documentation/utilities/polylinealgorithm https://developers.google.com/maps/documentation/javascript/reference/geometry#encoding。
| 字段 | |
|---|---|
points |
表示多段线编码点的字符串。 |
过渡
路线上两个事件之间的转换。请参阅 ShipmentRoute 的说明。
如果车辆没有 start_location 和/或 end_location，则相应的行程指标为 0。
| 字段 | |
|---|---|
travel_duration |
在此过渡期间的旅行时长。 |
travel_distance_meters |
过渡期间行进的距离。 |
traffic_info_unavailable |
通过 |
delay_duration |
应用于此转换的延迟时长的总和。延迟时间（如果有）会在下一个事件（光顾或车辆结束）开始前恰好 |
break_duration |
在此转换期间发生的休息时长（如果有）的总和。有关每个休息时间的开始时间和时长的详细信息存储在 |
wait_duration |
在此过渡期间的等待时间。等待时长对应于空闲时间，不包括休息时间。另请注意，此等待时间可能会拆分为多个不连续的间隔时间。 |
total_duration |
转换的总时长，提供以供参考。等于：
|
start_time |
此转换的开始时间。 |
route_polyline |
转换期间所遵循路线的编码多段线表示法。只有当 |
vehicle_loads |
在此过渡期间的车辆载荷，对于此车辆的 第一次转换期间的载荷是车辆路线的起始载荷。然后，在每次访问后，系统都会添加或减去相应访问的 |
VehicleLoad
报告给定类型的车辆在路线上的某个位置的实际载荷（请参阅 Transition.vehicle_loads）。
| 字段 | |
|---|---|
amount |
指定类型的车辆上的载荷量。负载的单位通常由类型指示。请参阅 |
访问
在路线中执行的访问。此访问对应于 Shipment 的取件或送货。
| 字段 | |
|---|---|
shipment_index |
来源 |
is_pickup |
如果为 true，则表示相应到访与 |
visit_request_index |
|
start_time |
访问的开始时间。请注意，车辆可能会提前到达上门服务地点。时间与 |
load_demands |
总光顾负载需求为发货量和光顾请求 |
detour |
由于在到达之前在路线上拜访的运输服务而产生的额外绕道时间，以及由于时间范围而产生的潜在等待时间。如果是送货服务，则绕路距离是根据相应的上门取件服务计算得出的，等于： 否则，系统会根据车辆 |
shipment_label |
相应 |
visit_label |
相应 |
injected_solution_location_token |
一个不透明令牌，表示与访问地点相关的信息。 如果为此访问设置了 |
ShipmentTypeIncompatibility
根据 shipment_type 指定配送信息之间的不兼容性。系统会根据不兼容模式限制同一路线上不兼容的配送信息的显示。
| 字段 | |
|---|---|
types[] |
不兼容的类型列表。如果两个发货中列出的 |
incompatibility_mode |
应用于不兼容问题的模式。 |
IncompatibilityMode
用于定义如何限制同一路线上不兼容的配送方式的显示方式的模式。
| 枚举 | |
|---|---|
INCOMPATIBILITY_MODE_UNSPECIFIED |
未指定的不兼容模式。不应使用此值。 |
NOT_PERFORMED_BY_SAME_VEHICLE |
在此模式下，两件类型不兼容的运输服务绝不能共用同一辆车辆。 |
NOT_IN_SAME_VEHICLE_SIMULTANEOUSLY |
对于两种类型不兼容且采用
|
ShipmentTypeRequirement
根据 shipment_type 指定不同配送方式之间的要求。具体要求由要求模式定义。
| 字段 | |
|---|---|
required_shipment_type_alternatives[] |
|
dependent_shipment_types[] |
对于 注意：不允许出现 |
requirement_mode |
应用于相应要求的模式。 |
RequirementMode
用于定义路线中依赖配送的显示方式的模式。
| 枚举 | |
|---|---|
REQUIREMENT_MODE_UNSPECIFIED |
未指定要求模式。不应使用此值。 |
PERFORMED_BY_SAME_VEHICLE |
在此模式下，所有“依赖性”运输必须与至少一个“必需性”运输共用同一车辆。 |
IN_SAME_VEHICLE_AT_PICKUP_TIME |
在 因此，“依赖”的商品自提必须具有以下任一属性：
|
IN_SAME_VEHICLE_AT_DELIVERY_TIME |
与之前相同，但“依赖”运输服务的运输订单在送达时需要在车辆上装载“必需”运输服务的运输订单。 |
SkippedShipment
指定解决方案中未执行的配送的详细信息。对于琐碎的用例和/或如果我们能够确定跳过的原因，我们会在此处报告原因。
| 字段 | |
|---|---|
index |
该索引与来源 |
label |
相应 |
reasons[] |
说明为何跳过发货的原因列表。请参阅 |
原因
如果我们可以说明为何跳过配送，原因会显示在此处。如果所有车辆的原因不尽相同，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），至少有一辆车的“梨”容量会超出（包括车辆 3），并且至少有一辆车的距离限制会超出（包括车辆 1）。
| 字段 | |
|---|---|
code |
请参阅代码的注释。 |
example_exceeded_capacity_type |
如果原因代码为 |
example_vehicle_index |
如果原因与运输车辆不兼容有关，此字段会提供相关车辆的编号。 |
代码
用于标识原因类型的代码。这里的顺序没有意义。具体而言，它不会指明给定原因是否会在解决方案中显示在另一个原因之前（如果这两个原因都适用）。
| 枚举 | |
|---|---|
CODE_UNSPECIFIED |
切勿使用此值。 |
NO_VEHICLE |
模型中没有车辆，因此所有运输都不可行。 |
DEMAND_EXCEEDS_VEHICLE_CAPACITY |
运输需求超出了车辆的某些容量类型（其中之一是 example_exceeded_capacity_type）的容量。 |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DISTANCE_LIMIT |
执行此运输所需的最短距离（即从车辆的 请注意，在此计算中，我们使用的是测地线距离。 |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT |
执行此运输所需的最短时间（包括行驶时间、等待时间和服务时间）超出了车辆的 注意：系统会在最佳情况下计算行程时间，即测地线距离 x 36 米/秒（大约 130 公里/小时）。 |
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 字段不为空，而此车辆不属于该订单。 |
TimeWindow
时间范围用于约束事件的时间，例如到达时间或车辆的开始时间和结束时间。
硬性时间范围边界 start_time 和 end_time 会强制执行事件的最早和最晚时间，例如 start_time <= event_time <=
end_time。软时间范围下限 soft_start_time 表示希望事件在 soft_start_time 当天或之后发生，如果事件发生在 soft_start_time 之前，则会产生与事件发生在 soft_start_time 之前的时间长度成正比的费用。软时间范围上限 soft_end_time 表示希望事件在 soft_end_time 当天或之前发生，如果事件发生在 soft_end_time 之后，则会产生与事件发生在 soft_end_time 之后的时长成正比的代价。start_time、end_time、soft_start_time 和 soft_end_time 应在全球时间限制范围内（请参阅 ShipmentModel.global_start_time 和 ShipmentModel.global_end_time），并且应遵循以下要求：
0 <= `start_time` <= `end_time` and
0 <= `start_time` <= `soft_start_time` and
0 <= `soft_end_time` <= `end_time`.
| 字段 | |
|---|---|
start_time |
硬性时间范围的开始时间。如果未指定，则将设置为 |
end_time |
硬性时间范围的结束时间。如果未指定，则将设置为 |
soft_start_time |
时间段的软开始时间。 |
soft_end_time |
时间范围的非强制性结束时间。 |
cost_per_hour_before_soft_start_time |
如果事件发生在 soft_start_time 之前，则将每小时费用添加到模型中的其他费用中，计算方式如下： 此费用必须为正值，并且只有在设置了 soft_start_time 后才能设置此字段。 |
cost_per_hour_after_soft_end_time |
如果事件发生在 此费用必须为正数，并且只有在设置了 |
TransitionAttributes
指定路线上两次连续访问之间的转换属性。同一转换可能适用多个 TransitionAttributes：在这种情况下，所有额外费用都会相加，并且系统会应用最严格的约束条件或限制（遵循自然的“AND”语义）。
| 字段 | |
|---|---|
src_tag |
用于定义要应用这些属性的一组 (src->dst) 转场效果的标记。 来源访问或车辆启动匹配的条件是：其 |
excluded_src_tag |
请参阅 |
dst_tag |
只有当目的地到访或车辆结束的 |
excluded_dst_tag |
请参阅 |
cost |
指定执行此转换的费用。此值应与模型中的所有其他费用采用相同的单位，且不得为负值。此费用需在所有其他现有费用的基础上支付。 |
cost_per_kilometer |
指定在执行此过渡期间对行驶距离应用的每公里费用。它与车辆上指定的任何 |
distance_limit |
指定执行此过渡时行进的距离上限。 自 2021 年 6 月起，仅支持软限制。 |
delay |
指定执行此转换时产生的延迟时间。 此延迟始终发生在完成来源访问之后，并在开始目标访问之前。 |
交通工具
对运输问题中的车辆进行建模。解决运输问题后，系统会为此车辆构建一条起点为 start_location、终点为 end_location 的路线。路线是一系列到访记录（请参阅 ShipmentRoute）。
| 字段 | |
|---|---|
display_name |
车辆的用户定义显示名称。此字符串不得超过 63 个字符，且可以使用 UTF-8 字符。 |
travel_mode |
行驶模式，会影响车辆可行驶的道路和速度。另请参阅 |
start_location |
车辆在接收任何运输包裹之前的起始地理位置。如果未指定，则车辆从首次上车开始计算。如果运输模型具有时长和距离矩阵，则不得指定 |
start_waypoint |
表示车辆在接收任何运输件之前的起始地理位置的航点。如果未指定 |
end_location |
车辆完成最后一次 |
end_waypoint |
路点，表示车辆完成最后一次 |
start_tags[] |
指定附加到车辆路线起点的标记。 不允许使用空字符串或重复的字符串。 |
end_tags[] |
指定附加到车辆路线末尾的标记。 不允许使用空字符串或重复的字符串。 |
start_time_windows[] |
车辆可以从起始位置出发的时间范围。它们必须在全球时限范围内（请参阅 属于同一重复字段的时间范围必须互不重叠，即任何时间范围都不能与其他时间范围重叠或相邻，并且必须按时间顺序排列。 只有在只有一个时间窗口时，才能设置 |
end_time_windows[] |
车辆可能到达终点位置的时间范围。它们必须在全球时限范围内（请参阅 属于同一重复字段的时间范围必须互不重叠，即任何时间范围都不能与其他时间范围重叠或相邻，并且必须按时间顺序排列。 只有在只有一个时间窗口时，才能设置 |
unloading_policy |
对车辆强制执行的卸载政策。 |
load_limits |
车辆的载重量（例如重量、体积、托盘数量）。映射中的键是负载类型的标识符，与 |
cost_per_hour |
车辆费用：所有费用相加，且必须与 车辆路线的每小时费用。此费用适用于相应路线所花费的总时间，包括行驶时间、等待时间和访问时间。使用 |
cost_per_traveled_hour |
车辆路线每小时的费用。此费用仅适用于路线所需的旅行时间（即 |
cost_per_kilometer |
车辆路线的每公里费用。此费用适用于 |
fixed_cost |
如果此车辆用于处理运输，则应用的固定费用。 |
used_if_route_is_empty |
此字段仅适用于其路线未配送任何运输的车辆。它表示在这种情况下，车辆是否应被视为二手车。 如果为 true，则车辆会从起始位置前往终点位置（即使没有运送任何运输），并且系统会考虑从起始位置到终点位置的旅行时间和距离费用。 否则，车辆不会从起始位置前往终点位置，并且系统不会为此车辆安排 |
route_duration_limit |
适用于车辆路线总时长的限制。在给定 |
travel_duration_limit |
对车辆行驶路线的旅行时长施加的限制。在给定 |
route_distance_limit |
适用于车辆行程总里程的限制。在给定的 |
extra_visit_duration_for_visit_type |
指定从 visit_types 字符串到时长的映射。时长是指在使用指定 如果访问请求具有多种类型，系统会在映射中为每种类型添加时长。 |
break_rule |
说明要强制执行在此车辆上的休息时间表。如果为空，则系统不会为此车辆安排休息时间。 |
label |
为此车辆指定标签。此标签会在响应中报告为相应 |
ignore |
如果为 true，则 如果运输由 如果运输由 |
travel_duration_multiple |
指定一个乘数，可用于增加或缩短此车辆的旅行时间。例如，将此值设置为 2.0 表示此车辆的速度较慢，行程时间是标准车辆的两倍。此倍数不会影响访问时长。如果指定了 警告：在应用此倍数后，但在执行任何数值运算之前，行程时间将舍入到最接近的秒数，因此，较小的倍数可能会导致精度损失。 另请参阅下面的 |
DurationLimit
用于定义车辆路线时长上限的限制。它可以是硬的，也可以是软的。
定义软上限字段时，必须同时定义软上限阈值及其关联的费用。
| 字段 | |
|---|---|
max_duration |
硬限制，将时长限制为不超过 max_duration。 |
soft_max_duration |
软性限制不会强制执行时长上限，但如果违反此限制，相应路线会产生费用。此费用与模型中定义的其他费用相加，单位相同。 如果已定义， |
quadratic_soft_max_duration |
软限制不会强制执行时长上限，但如果违反此限制，路线会产生费用，费用与时长成二次方关系。此费用与模型中定义的其他费用相加，单位相同。 如果已定义，
|
cost_per_hour_after_soft_max |
如果违反 费用必须为非负数。 |
cost_per_square_hour_after_quadratic_soft_max |
如果违反 如果时长低于阈值，则额外费用为 0；否则，费用取决于时长，如下所示： 费用必须为非负数。 |
LoadLimit
定义适用于车辆的载重限制，例如“此卡车载重不得超过 3500 千克”。请参阅 load_limits。
| 字段 | |
|---|---|
soft_max_load |
负载的软上限。请参阅 |
cost_per_unit_above_soft_max |
如果此车辆的路线上的载荷超过 |
start_load_interval |
车辆在路线起点处的可接受载荷间隔。 |
end_load_interval |
车辆在路线结束时可接受的载荷间隔。 |
max_load |
可接受的最大负载量。 |
间隔
可接受的加载量间隔。
| 字段 | |
|---|---|
min |
|
max |
可接受的最大负载。必须大于等于 0。如果未指定，则此消息不会限制最大负载。如果同时指定了 |
TravelMode
车辆可使用的出行方式。
这些应是 Google Maps Platform 路线首选 API 出行方式的子集，请参阅：https://developers.google.com/maps/documentation/routes_preferred/reference/rest/Shared.Types/RouteTravelMode。
| 枚举 | |
|---|---|
TRAVEL_MODE_UNSPECIFIED |
未指定的出行方式，相当于 DRIVING。 |
DRIVING |
与驾车路线对应的出行方式（汽车等）。 |
WALKING |
与步行路线对应的出行方式。 |
UnloadingPolicy
有关如何卸车的政策。仅适用于同时包含自提和送货服务的配送。
其他运输可以随意在路线上的任何位置进行，不受 unloading_policy 的影响。
| 枚举 | |
|---|---|
UNLOADING_POLICY_UNSPECIFIED |
未指定卸货政策；送货必须在相应上货后进行。 |
LAST_IN_FIRST_OUT |
送货必须按取件顺序的反向顺序进行 |
FIRST_IN_FIRST_OUT |
送货顺序必须与上门取件顺序相同 |
航点
封装航点。路点用于标记 VisitRequest 的到达和出发地点，以及车辆的起始和终点位置。
| 字段 | |
|---|---|
side_of_road |
可选。指示此航点的位置是指示车辆在道路的特定侧停车的偏好设置。设置此值后，路线将穿过相应位置，以便车辆在相应位置偏离道路中心的一侧停车。此选项不适用于“步行”出行方式。 |
联合字段 location_type。表示地理位置的不同方式。location_type 只能是下列其中一项： |
|
location |
使用地理坐标指定的点，包括可选的航向。 |
place_id |
与航点关联的地图注点地点 ID。 |