- JSON 表示法
- 装运
- VisitRequest
- LatLng
- 航点
- 位置
- TimeWindow
- 车辆
- TravelMode
- 路由修饰符
- UnloadingPolicy
- LoadLimit
- 间隔时间
- LoadCost
- DurationLimitDurationLimit
- DistanceLimit
- BreakRule
- BreakRequest
- FrequencyConstraint
- DurationDistanceMatrix
- 行
- TransitionAttributes
- ShipmentTypeIncompatibility
- IncompatibilityMode
- ShipmentTypeRequirement
- RequirementMode
- PrecedenceRule
一个运单模式包含一组必须由一组车辆执行运单,同时最大限度地降低总体成本,即:
- 车辆路线规划费用(所有车辆的总时间费用、行驶时间费用和固定费用之和)。
- 不履行的发货惩罚。
- 全球运送时间的费用
JSON 表示法 |
---|
{ "shipments": [ { object ( |
字段 | |
---|---|
shipments[] |
必须在模型中执行的一组配送。 |
vehicles[] |
可用于执行访问的一组车辆。 |
globalStartTime |
模型的全局开始时间和结束时间:此范围以外的时间都不能视为有效时间。 模型的时间跨度不得超过 1 年,即 使用 时间戳采用 RFC3339 世界协调时间(UTC,即“祖鲁时”)格式,精确到纳秒,最多九个小数位。示例: |
globalEndTime |
如果未设置,系统将使用世界协调时间 (UTC) 1971 年 1 月 1 日 00:00:00 作为默认值(即秒:31536000,纳米:0)。 时间戳采用 RFC3339 世界协调时间(UTC,即“祖鲁时”)格式,精确到纳秒,最多九个小数位。示例: |
globalDurationCostPerHour |
整个方案的“总时长”是指所有车辆的最早有效开始时间与最晚有效结束时间之间的差值。例如,用户可以为此数量指定每小时费用,以尝试进行优化,以便尽早完成作业。此费用必须与 |
durationDistanceMatrices[] |
指定模型中使用的持续时间和距离矩阵。如果此字段为空,则会根据 用法示例:
|
durationDistanceMatrixSrcTags[] |
用于定义时长和距离矩阵来源的标签; 标记对应于 |
durationDistanceMatrixDstTags[] |
用于定义时长和距离矩阵目的地的标记; 标记对应于 |
transitionAttributes[] |
添加到模型的转换属性。 |
shipmentTypeIncompatibilities[] |
不兼容的 shipment_type 集(请参阅 |
shipmentTypeRequirements[] |
|
precedenceRules[] |
必须在模型中强制执行的一组优先级规则。 |
maxActiveVehicles |
限制有效车辆的数量上限。如果车辆的路线至少完成一次送货,则车辆处于活跃状态。如果驾驶员数量少于车辆数量,并且车队是异构的,则可以使用此参数来限制路线数量。然后,优化功能会选择最佳车辆子集。必须是正数。 |
发货
单个商品的运单,从其一次自提到一次送货。为了将运输作业视为已完成,唯一车辆必须先访问其某个取件地点(并相应地减少其空闲运力),然后稍后访问其某个送货地点(并相应地重新增加其空闲运力)。
JSON 表示法 |
---|
{ "displayName": string, "pickups": [ { object ( |
字段 | |
---|---|
displayName |
用户定义的运单显示名称。长度不得超过 63 个字符,且可以使用 UTF-8 字符。 |
pickups[] |
与运单关联的一组备选自提选项。如果未指定,车辆只需访问与送货点对应的地点即可。 |
deliveries[] |
与运输订单关联的一组配送替代方案。如果未指定,车辆只需访问与上车点对应的地点即可。 |
loadDemands |
运输的载荷需求(例如重量、体积、托盘数量等)。映射中的键应为描述相应负载类型的标识符,最好还包含单位。例如:“weight_kg”“volume_gallons”“pallet_count”等。如果给定键未出现在映射中,则相应的加载会被视为 null。 |
allowedVehicleIndices[] |
可能执行此运输的车辆组。如果留空,所有车辆都可以执行此操作。车辆由 |
costsPerVehicle[] |
指定每辆车交付此运单时产生的费用。如果指定了,则必须具有以下任一属性:
这些费用的单位必须与“ |
costsPerVehicleIndices[] |
应用 |
pickupToDeliveryAbsoluteDetourLimit |
指定与从上车点到下车点的最短路径相比的绝对绕道时间上限。如果指定,则必须为非负数,并且运单中必须至少包含自提和送货信息。 例如,设 t 为从所选的取件替代方案直接前往所选的送货替代方案所需的最短时间。然后,设置
如果同一运输中同时指定了相对上限和绝对上限,则系统会对每个可能的取件/送货对使用更严格的上限。从 2017 年 10 月 10 日开始,仅当行程时长不取决于车辆时才支持绕行。 该时长以秒为单位,最多包含九个小数位,以“ |
pickupToDeliveryTimeLimit |
指定从开始自提到开始配送的最长时长。如果指定,则必须为非负数,并且运单中必须至少包含自提和送货信息。这既不取决于为自提和配送选择的替代选项,也不取决于车辆速度。此参数可与最大绕行限制一起指定:解决方案将遵循这两项规范。 该时长以秒为单位,最多包含九个小数位,以“ |
shipmentType |
非空字符串,用于指定此运单的“类型”。此功能可用于定义 与仅针对单次访问指定的 |
label |
指定此运单的标签。此标签会在响应的相应 |
ignore |
如果为 true,则跳过此配送,但不应用 如果模型中存在任何 允许忽略在 |
penaltyCost |
如果未能完成运输,则此处罚将添加到路线的总费用中。如果使用了某个自提和配送备选方式,则视为配送已完成。费用可以用用于模型中所有其他费用相关字段的相同单位表示,并且必须为正值。 重要提示:如果未指定此处罚,则会被视为无限期,即必须完成发货。 |
pickupToDeliveryRelativeDetourLimit |
指定与从上车点到下车点的最短路径相比,绕路的最大相对时间。如果指定,则必须为非负数,并且运单中必须至少包含自提和送货信息。 例如,设 t 为从所选的取件替代方案直接前往所选的送货替代方案所需的最短时间。然后,设置
如果同一批商品同时指定了相对限制和绝对限制,则系统会对每个可能的自提/送货对使用更具限制性的限制。自 2017 年 10 月起,只有在行程时长不依赖于车辆时,才支持绕道。 |
VisitRequest
请求由车辆完成的访问:它具有一个(或两个,见下文)地理位置、由时间范围表示的开业和打烊时间,以及服务时长(车辆到达取件或送货地点后所花的时间)。
JSON 表示法 |
---|
{ "arrivalLocation": { object ( |
字段 | |
---|---|
arrivalLocation |
执行此 |
arrivalWaypoint |
执行此 |
departureLocation |
车辆完成此 |
departureWaypoint |
车辆完成此 |
tags[] |
指定附加到访问请求的标记。不允许使用空字符串或重复字符串。 |
timeWindows[] |
用于约束到达时间的访问时间窗口。请注意,车辆可能会在到达时间范围之外出发,即到达时间 + 时长不必在时间范围内。如果车辆在 如果没有 时间窗口必须是不相交的,即所有时间窗口都不得与其他时间窗口重叠或相邻,并且顺序必须递增。 只有在只有一个时间窗口时,才能设置 |
duration |
访问持续时间,即车辆从到达到出发所花费的时间(将添加到可能的等待时间中;请参阅 该时长以秒为单位,最多包含九个小数位,以“ |
cost |
在车辆行驶路线上处理此访问请求的费用。此属性可用于为不同的商品自提或配送选项支付不同的费用。此费用必须与 |
loadDemands |
加载此访问请求的需求。这类似于 |
visitTypes[] |
指定访问类型。系统可能会据此分配车辆完成此次访问所需的额外时间(请参阅 一种类型只能出现一次。 |
label |
为此 |
LatLng
表示纬度/经度对的对象。该对象以一对双精度数表示,分别代表纬度度数和经度度数。除非另有说明,否则该对象必须符合 WGS84 标准。值必须介于标准化范围内。
JSON 表示法 |
---|
{ "latitude": number, "longitude": number } |
字段 | |
---|---|
latitude |
纬度(以度为单位)。它必须在 [-90.0, +90.0] 范围内。 |
longitude |
经度(以度为单位)。它必须在 [-180.0, +180.0] 范围内。 |
关键点
封装航点。路点用于标记 VisitRequest 的到达和出发位置,以及车辆的起始和终点位置。
JSON 表示法 |
---|
{ "sideOfRoad": boolean, // Union field |
字段 | |
---|---|
sideOfRoad |
可选。表示此航点的位置优先让车辆停靠在道路的某一侧。设置此值后,路线会经过相应位置,以便车辆在偏离道路中心的道路一侧停靠。此选项不适用于“步行”出行方式。 |
联合字段 location_type 。表示营业地点的不同方式。location_type 只能是下列其中一项: |
|
location |
使用地理坐标指定的点,包括可选的航向。 |
placeId |
与航点关联的地图注点地点 ID。 |
位置
封装位置(地理点和可选标题)。
JSON 表示法 |
---|
{
"latLng": {
object ( |
字段 | |
---|---|
latLng |
航点的地理坐标。 |
heading |
与交通流动方向相关联的罗盘航向。此值用于指定上车点和下车点的公路一侧。方向值的范围为 0 到 360,其中 0 指定正北方位,90 指定正北方方向,依此类推。 |
TimeWindow
时间窗口用于限制事件的时间,例如到达时间或车辆的开始时间和结束时间。
硬性时间范围边界(startTime
和 endTime
)会强制实施事件的最早和最晚时间,例如 startTime <= event_time <=
endTime
。软时间范围下限 softStartTime
表示希望事件在 softStartTime
或之后发生,其费用与事件在 softStartTime 之前发生的时间长度成正比。软时间范围上限 softEndTime
表示希望事件在 softEndTime
当天或之前发生,如果事件发生在 softEndTime
之后,则会产生与事件发生在 softEndTime
之后的时长成正比的代价。startTime
、endTime
、softStartTime
和 softEndTime
应在全球时间限制范围内(请参阅 ShipmentModel.global_start_time
和 ShipmentModel.global_end_time
),并且应遵循以下要求:
0 <= `startTime` <= `endTime` and
0 <= `startTime` <= `softStartTime` and
0 <= `softEndTime` <= `endTime`.
JSON 表示法 |
---|
{ "startTime": string, "endTime": string, "softStartTime": string, "softEndTime": string, "costPerHourBeforeSoftStartTime": number, "costPerHourAfterSoftEndTime": number } |
字段 | |
---|---|
startTime |
硬性时间范围的开始时间。如果未指定,则将设置为 时间戳采用 RFC3339 世界协调时间(UTC,即“祖鲁时”)格式,精确到纳秒,最多九个小数位。示例: |
endTime |
硬性时间范围的结束时间。如果未指定,则将设置为 时间戳采用 RFC3339 世界协调时间(UTC,即“祖鲁时”)格式,精确到纳秒,最多九个小数位。示例: |
softStartTime |
时间范围的软开始时间。 时间戳采用 RFC3339 世界协调时间(UTC,即“祖鲁时”)格式,精确到纳秒,最多九个小数位。示例: |
softEndTime |
时间范围的非强制性结束时间。 时间戳采用 RFC3339 世界协调时间(UTC,即“祖鲁时”)格式,精确到纳秒,最多九个小数位。示例: |
costPerHourBeforeSoftStartTime |
如果事件在 softStartTime 之前发生,则每小时的费用与模型中的其他费用相加,计算公式如下:
该开销必须为正数,并且只有在设置了 softStartTime 时才能设置该字段。 |
costPerHourAfterSoftEndTime |
如果事件发生在
此费用必须为正数,并且只有在已设置 |
交通工具
对运输问题中的车辆进行建模。解决运输问题后,系统会为此车辆构建一条起点为 startLocation
、终点为 endLocation
的路线。路线是一系列到访记录(请参阅 ShipmentRoute
)。
JSON 表示法 |
---|
{ "displayName": string, "travelMode": enum ( |
字段 | |
---|---|
displayName |
用户定义的车辆显示名称。此字符串不得超过 63 个字符,且可以使用 UTF-8 字符。 |
travelMode |
会影响车辆可使用的道路及其速度的出行方式。另请参阅 |
routeModifiers |
一组要满足的条件,这些条件会影响为指定车辆计算路线的方式。 |
startLocation |
车辆在接收任何运输件之前的起始地理位置。如果未指定,车辆会在首次上车点启动。如果运单模型具有时长和距离矩阵,则不得指定 |
startWaypoint |
表示车辆在接收任何运输件之前的起始地理位置的航点。如果未指定 |
endLocation |
车辆在最后一次行驶 |
endWaypoint |
路点,表示车辆完成最后一次 |
startTags[] |
指定附加到车辆路线起点的标记。 不允许使用空字符串或重复字符串。 |
endTags[] |
指定附加到车辆路线末尾的标记。 不允许使用空字符串或重复字符串。 |
startTimeWindows[] |
车辆可能离开其起始位置的时间窗口。它们必须在全局时间限制内(请参阅 属于同一重复字段的时间范围必须互不相交,即任何时间范围都不能与其他时间范围重叠或相邻,并且必须按时间顺序排列。 仅当存在单个时间范围时才能设置 |
endTimeWindows[] |
车辆可到达终点位置的时间范围。它们必须在全球时限范围内(请参阅 属于同一重复字段的时间范围必须互不相交,即任何时间范围都不能与其他时间范围重叠或相邻,并且必须按时间顺序排列。 仅当存在单个时间范围时才能设置 |
unloadingPolicy |
已在车辆上强制执行卸载政策。 |
loadLimits |
车辆容量(例如重量、体积、托盘数)。映射中的键是加载类型的标识符,与 |
costPerHour |
车辆费用:所有费用相加,且必须与“ 车辆路线的每小时费用。此费用适用于相应路线所花费的总时间,包括行驶时间、等待时间和访问时间。使用 |
costPerTraveledHour |
车辆行驶路线每小时的费用。此费用仅适用于路线所需的旅行时间(即 |
costPerKilometer |
车辆行驶的每公里费用。此开销适用于 |
fixedCost |
如果此车辆用于处理运输,则应用的固定费用。 |
usedIfRouteIsEmpty |
此字段仅适用于其路线未配送任何运输的车辆。它表示在这种情况下,车辆是否应被视为二手车。 如果为 true,则车辆会从起始位置前往终点位置(即使没有运送任何运输),并且系统会考虑从起始位置到终点位置的旅行时间和距离费用。 否则,它不会从出发位置前往目的地,并且没有为此车辆安排 |
routeDurationLimit |
适用于车辆路线总时长的限制。在给定 |
travelDurationLimit |
应用于车辆路线行程时长的限制。在给定的 |
routeDistanceLimit |
应用于车辆路线的总距离的限制。在给定的 |
extraVisitDurationForVisitType |
指定从 visitTypes 字符串到时长的映射。时长是指在使用指定 如果访问请求具有多种类型,系统会在映射中为每种类型添加时长。 |
breakRule |
说明要强制执行在此车辆上的休息时间表。如果为空,则不会为此车辆安排休息时间。 |
label |
为此车辆指定标签。此标签会在响应中报告为相应 |
ignore |
如果设为 true, 如果配送由 如果配送由忽略的车辆在 |
travelDurationMultiple |
指定可用于延长或缩短此车辆行程时间的乘法系数。例如,将此值设为 2.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 |
与步行路线对应的出行方式。 |
RouteModifiers
封装了一组在计算车辆路线时需要满足的可选条件。这类似于 Google Maps Platform Routes Preferred API 中的 RouteModifiers
;请参阅:https://developers.google.com/maps/documentation/routes/reference/rest/v2/RouteModifiers。
JSON 表示法 |
---|
{ "avoidTolls": boolean, "avoidHighways": boolean, "avoidFerries": boolean, "avoidIndoor": boolean } |
字段 | |
---|---|
avoidTolls |
指定是否在合理情况下避开收费公路。优先考虑不包含收费路段的路线。仅适用于机动出行方式。 |
avoidHighways |
指定是否在合理情况下避开高速公路。优先考虑不包含高速公路的路线。仅适用于机动化出行方式。 |
avoidFerries |
指定是否在合理情况下避开轮渡。对于不包含轮渡旅行的路线,系统会优先考虑该路线。仅适用于机动出行方式。 |
avoidIndoor |
可选。指定是否在合理情况下避免在室内导航。系统会优先显示不包含室内导航的路线。仅适用于 |
UnloadingPolicy
关于如何卸载车辆的政策。仅适用于同时包含自提和送货服务的配送。
其他运输可以随意在路线上的任何位置进行,不受 unloadingPolicy
的影响。
枚举 | |
---|---|
UNLOADING_POLICY_UNSPECIFIED |
未指定的卸载政策;只有在相应的上车点后才发货。 |
LAST_IN_FIRST_OUT |
送货必须按照取件顺序的反向顺序进行 |
FIRST_IN_FIRST_OUT |
送货顺序必须与上门取件顺序相同 |
LoadLimit
定义适用于车辆的载重限制,例如“此卡车载重不得超过 3500 千克”。请参阅 loadLimits
。
JSON 表示法 |
---|
{ "softMaxLoad": string, "costPerUnitAboveSoftMax": number, "startLoadInterval": { object ( |
字段 | |
---|---|
softMaxLoad |
负载的软性限制。请参阅 |
costPerUnitAboveSoftMax |
如果此车辆的路线上的载荷超出 |
startLoadInterval |
车辆在路线起点的可接受装入间隔时间。 |
endLoadInterval |
车辆在路线终点处的可接受载重间隔。 |
maxLoad |
可接受的最大负载量。 |
costPerKilometer |
这辆车将一个单位的重量移动一公里以上的费用。该值可以用作燃料消耗的替代指标:如果负载是一个重量(以牛顿为单位),则负载*公里具有能量维度。 |
costPerTraveledHour |
这辆车每小时的交通费用。 |
间隔
可接受的加载量间隔。
JSON 表示法 |
---|
{ "min": string, "max": string } |
字段 | |
---|---|
min |
|
max |
可接受的最大负载。必须 ≥ 0。如果未指定最大负载,则不受此消息限制。如果同时指定这两者,则 |
LoadCost
在 Transition
期间移动 1 个单位负载的开销。对于给定负载,费用是以下两部分的总和:
- min(加载,
loadThreshold
) *costPerUnitBelowThreshold
- max(0, load -
loadThreshold
) *costPerUnitAboveThreshold
在这种情况下,解决方案会优先传送高需求,或者等到最后才传送高需求。例如,如果车辆具有
load_limit {
key: "weight"
value {
costPerKilometer {
loadThreshold: 15
costPerUnitBelowThreshold: 2.0
costPerUnitAboveThreshold: 10.0
}
}
}
其路线是 start、pickup、pickup、delivery、delivery、end with transition :
transition { vehicle_load['weight'] { amount: 0 }
travelDistanceMeters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
travelDistanceMeters: 1000.0 }
transition { vehicle_load['weight'] { amount: 20 }
travelDistanceMeters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
travelDistanceMeters: 1000.0 }
transition { vehicle_load['weight'] { amount: 0 }
travelDistanceMeters: 1000.0 }
则此 LoadCost
产生的费用为 (cost_below * load_below * kilometers + cost_above * load_above * kms)
- 过渡 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
- 过渡 3:2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
- 过渡 4:0.0
因此,路由上的 LoadCost
为 120.0。
但是,如果路线是 start,pickup,delivery,pickup,delivery,end with transition [开始、提货、送货、提货、送货、结束]:
transition { vehicle_load['weight'] { amount: 0 }
travelDistanceMeters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
travelDistanceMeters: 1000.0 }
transition { vehicle_load['weight'] { amount: 0 }
travelDistanceMeters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
travelDistanceMeters: 1000.0 }
transition { vehicle_load['weight'] { amount: 0 }
travelDistanceMeters: 1000.0 }
那么此LoadCost
产生的费用为
- transition 0: 0.0
- 过渡效果 1:2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
- 过渡 2:0.0
- 过渡效果 3:2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
- 过渡 4:0.0
在这里,整个路线的 LoadCost
为 40.0。
LoadCost
使具有高负载过渡的解决方案的开销更高。
JSON 表示法 |
---|
{ "loadThreshold": string, "costPerUnitBelowThreshold": number, "costPerUnitAboveThreshold": number } |
字段 | |
---|---|
loadThreshold |
负载量,如果负载量超过此值,则移动一个单位负载的费用将从 costPerUnitBelowThreshold 更改为 costPerUnitAboveThreshold。必须大于等于 0。 |
costPerUnitBelowThreshold |
移动单位负载的费用,对于 0 到阈值之间的每个单位。必须是有限值,且大于等于 0。 |
costPerUnitAboveThreshold |
每超出阈值一个单位的负载,移动该单位负载的费用。在特殊情况下,如果阈值 = 0,则表示每单位固定费用。必须是有限值,且大于等于 0。 |
DurationLimit
定义车辆路线的最大时长的限制。它可以是硬的,也可以是软的。
定义软性限制字段后,必须同时定义软最大阈值及其相关费用。
JSON 表示法 |
---|
{ "maxDuration": string, "softMaxDuration": string, "quadraticSoftMaxDuration": string, "costPerHourAfterSoftMax": number, "costPerSquareHourAfterQuadraticSoftMax": number } |
字段 | |
---|---|
maxDuration |
一个硬限制,用于限制时长不得超过 maxDuration。 该时长以秒为单位,最多包含九个小数位,以“ |
softMaxDuration |
软性限制,未强制实施时长上限,但如果违反,则会导致路线产生费用。此费用与模型中定义的其他费用相加,单位相同。 如果已定义,则 该时长以秒为单位,最多包含九个小数位,以“ |
quadraticSoftMaxDuration |
不强制执行时长上限的软性限制,但如果违反,会导致路线产生费用,即持续时间的二次方。此费用与模型中定义的其他费用相加,单位相同。 如果已定义,
该时长以秒为单位,最多包含九个小数位,以“ |
costPerHourAfterSoftMax |
违反
费用必须为非负数。 |
costPerSquareHourAfterQuadraticSoftMax |
违反 如果时长低于阈值,则额外费用为 0,否则费用取决于时长,如下所示:
费用必须是非负数。 |
DistanceLimit
用于定义可行驶的最大距离的限制。它可以是硬的,也可以是软的。
如果定义了软性限制,则必须将 softMaxMeters
和 costPerKilometerAboveSoftMax
都定义为非负数。
JSON 表示法 |
---|
{ "maxMeters": string, "softMaxMeters": string, "costPerKilometerBelowSoftMax": number, "costPerKilometerAboveSoftMax": number } |
字段 | |
---|---|
maxMeters |
一个硬限制,用于限制距离不得超过 maxMeters。上限必须是非负数。 |
softMaxMeters |
软限制不会强制执行最长距离限制,但如果违反了此限制,则会产生费用,该费用会与模型中定义的其他费用相加,并采用相同的单位。 如果定义的 softMaxMeters 必须小于 maxMeters,则必须为非负数。 |
costPerKilometerBelowSoftMax |
产生的每公里费用,最多可增加
|
costPerKilometerAboveSoftMax |
如果距离超过
费用必须为非负数。 |
BreakRule
用于为车辆生成时间休息时段(例如午餐休息时段)的规则。休息时间是指车辆在其当前位置保持空闲状态且无法执行任何访问的连续时间段。中断可能会发生在以下情况:
- 在两次访问之间间隔的时间(包括访问之前或之后,但不在访问过程中的时间),在这种情况下,它会延长两次访问之间的相应运送时间,
- 或车辆开始前(车辆可能不会在休息期间启动),在这种情况下,启动时间不影响车辆的启动时间。
- 或在车辆结束时间之后(同上,使用车辆结束时间)。
JSON 表示法 |
---|
{ "breakRequests": [ { object ( |
字段 | |
---|---|
breakRequests[] |
休息时间序列。查看 |
frequencyConstraints[] |
可能有多个 |
BreakRequest
您必须事先知道适用于每辆车的插播时间点(即其编号和顺序)的顺序。重复的 BreakRequest
定义了该序列,并按其必须出现的顺序进行定义。它们的时间范围 (earliestStartTime
/ latestStartTime
) 可以重叠,但必须与订单兼容(已勾选)。
JSON 表示法 |
---|
{ "earliestStartTime": string, "latestStartTime": string, "minDuration": string } |
字段 | |
---|---|
earliestStartTime |
必需。休息时间开始的下限(包括该时间)。 时间戳采用 RFC3339 世界协调时间(UTC,即“祖鲁时”)格式,精确到纳秒,最多九个小数位。示例: |
latestStartTime |
必需。插播时间点开始时的上限(含边界值)。 时间戳采用 RFC3339 世界协调时间(UTC,即“祖鲁时”)格式,精确到纳秒,最多九个小数位。示例: |
minDuration |
必需。广告插播时长下限。必须为正值。 该时长以秒为单位,最多包含九个小数位,以“ |
FrequencyConstraint
您可以通过强制执行最短休息频率(例如“每 12 小时必须至少休息 1 小时”)来进一步约束上述休息时间的频率和时长。假设这可以解释为“在任何 12 小时的滑动时间窗口内,必须至少有一次至少 1 小时的休息时间”,那么该示例将转换为以下 FrequencyConstraint
:
{
minBreakDuration { seconds: 3600 } # 1 hour.
maxInterBreakDuration { 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
JSON 表示法 |
---|
{ "minBreakDuration": string, "maxInterBreakDuration": string } |
字段 | |
---|---|
minBreakDuration |
必需。此限制条件的最短广告插播时长。非负数。请参阅 该时长以秒为单位,最多包含九个小数位,以“ |
maxInterBreakDuration |
必需。路线中至少部分间隔 该时长以秒为单位,最多包含九个小数位,以“ |
DurationDistanceMatrix
指定从访问地点和车辆起始位置到访问地点和车辆终止位置的用时和距离矩阵。
JSON 表示法 |
---|
{
"rows": [
{
object ( |
字段 | |
---|---|
rows[] |
指定时长和距离矩阵的行。它包含的元素数量必须与 |
vehicleStartTag |
用于定义此时长和距离矩阵适用于哪些车辆的标记。如果为空,则应用于所有车辆,并且只能有一个矩阵。 每次车辆发动都必须与一个矩阵完全匹配,即它们的 所有矩阵都必须具有不同的 |
行
指定时长和距离矩阵的行。
JSON 表示法 |
---|
{ "durations": [ string ], "meters": [ number ] } |
字段 | |
---|---|
durations[] |
指定行的时长值。它包含的元素数量必须与 该时长以秒为单位,最多包含九个小数位,以“ |
meters[] |
给定行的距离值。如果模型中没有任何费用或约束条件引用距离,则可以将此值留空;否则,其元素数量必须与 |
TransitionAttributes
指定路线上两次连续访问之间的转换属性。同一转换可能适用多个 TransitionAttributes
:在这种情况下,所有额外费用都会相加,并且系统会应用最严格的约束条件或限制(遵循自然的“AND”语义)。
JSON 表示法 |
---|
{
"srcTag": string,
"excludedSrcTag": string,
"dstTag": string,
"excludedDstTag": string,
"cost": number,
"costPerKilometer": number,
"distanceLimit": {
object ( |
字段 | |
---|---|
srcTag |
用于定义这些属性所适用的 (src->dst) 转换集的标记。 当来源访问或车辆启动匹配时,仅当其 |
excludedSrcTag |
请参阅 |
dstTag |
只有当目的地到访或车辆结束的 |
excludedDstTag |
请参阅 |
cost |
指定执行此转换的费用。此值的单位与模型中的所有其他费用相同,且不得为负值。该费用在所有其他现有费用的基础上加收。 |
costPerKilometer |
指定对执行此过渡时行驶的距离应用的每公里费用。它与车辆上指定的任何 |
distanceLimit |
指定执行此过渡时行进的距离上限。 自 2021 年 6 月起,仅支持软性限额。 |
delay |
指定执行此过渡时产生的延迟。 此延迟始终发生在完成来源访问之后,并在开始目的地访问之前。 该时长以秒为单位,最多包含九个小数位,以“ |
ShipmentTypeIncompatibility
根据 shipmentType 指定不同配送信息之间的不兼容性。由于不兼容模式,同一航线上出现不兼容的运单会受到限制。
JSON 表示法 |
---|
{
"types": [
string
],
"incompatibilityMode": enum ( |
字段 | |
---|---|
types[] |
不兼容的类型列表。如果两个发货中列出的 |
incompatibilityMode |
应用于不兼容问题的模式。 |
IncompatibilityMode
定义如何在同一条航线上限制出现不相容运单的情况。
枚举 | |
---|---|
INCOMPATIBILITY_MODE_UNSPECIFIED |
未指定的不兼容模式。不应使用此值。 |
NOT_PERFORMED_BY_SAME_VEHICLE |
在此模式下,两件类型不兼容的运输服务绝不能共用同一辆车辆。 |
NOT_IN_SAME_VEHICLE_SIMULTANEOUSLY |
对于类型不兼容且
|
ShipmentTypeRequirement
根据 shippingType 指定运单之间的要求。具体要求由要求模式定义。
JSON 表示法 |
---|
{
"requiredShipmentTypeAlternatives": [
string
],
"dependentShipmentTypes": [
string
],
"requirementMode": enum ( |
字段 | |
---|---|
requiredShipmentTypeAlternatives[] |
|
dependentShipmentTypes[] |
对于 注意:不允许 |
requirementMode |
应用于相应要求的模式。 |
RequirementMode
用于定义路线上依赖性货物的外观的模式。
枚举 | |
---|---|
REQUIREMENT_MODE_UNSPECIFIED |
未指定的要求模式。不应使用此值。 |
PERFORMED_BY_SAME_VEHICLE |
在此模式下,所有“依赖性”运输必须与至少一个“必需性”运输共用同一车辆。 |
IN_SAME_VEHICLE_AT_PICKUP_TIME |
如果使用 因此,“依赖”的商品自提必须具有以下任一属性:
|
IN_SAME_VEHICLE_AT_DELIVERY_TIME |
与之前相同,但“被抚养”运送的商品在送达时需要有“必需”的运单。 |
PrecedenceRule
两个事件(每个事件都是取货或送货)之间的优先规则:第二个事件必须在“第一个”事件开始后至少 offsetDuration
开始。
多个优先级可以引用同一(或相关)事件,例如“B 的送达发生在 A 的送达之后”和“C 的送达发生在 B 的送达之后”。
此外,优先级仅在同时发货时才适用,否则会被忽略。
JSON 表示法 |
---|
{ "firstIsDelivery": boolean, "secondIsDelivery": boolean, "offsetDuration": string, "firstIndex": integer, "secondIndex": integer } |
字段 | |
---|---|
firstIsDelivery |
指明“第一个”事件是否为投放。 |
secondIsDelivery |
指示“第二个”事件是否为传送。 |
offsetDuration |
“first”和“second”事件之间的偏移。可以为负数。 该时长以秒为单位,最多包含九个小数位,以“ |
firstIndex |
“first”事件的发货索引。必须指定此字段。 |
secondIndex |
“second”事件的发货索引。必须指定此字段。 |