车辆的路线可以沿时间轴分解,如下所示(假设有 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 的安排方式。
- 它们不会重叠。
- 延迟时间是唯一的,必须是下一次访问(或车辆结束)之前的连续时间段。因此,只需知道延迟时长,即可知道其开始时间和结束时间。
- 中断是连续且不重叠的时间段。响应会指定每次中断的开始时间和时长。
- TRAVEL 和 WAIT 是“可抢占”的:它们可以在此过渡期间多次中断。客户端可以假设 TRAVEL 会“尽快”发生,而“等待”会填补剩余时间。
一个(复杂)示例:
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 | | | | ||
|| | | | | | | ||
--++-----------------------------------------------------------------++-->
| JSON 表示法 |
|---|
{ "vehicleIndex": integer, "vehicleLabel": string, "vehicleStartTime": string, "vehicleEndTime": string, "visits": [ { object ( |
| 字段 | |
|---|---|
vehicleIndex |
执行路线的车辆,由其在来源 |
vehicleLabel |
执行此路线的车辆的标签,如果指定,则等于 |
vehicleStartTime |
车辆开始行驶路线的时间。 采用 RFC 3339 标准,生成的输出将始终进行 Z 规范化(即转换为 UTC 零时区格式并在末尾附加 Z),并使用 0、3、6 或 9 个小数位。不进行“Z”归一化处理的偏差时间也是可以接受的。示例: |
vehicleEndTime |
车辆完成路线的时间。 采用 RFC 3339 标准,生成的输出将始终进行 Z 规范化(即转换为 UTC 零时区格式并在末尾附加 Z),并使用 0、3、6 或 9 个小数位。不进行“Z”归一化处理的偏差时间也是可以接受的。示例: |
visits[] |
表示路线的有序访问序列。visits[i] 是路线中的第 i 次访问。如果此字段为空,则表示车辆未被使用。 |
transitions[] |
相应路由的有序转换列表。 |
hasTrafficInfeasibilities |
当 由于交通状况导致出行时间估计值 |
routePolyline |
路线的编码多段线表示法。只有当 |
breaks[] |
执行此路线的车辆的预定休息时间。 |
metrics |
相应路线的时长、距离和负载指标。 |
vehicleFullness |
实验性:此字段的行为或存在状态将来可能会发生变化。 |
routeCosts |
路线的费用,按与费用相关的请求字段细分。键是相对于输入 OptimizeToursRequest 的 proto 路径,例如“model.shipments.pickups.cost”,值是相应费用字段生成的总费用,汇总了整个路线的费用。换句话说,costs["model.shipments.pickups.cost"] 是路线中所有取货费用的总和。模型中定义的所有费用都会在此处详细报告,但与 TransitionAttributes 相关的费用除外,这些费用自 2022 年 1 月起仅以汇总方式报告。 |
routeTotalCost |
路线的总费用。费用地图中所有费用的总和。 |
访问
在路线期间进行的拜访。此访问记录对应于 Shipment 的取件或送件。
| JSON 表示法 |
|---|
{ "shipmentIndex": integer, "isPickup": boolean, "visitRequestIndex": integer, "startTime": string, "loadDemands": { string: { object ( |
| 字段 | |
|---|---|
shipmentIndex |
来源 |
isPickup |
如果为 true,则表示相应访问是取货访问。否则,表示相应访问是送货访问。 |
visitRequestIndex |
|
startTime |
访问的开始时间。请注意,车辆可能会比此时间更早到达访问地点。时间与 采用 RFC 3339 标准,生成的输出将始终进行 Z 规范化(即转换为 UTC 零时区格式并在末尾附加 Z),并使用 0、3、6 或 9 个小数位。不进行“Z”归一化处理的偏差时间也是可以接受的。示例: |
loadDemands |
总访问负载需求,即货件和访问请求 |
detour |
由于在到访之前访问了路线上的其他配送点,以及时间窗口可能造成的等待时间,而产生的额外绕行时间。如果到访是送货,则绕行时间是从相应的取货到访计算得出的,等于: 否则,该值将根据车辆 该时长以秒为单位,最多包含九个小数位,以“ |
shipmentLabel |
相应 |
visitLabel |
相应 |
visitType |
可选。指定访问类型。替换 |
injectedSolutionLocationToken |
一个不透明的令牌,表示有关访问位置的信息。 如果相应访问的 实验性功能:如需了解详情,请参阅 https://developers.google.com/maps/tt/route-optimization/experimental/u-turn-avoidance/make-request。 |
VisitType
表示相应访问是自提、送货上门还是对 Stop 的访问。仅当启用多模态优化时,才会使用对 Stop 的访问。
| 枚举 | |
|---|---|
VISIT_TYPE_UNSPECIFIED |
未指定访问类型。 |
PICKUP_SHIPMENT |
访问对应于取件。 |
DELIVER_SHIPMENT |
访问对应于送货。 |
过渡
路线中两个事件之间的过渡。请参阅 ShipmentRoute 的说明。
如果车辆没有 startLocation 和/或 endLocation,则相应的出行指标为 0。
| JSON 表示法 |
|---|
{ "travelDuration": string, "travelDistanceMeters": number, "trafficInfoUnavailable": boolean, "delayDuration": string, "breakDuration": string, "waitDuration": string, "totalDuration": string, "startTime": string, "routePolyline": { object ( |
| 字段 | |
|---|---|
travelDuration |
此过渡期间的旅行时长。 该时长以秒为单位,最多包含九个小数位,以“ |
travelDistanceMeters |
过渡期间的行驶距离。 |
trafficInfoUnavailable |
当通过 |
delayDuration |
应用于相应过渡的延迟时长的总和。如果有延迟,则延迟会在下一个事件(到访或车辆结束)开始前 该时长以秒为单位,最多包含九个小数位,以“ |
breakDuration |
相应过渡期间发生的插播广告的时长总和(如有)。有关每次中断的开始时间和时长的详细信息存储在 该时长以秒为单位,最多包含九个小数位,以“ |
waitDuration |
在此过渡期间的等待时间。等待时长对应于空闲时间,不包括休息时间。另请注意,此等待时间可能会分为多个不连续的时间段。 该时长以秒为单位,最多包含九个小数位,以“ |
totalDuration |
过渡的总时长,为方便起见而提供。它等于:
该时长以秒为单位,最多包含九个小数位,以“ |
startTime |
相应过渡的开始时间。 采用 RFC 3339 标准,生成的输出将始终进行 Z 规范化(即转换为 UTC 零时区格式并在末尾附加 Z),并使用 0、3、6 或 9 个小数位。不进行“Z”归一化处理的偏差时间也是可以接受的。示例: |
routePolyline |
过渡期间所遵循路线的编码多段线表示法。只有当 |
routeToken |
仅限输出。一个不透明的令牌,可传递给 Navigation SDK,以便在导航期间重建路线,并在重新规划路线时遵循创建路线时的原始意图。将此令牌视为不透明 blob。请勿跨请求比较其值,因为即使服务返回完全相同的路线,其值也可能会发生变化。只有当 |
vehicleLoads |
相应车辆在过渡期间的载重,针对的是该车辆的 第一次过渡期间的载荷是车辆路线的起始载荷。然后,在每次访问之后,系统会根据访问是取货还是送货,将访问的 |
EncodedPolyline
多段线的编码表示法。如需详细了解多段线编码,请访问以下网址:https://developers.google.com/maps/documentation/utilities/polylinealgorithm https://developers.google.com/maps/documentation/javascript/reference/geometry#encoding。
| JSON 表示法 |
|---|
{ "points": string } |
| 字段 | |
|---|---|
points |
表示多段线的编码点的字符串。 |
休息时间
表示中断执行的数据。
| JSON 表示法 |
|---|
{ "startTime": string, "duration": string } |
| 字段 | |
|---|---|
startTime |
休息的开始时间。 采用 RFC 3339 标准,生成的输出将始终进行 Z 规范化(即转换为 UTC 零时区格式并在末尾附加 Z),并使用 0、3、6 或 9 个小数位。不进行“Z”归一化处理的偏差时间也是可以接受的。示例: |
duration |
休息时长。 该时长以秒为单位,最多包含九个小数位,以“ |
VehicleFullness
VehicleFullness 是一种用于计算车辆满载程度的指标。每个 VehicleFullness 字段的值都介于 0 和 1 之间,计算方式为有上限的指标字段(例如 AggregatedMetrics.travel_distance_meters)与其相关车辆限值(例如 Vehicle.route_distance_limit)的比率(如果存在)。否则,饱腹感比率将保持未设置状态。如果限制为 0,则该字段设置为 1。注意:如果路线存在流量不可行性,某些原始满载率可能会超过 1.0,例如,车辆可能会超出其距离限制。在这些情况下,我们会将饱腹度值上限设为 1.0。
| JSON 表示法 |
|---|
{ "maxFullness": number, "distance": number, "travelDuration": number, "activeDuration": number, "maxLoad": number, "activeSpan": number } |
| 字段 | |
|---|---|
maxFullness |
相应消息中所有其他字段的最大值。 |
distance |
|
travelDuration |
[AggregatedMetrics.travel_duration_seconds][] 与 |
activeDuration |
[AggregatedMetrics.total_duration_seconds][] 与 |
maxLoad |
所有类型的 [AggregatedMetrics.max_load][] 及其各自的 |
activeSpan |
给定车辆的(vehicleEndTime - vehicleStartTime)/(latestVehicleEndTime - earliestVehicleStartTime)比率。如果不存在分母,则改用( |