- JSON 表示法
- 发货
- VisitRequest
- LatLng
- 航点
- 位置
- TimeWindow
- 车辆
- TravelMode
- UnloadingPolicy
- LoadLimit
- 间隔时间
- DurationLimitDurationLimit
- DistanceLimit
- BreakRule
- BreakRequest
- FrequencyConstraint
- DurationDistanceMatrix
- 行
- TransitionAttributes
- ShipmentTypeIncompatibility
- IncompatibilityMode
- ShipmentTypeRequirement
- RequirementMode
- PrecedenceRule
一个运单模式包含一组必须由一组车辆执行运单,同时最大限度地降低总体成本,即:
- 车辆路线规划费用(所有车辆的总时间费用、行驶时间费用和固定费用之和)。
- 不履行的发货惩罚。
- 运输全程的费用
| JSON 表示法 | 
|---|
| { "shipments": [ { object ( | 
| 字段 | |
|---|---|
| shipments[] | 
 必须在模型中执行的一组配送。 | 
| vehicles[] | 
 可用于执行访问的一组车辆。 | 
| globalStartTime | 
 模型的全局开始时间和结束时间:此范围以外的时间都不能视为有效时间。 模型的时间跨度不得超过 1 年,即  使用  时间戳采用 RFC3339 世界协调时间(UTC,即“祖鲁时”)格式,精确到纳秒,最多九个小数位。示例: | 
| globalEndTime | 
 如果未设置,系统会默认使用 1971 年 1 月 1 日 00:00:00 UTC(即秒数:31536000,纳秒数:0)。 时间戳采用 RFC3339 世界协调时间(UTC,即“祖鲁时”)格式,精确到纳秒,最多九个小数位。示例: | 
| globalDurationCostPerHour | 
 整个方案的“全局时长”是指所有车辆的最早有效开始时间和最晚有效结束时间之间的差值。例如,用户可以为该数量分配每小时费用,以便尽可能优化作业完成时间。此费用必须与 | 
| durationDistanceMatrices[] | 
 指定模型中使用的时长和距离矩阵。如果此字段为空,系统将改用 Google 地图或大地距离,具体取决于  用法示例: 
 
  | 
| 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 月起,只有在行程时长不依赖于车辆时,才支持绕道。 该时长以秒为单位,最多包含九个小数位,以“ | 
| pickupToDeliveryTimeLimit | 
 指定从开始自提到开始配送的最长时长。如果指定,则必须为非负数,并且运单中必须至少包含自提和送货信息。这既不取决于为自提和配送选择的替代选项,也不取决于车辆速度。这可以与最大绕行约束条件一起指定:解决方案将同时遵循这两种规范。 该时长以秒为单位,最多包含九个小数位,以“ | 
| shipmentType | 
 非空字符串,用于指定此运单的“类型”。此功能可用于定义  与仅针对单次访问指定的  | 
| label | 
 指定此运单的标签。此标签会在响应的相应  | 
| ignore | 
 如果为 true,则跳过此配送,但不应用  如果模型中存在任何  允许忽略在  | 
| penaltyCost | 
 如果未能完成配送,此处罚金将计入路线的总费用。如果使用了某个自提和配送备选方式,则视为配送已完成。费用可以采用与模型中所有其他与费用相关的字段相同的单位表示,并且必须为正数。 重要提示:如果未指定此处罚,则视为无限期,即必须完成发货。 | 
| pickupToDeliveryRelativeDetourLimit | 
 指定与从上车点到下车点的最短路径相比,绕路的最大相对时间。如果指定,则必须为非负数,并且运单中必须至少包含自提和送货信息。 例如,设为从所选的自提备选方案直接到所选的备选配送方式所需的最短时间。然后,设置  如果同一运输中同时指定了相对上限和绝对上限,则系统会对每个可能的取件/送货对使用更严格的上限。从 2017 年 10 月 10 日开始,仅当行程时长不取决于车辆时才支持绕行。 | 
VisitRequest
请求由车辆完成的访问:它具有一个(或两个,见下文)地理位置、由时间范围表示的开业和打烊时间,以及服务时长(车辆到达取件或送货地点后所花的时间)。
| JSON 表示法 | 
|---|
| { "arrivalLocation": { object ( | 
| 字段 | |
|---|---|
| arrivalLocation | 
 执行此  | 
| arrivalWaypoint | 
 车辆执行此  | 
| departureLocation | 
 车辆完成此  | 
| departureWaypoint | 
 完成此  | 
| tags[] | 
 指定附加到访问请求的标记。不允许使用空字符串或重复字符串。 | 
| timeWindows[] | 
 用于约束到达时间的访问时间窗口。请注意,车辆可能会在到达时间窗口之外离开,即到达时间 + 持续时间无需在时间窗口内。如果车辆在  如果缺少  时间窗口必须互不重叠,即任何时间窗口都不能与其他时间窗口重叠或相邻,并且必须按升序排列。 只有在只有一个时间窗口时,才能设置  | 
| duration | 
 访问时长,即车辆从到达到离开所用的时间(应与可能的等待时间相加;请参阅  该时长以秒为单位,最多包含九个小数位,以“ | 
| cost | 
 在车辆路线上处理此访问请求的费用。此属性可用于为不同的商品自提或配送选项支付不同的费用。此费用的单位必须与“ | 
| loadDemands | 
 此访问请求的加载需求。这类似于  包含一系列  | 
| visitTypes[] | 
 指定访问类型。系统可能会据此分配车辆完成此次访问所需的额外时间(请参阅 一种类型只能出现一次。 | 
| label | 
 为此  | 
| avoidUTurns | 
 指定在此位置的行驶路线中是否应避免掉头。系统会尽最大努力避免调头,无法保证完全避开。这是一项实验性功能,具体行为可能会发生变化。 | 
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 | 
 会影响车辆可使用的道路及其速度的出行方式。另请参阅  | 
| startLocation | 
 车辆在接收任何运输件之前的起始地理位置。如果未指定,则车辆从首次上车开始计算。如果运单模型具有时长和距离矩阵,则不得指定  | 
| startWaypoint | 
 表示车辆在接收任何运输件之前的起始地理位置的航点。如果未指定  | 
| endLocation | 
 车辆完成最后一次  | 
| endWaypoint | 
 路点,表示车辆完成最后一次  | 
| startTags[] | 
 指定附加到车辆路线起点的标记。 不允许使用空字符串或重复字符串。 | 
| endTags[] | 
 指定附加到车辆路线末尾的标记。 不允许使用空字符串或重复字符串。 | 
| startTimeWindows[] | 
 车辆可以从起始位置出发的时间范围。它们必须在全球时限范围内(请参阅  属于同一重复字段的时间窗口必须是不相交的,即任何时间窗口都不能与其他时间窗口重叠或相邻,并且必须按时间顺序排列。 只有在只有一个时间窗口时,才能设置  | 
| endTimeWindows[] | 
 车辆可到达终点位置的时间范围。它们必须在全局时间限制内(请参阅  属于同一重复字段的时间窗口必须是不相交的,即任何时间窗口都不能与其他时间窗口重叠或相邻,并且必须按时间顺序排列。 只有在只有一个时间窗口时,才能设置  | 
| unloadingPolicy | 
 已在车辆上强制执行卸载政策。 | 
| loadLimits | 
 车辆容量(例如重量、体积、托盘数)。映射中的键是加载类型的标识符,与  包含一系列  | 
| costPerHour | 
 车辆费用:所有费用相加,且必须与  车辆路线的每小时费用。该费用适用于相应路线的总时间,包括行程时间、等候时间和到访时间。使用  | 
| costPerTraveledHour | 
 车辆行驶路线每小时的费用。此费用仅适用于相应路线所用行程时间(即在  | 
| costPerKilometer | 
 车辆行驶的每公里费用。此开销适用于  | 
| fixedCost | 
 如果此车辆用于处理运输,则应用的固定费用。 | 
| usedIfRouteIsEmpty | 
 此字段仅适用于其路线未配送任何运输的车辆。用于指明在这种情况下是否应将车辆视为二手。 如果为 true,则即使车辆不提供任何运送服务,也会从起点到终点位置持续行驶,并且需要考虑从起点到终点行程产生的时间和距离成本。 否则,车辆不会从起始位置前往终点位置,并且系统不会为此车辆安排  | 
| routeDurationLimit | 
 适用于车辆路线总时长的限制。在给定  | 
| travelDurationLimit | 
 应用于车辆路线行程时长的限制。在给定  | 
| routeDistanceLimit | 
 适用于车辆行程总里程的限制。在给定的  | 
| extraVisitDurationForVisitType | 
 指定从访问类型字符串到持续时间的映射。时长是指在指定了  如果访问请求具有多种类型,系统会在映射中为每种类型添加时长。 包含一系列  | 
| 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 | 与步行路线对应的出行方式。 | 
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 | 
 可接受的最大负载量。 | 
间隔
可接受的加载量的间隔。
| JSON 表示法 | 
|---|
| { "min": string, "max": string } | 
| 字段 | |
|---|---|
| min | 
 | 
| max | 
 可接受的最大负载。必须大于等于 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, "costPerKilometerAboveSoftMax": number } | 
| 字段 | |
|---|---|
| maxMeters | 
 将距离限制为不超过 maxMeters 的硬性限制。上限必须是非负数。 | 
| softMaxMeters | 
 不强制执行最大距离限制的软性限制,但如果违反,则产生的费用将与模型中定义的其他费用相加,且单位相同。 如果定义的 softMaxMeters 必须小于 maxMeters,则必须为非负数。 | 
| 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
根据搬运类型指定运单之间的不兼容情况。系统会根据不兼容模式限制同一路线上不兼容的配送信息的显示方式。
| JSON 表示法 | 
|---|
| {
  "types": [
    string
  ],
  "incompatibilityMode": enum ( | 
| 字段 | |
|---|---|
| types[] | 
 不兼容的类型列表。列出的  | 
| incompatibilityMode | 
 应用于不兼容问题的模式。 | 
IncompatibilityMode
定义如何在同一条航线上限制出现不相容运单的情况。
| 枚举 | |
|---|---|
| INCOMPATIBILITY_MODE_UNSPECIFIED | 未指定的不兼容模式。不应使用此值。 | 
| NOT_PERFORMED_BY_SAME_VEHICLE | 在此模式下,类型不兼容的两件货品绝不能共用同一辆车。 | 
| NOT_IN_SAME_VEHICLE_SIMULTANEOUSLY | 对于类型不兼容且 
 | 
ShipmentTypeRequirement
根据 shipmentType 指定不同配送之间的要求。具体要求由要求模式定义。
| 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 | 
 “第二个”事件的配送编号。必须指定此字段。 |