索引
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)。用于优化的输入(
|
OptimizeTours |
---|
发送包含
目标是为
|
AggregatedMetrics
ShipmentRoute
(反映OptimizeToursResponse
所有 Transition
和/或 Visit
(针对所有 ShipmentRoute
)元素的汇总指标。
字段 | |
---|---|
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 |
Protocol Buffers 文本格式。请参阅 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 |
必需。Google Cloud Storage 对象的 URI,格式为 |
InjectedSolutionConstraint
已注入到请求中的解决方案,包括有关必须限制哪些访问以及如何限制访问的信息。
字段 | |
---|---|
routes[] |
要注入的解决方案的路由。原始解决方案中可能会省略某些路由。航线和跳过的运单必须满足针对 |
skipped_shipments[] |
跳过了要注入的解决方案的发货步骤。原始解决方案中可能会省略一些内容。请参阅 |
constraint_relaxations[] |
对于零组或多组车辆,指定放宽约束的时间和程度。如果此字段为空,则所有非空车辆路线将完全限制。 |
ConstraintRelaxation
对于一组车辆,指定在哪些阈值下放宽到访地点限制以及将放宽到哪个级别。skipped_shipment
字段列出的发运只能跳过,也就是说,无法执行这些运单。
字段 | |
---|---|
relaxations[] |
所有访问限制条件放宽限制,适用于 |
vehicle_indices[] |
指定访问限制条件 如果 |
娱乐
如果 relaxations
为空,则 routes
上所有访问的开始时间和顺序均受完全约束,无法向这些路线插入或添加新的访问。此外,车辆在 routes
中的开始和结束时间完全约束,除非车辆是空的(即没有到访记录并将模型中的 used_if_route_is_empty
设置为 false)。
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:
此解释适用于 如果为 true,则以下类别的标签在其类别中最多只能出现一次:
如果注入的解决方案中的 从注入的解决方案中移除路线造访记录或整个路线可能会影响隐含的约束条件,进而可能导致解决方案发生变化、验证错误或不可行。 注意:调用方必须确保每个 |
consider_road_traffic |
在计算 |
populate_polylines |
如果为 true,系统会在响应 |
populate_transition_polylines |
如果为 true,将在响应 |
allow_large_deadline_despite_interruption_risk |
如果设置了此属性,则请求的截止时间(请参阅 https://grpc.io/blog/deadlines)最长为 60 分钟。否则,最长期限仅为 30 分钟。请注意,对于长期请求,中断的风险显著较大(但仍然很小)。 |
use_geodesic_distances |
如果为 true,则使用测地距离(而不是 Google 地图距离)计算行程距离,并且使用测地距离计算行程时间,速度由 |
label |
可用于识别此请求的标签,在 |
geodesic_meters_per_second |
当 |
max_validation_errors |
截断返回的验证错误数。这些错误通常以 BadRequest 错误详情的形式附加到 INVALID_STRING 错误载荷中 (https://cloud.google.com/apis/design/errors#error_details),除非 resolve_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 |
求解模型。 |
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”,值是相应费用字段生成的总费用,在整个解决方案中进行了汇总。换句话说,费用 ["model.shipments.pickups.cost"] 是解决方案中所有自提费用的总和。此处报告了模型中定义的所有费用,但与 TransitionAttributes 相关的费用除外,这些费用在 2022 年 1 月之前仅以汇总方式报告。 |
total_cost |
解决方案的总费用。费用映射中所有值的总和。 |
OptimizeToursValidationError
描述验证 OptimizeToursRequest
时遇到的错误。
字段 | |
---|---|
code |
验证错误由始终存在的键值对( 其他字段(见下文)提供了有关该错误的更多背景信息。 多个错误:当存在多个错误时,验证流程会尝试输出多个错误。这个过程与编译器非常相似,但并不完美。有些验证错误是“严重”错误,也就是说,这些错误会停止整个验证流程。 STABILITY: 参考:所有(代码、名称)对的列表:
|
display_name |
错误的显示名称。 |
fields[] |
错误上下文可能涉及 0、1(大多数情况下)或更多字段。例如,引用车辆 4 和运单 2 的首次取货,可如下执行:
但请注意, |
error_message |
用于描述错误的一种人类可读字符串。 STABILITY:不稳定:与给定 |
offending_values |
可能包含字段值。此功能并非始终可用。您绝对不应该依赖它,而是仅将其用于手动模型调试。 |
FieldReference
指定验证错误的上下文。FieldReference
始终引用此文件中的给定字段,并遵循相同的层次结构。例如,我们可以使用以下命令指定车辆 5 的 start_time_windows
的元素 #2:
name: "vehicles" index: 5 sub_field { name: "end_time_windows" index: 2 }
不过,我们会省略 OptimizeToursRequest
或 ShipmentModel
等顶级实体,以避免拥挤消息。
字段 | |
---|---|
name |
字段的名称,例如“车辆”。 |
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 |
指定此 |
ShipmentModel
装运模型包含一组装运,这些装运必须由一组车辆执行,同时最大限度地降低总成本,即以下总和:
- 规划车辆路线的费用(每总时间费用、每次行程时间费用和所有车辆的固定费用的总和)。
- 未履行的发货处罚。
- 全球运单产生的费用
字段 | |
---|---|
shipments[] |
必须在模型中执行的一组装运。 |
vehicles[] |
可用于到访地点的一组车辆。 |
global_start_time |
模型的全局开始时间和结束时间:凡是超出此范围的时间均不会被视为有效。 模型的时间跨度必须少于一年,即 使用 |
global_end_time |
如果未设置,则默认使用世界协调时间 (UTC) 1971 年 1 月 1 日 00:00:00(即秒:31536000,nanos: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[] |
不兼容的 shipping_types [运单类型] 集(请参阅 |
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 |
指明“second”事件是否为传送。 |
offset_duration |
“first”和“second”事件之间的偏移量。此值可以为负数。 |
first_index |
“first”事件的装运索引。必须指定此字段。 |
second_index |
“second”事件的发货索引。必须指定此字段。 |
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。
- 它们不会重叠。
- 延迟是唯一的,必须是下次访问(或车辆结束)之前的连续时间段。因此,知道延迟时长即可知道其开始时间和结束时间。
- 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 |
路线的费用,按与费用相关的请求字段细分。键是相对于输入 OptimizationToursRequest 的 proto 路径,例如“model.shipments.pickups.cost”,值是相应费用字段生成的总费用,在整个路线中汇总。换句话说,cost["model.shipments.pickups.cost"] 是沿途所有自提费用的总和。此处报告了模型中定义的所有费用,但与 TransitionAttributes 相关的费用除外,这些费用在 2022 年 1 月之前仅以汇总方式报告。 |
route_total_cost |
路线的总费用。费用映射中所有费用的总和。 |
休息时间
表示广告插播执行的数据。
字段 | |
---|---|
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 |
相应 |
ShipmentTypeIncompatibility
根据 shipping_type [运单类型] 指定发货间的不兼容问题。根据不兼容模式,在同一航线中显示不兼容的配送选项会受到限制。
字段 | |
---|---|
types[] |
不兼容的类型列表。所列两批货运的 |
incompatibility_mode |
应用于不兼容的模式。 |
IncompatibilityMode
用于指定如何在同一航线上限制不兼容的运单的显示模式。
枚举 | |
---|---|
INCOMPATIBILITY_MODE_UNSPECIFIED |
未指定的不兼容模式。不应使用此值。 |
NOT_PERFORMED_BY_SAME_VEHICLE |
在此模式下,两批货物类型不兼容,绝不会共用同一辆车。 |
NOT_IN_SAME_VEHICLE_SIMULTANEOUSLY |
对于两件货物,其类型与“
|
ShipmentTypeRequirement
根据 shipping_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_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` <= `soft_start_time` <= `end_time` and
0 <= `start_time` <= `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 Routes Preferred 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。 |