OptimizeToursResponse

解决巡回优化问题后的响应,其中包含每辆车行驶的路线、已跳过的运输以及解决方案的总费用。

JSON 表示法
{
  "routes": [
    {
      object (ShipmentRoute)
    }
  ],
  "requestLabel": string,
  "skippedShipments": [
    {
      object (SkippedShipment)
    }
  ],
  "validationErrors": [
    {
      object (OptimizeToursValidationError)
    }
  ],
  "metrics": {
    object (Metrics)
  }
}
字段
routes[]

object (ShipmentRoute)

为每辆车辆计算的路线;第 i 条路线对应于模型中的第 i 辆车辆。

requestLabel

string

OptimizeToursRequest.label 的副本(如果请求中指定了标签)。

skippedShipments[]

object (SkippedShipment)

跳过的所有运单的列表。

validationErrors[]

object (OptimizeToursValidationError)

我们能够单独检测到的所有验证错误的列表。请参阅 OptimizeToursValidationError 消息的“MULTIPLE ERRORS”说明。如果 solvingModeDEFAULT_SOLVE,则会包含警告(而非错误)。

metrics

object (Metrics)

此解决方案的时长、距离和使用情况指标。

OptimizeToursValidationError

描述验证 OptimizeToursRequest 时遇到的错误或警告。

JSON 表示法
{
  "code": integer,
  "displayName": string,
  "fields": [
    {
      object (FieldReference)
    }
  ],
  "errorMessage": string,
  "offendingValues": string
}
字段
code

integer

验证错误由始终存在的对 (code, displayName) 定义。

此部分后面的字段提供了有关错误的更多背景信息。

MULTIPLE ERRORS:如果存在多个错误,验证流程会尝试输出其中的多个错误。这是一个不完美的过程,就像编译器一样。某些验证错误会是“严重”错误,这意味着它们会停止整个验证流程。displayName="UNSPECIFIED" 错误就属于这种情况。某些错误可能会导致验证流程跳过其他错误。

稳定性codedisplayName 应非常稳定。不过,随着时间的推移,可能会出现新的代码和显示名称,这可能会导致指定(无效)的请求生成不同的 (code, displayName) 对,因为新错误会隐藏旧错误对。有关示例,请参阅“多个错误”。

displayName

string

错误的显示名称。

fields[]

object (FieldReference)

错误上下文可能涉及 0 个、1 个(大多数时候)或多个字段。例如,对于车辆 4 和运单 2 的首次取货,可以按如下方式完成:

fields { name: "vehicles" index: 4}
fields { name: "shipments" index: 2 subField {name: "pickups" index: 0} }

但请注意,对于给定的错误代码,fields 的基数不应发生变化。

errorMessage

string

用于描述错误的简单易懂的字符串。codeerrorMessage 之间存在 1 对 1 映射(如果代码 != "UNSPECIFIED")。

稳定性:不稳定:与给定 code 关联的错误消息可能会随时间推移而发生变化(希望能更清楚地说明)。请改用 displayNamecode

offendingValues

string

可能包含字段的值。此功能不一定始终可用。您绝不应依赖它,只能将其用于手动模型调试。

FieldReference

指定验证错误的上下文。FieldReference 始终引用此文件中的给定字段,并采用相同的层次结构。例如,我们可以使用以下命令指定 5 号车辆的 startTimeWindows 元素 2:

name: "vehicles" index: 5 subField { name: "endTimeWindows" index: 2 }

不过,我们会省略 OptimizeToursRequestShipmentModel 等顶级实体,以免消息过于拥挤。

JSON 表示法
{
  "name": string,
  "subField": {
    object (FieldReference)
  },

  // Union field index_or_key can be only one of the following:
  "index": integer,
  "key": string
  // End of list of possible types for union field index_or_key.
}
字段
name

string

字段的名称,例如“vehicles”

subField

object (FieldReference)

递归嵌套的子字段(如有必要)。

联合字段 index_or_key

index_or_key 只能是下列其中一项:

index

integer

字段的索引(如果重复)。

key

string

键(如果字段是映射)。

指标

所有路由的汇总指标。

JSON 表示法
{
  "aggregatedRouteMetrics": {
    object (AggregatedMetrics)
  },
  "skippedMandatoryShipmentCount": integer,
  "usedVehicleCount": integer,
  "earliestVehicleStartTime": string,
  "latestVehicleEndTime": string,
  "costs": {
    string: number,
    ...
  },
  "totalCost": number
}
字段
aggregatedRouteMetrics

object (AggregatedMetrics)

按路线汇总。每个指标都是所有同名 ShipmentRoute.metrics 字段的总和(或负载最大值)。

skippedMandatoryShipmentCount

integer

跳过的强制性运单数。

usedVehicleCount

integer

使用的车辆数量。注意:如果车辆路线为空且 Vehicle.used_if_route_is_empty 为 true,则车辆会被视为已使用。

earliestVehicleStartTime

string (Timestamp format)

二手车最早的开始时间,根据 ShipmentRoute.vehicle_start_time 的所有二手车的最短时间计算得出。

时间戳采用 RFC3339 世界协调时间(UTC,即“祖鲁时”)格式,精确到纳秒,最多九个小数位。示例:"2014-10-02T15:01:23Z""2014-10-02T15:01:23.045123456Z"

latestVehicleEndTime

string (Timestamp format)

二手车的最晚结束时间,根据 ShipmentRoute.vehicle_end_time 的所有二手车的最大值计算得出。

时间戳采用 RFC3339 世界协调时间(UTC,即“祖鲁时”)格式,精确到纳秒,最多九个小数位。示例:"2014-10-02T15:01:23Z""2014-10-02T15:01:23.045123456Z"

costs

map (key: string, value: number)

解决方案的费用,按与费用相关的请求字段细分。键是相对于输入 OptimizationToursRequest(例如“model.shipments.pickups.cost”)的 proto 路径,值是相应费用字段生成的总费用,汇总到整个解决方案中。换句话说,cost["model.shipments.pickups.cost"] 是解决方案的所有提货费用的总和。此处会详细报告模型中定义的所有费用,但与 TransitionAttributes 相关的费用除外,自 2022 年 1 月起,这些费用仅以汇总方式报告。

totalCost

number

解决方案的总费用。费用映射中所有值的总和。