解决游览优化问题后给出的响应,其中包括每辆车所走的路线、跳过的运单以及解决方案的总体成本。
JSON 表示法 |
---|
{ "routes": [ { object ( |
字段 | |
---|---|
routes[] |
为每辆车计算的路线;第 i-th 号路线对应于模型中的第 i 号交通工具。 |
requestLabel |
|
skippedShipments[] |
跳过的所有运单的列表。 |
validationErrors[] |
我们能够单独检测到的所有验证错误的列表。请参阅“多个错误” |
metrics |
此解决方案的时长、距离和用量指标。 |
OptimizeToursValidationError
描述验证 OptimizeToursRequest
时遇到的错误或警告。
JSON 表示法 |
---|
{
"code": integer,
"displayName": string,
"fields": [
{
object ( |
字段 | |
---|---|
code |
验证错误由始终存在的对 ( 其他字段(见下文)提供了有关此错误的更多背景信息。 多个错误:如果存在多个错误,验证流程会尝试输出其中多个错误。这是一个不完美的过程,就像编译器一样。有些验证错误是“严重”错误,也就是说,它们会停止整个验证流程。 STABILITY: REFERENCE:所有 (code, name) 对的列表:
|
displayName |
错误的显示名称。 |
fields[] |
错误上下文可能涉及 0 个、1 个(大多数时候)或多个字段。例如,对于车辆 4 和运单 2 的首次取货,可以按如下方式完成:
但请注意,对于给定的错误代码, |
errorMessage |
用于描述错误的简单易懂的字符串。 稳定性:不稳定:与给定 |
offendingValues |
可以包含字段的值。此功能不一定始终可用。您绝对不能依赖它,而只能将其用于手动模型调试。 |
FieldReference
指定验证错误的上下文。FieldReference
始终引用此文件中的给定字段,并采用相同的层次结构。例如,我们可以使用以下命令指定 5 号车辆的 startTimeWindows
元素 2:
name: "vehicles" index: 5 subField { name: "endTimeWindows" index: 2 }
不过,我们会省略 OptimizeToursRequest
或 ShipmentModel
等顶级实体,以避免造成消息拥挤。
JSON 表示法 |
---|
{ "name": string, "subField": { object ( |
字段 | |
---|---|
name |
字段的名称,例如“vehicles” |
subField |
以递归方式嵌套子字段(如果需要)。 |
联合字段
|
|
index |
字段的索引(如果重复)。 |
key |
键(如果字段是映射)。 |
指标
所有路由的汇总指标。
JSON 表示法 |
---|
{
"aggregatedRouteMetrics": {
object ( |
字段 | |
---|---|
aggregatedRouteMetrics |
通过路由进行汇总。每个指标都是所有同名 |
skippedMandatoryShipmentCount |
跳过的强制性运单数。 |
usedVehicleCount |
使用的车辆数量。注意:如果车辆路线为空且 |
earliestVehicleStartTime |
二手车最早的开始时间,根据 时间戳采用 RFC3339 世界协调时间(UTC,即“祖鲁时”)格式,精确到纳秒,最多九个小数位。示例: |
latestVehicleEndTime |
二手车最晚结束时间,根据 时间戳采用 RFC3339 世界协调时间(UTC,即“祖鲁时”)格式,精确到纳秒,最多九个小数位。示例: |
costs |
解决方案费用,按与费用相关的请求字段细分。键是相对于输入 OptimizationToursRequest 的 proto 路径,例如:"model.shipments.pickups.cost",这些值是相应费用字段生成的总费用,汇总到整个解决方案中。换句话说,cost["model.shipments.pickups.cost"] 是解决方案的所有提货费用的总和。模型中定义的所有费用均在此处详细报告,但与 TransitionAttributes 相关的费用自 2022 年 1 月起仅以汇总方式报告。 包含一系列 |
totalCost |
解决方案的总费用。费用映射中所有值的总和。 |