车辆的路线可以沿时间轴分解,如下所示(假设有 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 | | | | ||
|| | | | | | | ||
--++-----------------------------------------------------------------++-->
JSON 表示法 |
---|
{ "vehicleIndex": integer, "vehicleLabel": string, "vehicleStartTime": string, "vehicleEndTime": string, "visits": [ { object ( |
字段 | |
---|---|
vehicleIndex |
执行路线的车辆,由其在来源 |
vehicleLabel |
执行此路线的车辆的标签,等于 |
vehicleStartTime |
车辆开始行驶路线的时间。 时间戳采用 RFC3339 世界协调时间(UTC,即“祖鲁时”)格式,精确到纳秒,最多九个小数位。示例: |
vehicleEndTime |
车辆完成行驶路线的时间。 时间戳采用 RFC3339 世界协调时间(UTC,即“祖鲁时”)格式,精确到纳秒,最多九个小数位。示例: |
visits[] |
表示路线的访问有序序列。visits[i] 是路线中的第 i 次访问。如果此字段为空,车辆会被视为未使用。 |
transitions[] |
相应路线的转换的有序列表。 |
hasTrafficInfeasibilities |
如果
由于交通原因,预计行程时间 ( |
routePolyline |
路线的编码多段线表示法。只有当 |
breaks[] |
为执行此路线的车辆安排的休息时间。 |
metrics |
此路线的时长、距离和载荷指标。系统会对所有 |
routeCosts |
路由的费用,按与费用相关的请求字段细分。键是相对于输入 OptimizationToursRequest(例如“model.shipments.pickups.cost”)的 proto 路径,值是相应费用字段生成的总费用(汇总了整个路线)。换句话说,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 |
访问的开始时间。请注意,车辆可能会提前到达上门服务地点。时间与 时间戳采用 RFC3339 世界协调时间(UTC,即“祖鲁时”)格式,精确到纳秒,最多九个小数位。示例: |
loadDemands |
总访问加载需求,即运单和访问请求 |
detour |
由于在到达前往目的地之前,路线上还有其他要配送的运输包裹,以及由于时间范围而可能产生的等待时间,因此产生的额外绕道时间。如果访问是送餐,系统会根据相应的取货造访计算绕行时间,并且等于:
否则,它根据车辆
该时长以秒为单位,最多包含九个小数位,以“ |
shipmentLabel |
相应 |
visitLabel |
相应 |
转换
路线上两个事件之间的转换。请参阅 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 |
此转换的开始时间。 时间戳采用 RFC3339 世界协调时间(UTC,即“祖鲁时”)格式,精确到纳秒,最多九个小数位。示例: |
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 |
表示多段线的编码点的字符串。 |
休息时间
表示执行 break 的数据。
JSON 表示法 |
---|
{ "startTime": string, "duration": string } |
字段 | |
---|---|
startTime |
休息时间的开始时间。 时间戳采用 RFC3339 世界协调时间(UTC,即“祖鲁时”)格式,精确到纳秒,最多九个小数位。示例: |
duration |
休息时长。 该时长以秒为单位,最多包含九个小数位,以“ |