OptimizeToursResponse

解决旅游优化问题后的响应，其中包含每辆车行驶的路线、已跳过的货件以及解决方案的总费用。

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

object (ShipmentRoute)

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

string

OptimizeToursRequest.label 的副本（如果在请求中指定了标签）。
skippedShipments[]

object (SkippedShipment)

所有跳过的配送的列表。
validationErrors[]

object (OptimizeToursValidationError)

我们能够独立检测到的所有验证错误的列表。请参阅 OptimizeToursValidationError 消息的“MULTIPLE ERRORS”说明。如果 solvingMode 为 DEFAULT_SOLVE，则会包含警告，而不是错误。
processedRequest

object (OptimizeToursRequest)

在某些情况下，我们会先修改传入的请求（即添加费用），然后再解决问题。如果 solvingMode == TRANSFORM_AND_RETURN_REQUEST，则在此处返回修改后的请求。

实验性功能：如需了解详情，请参阅 https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request。
metrics

object (Metrics)

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

OptimizeToursValidationError

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

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

integer

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

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

多个错误：如果存在多个错误，验证过程会尝试输出其中的几个。与编译器类似，这是一个不完善的过程。某些验证错误是“致命”的，这意味着它们会停止整个验证过程。displayName="UNSPECIFIED" 错误就是其中的一个例子。某些错误可能会导致验证过程跳过其他错误。

稳定性：code 和 displayName 应该非常稳定。但随着时间的推移，可能会出现新的代码和显示名称，这可能会导致给定的（无效）请求产生不同的（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

直观易懂的字符串，用于描述错误。code 和 errorMessage 之间存在一对一的映射关系（当代码不为“UNSPECIFIED”时）。

稳定性：不稳定：与给定 code 关联的错误消息可能会随时间变化（希望是变得更清晰）。请改用 displayName 和 code。
offendingValues

string

可能包含相应字段的值。此功能并非总是可用。您绝对不应依赖它，而应仅将其用于手动模型调试。

FieldReference

指定验证错误的上下文。FieldReference 始终是指此文件中的给定字段，并遵循相同的层次结构。例如，我们可以使用以下代码指定车辆 5 的 startTimeWindows 的元素 2：

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

不过，我们会省略 OptimizeToursRequest 或 ShipmentModel 等顶级实体，以免消息过于拥挤。

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

字段的名称，例如 “车辆”。
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 的最小值。

采用 RFC 3339 标准，生成的输出将始终进行 Z 规范化（即转换为 UTC 零时区格式并在末尾附加 Z），并使用 0、3、6 或 9 个小数位。不带“Z”的偏差时间也是可以接受的。示例："2014-10-02T15:01:23Z"、"2014-10-02T15:01:23.045123456Z" 或 "2014-10-02T15:01:23+05:30"。
latestVehicleEndTime

string (Timestamp format)

二手车的最新结束时间，计算方式为所有二手车的 ShipmentRoute.vehicle_end_time 中的最大值。

采用 RFC 3339 标准，生成的输出将始终进行 Z 规范化（即转换为 UTC 零时区格式并在末尾附加 Z），并使用 0、3、6 或 9 个小数位。不带“Z”的偏差时间也是可以接受的。示例："2014-10-02T15:01:23Z"、"2014-10-02T15:01:23.045123456Z" 或 "2014-10-02T15:01:23+05:30"。
costs

map (key: string, value: number)

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

number

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