解決導覽最佳化問題後,系統會回應,其中包含每輛車的路線、遭略過的貨物,以及解決方案的總費用。
| JSON 表示法 |
|---|
{ "routes": [ { object ( |
| 欄位 | |
|---|---|
routes[] |
為每輛車輛計算的路線;第 i 條路線對應至模型中的第 i 輛車輛。 |
requestLabel |
如果要求中已指定標籤,則 |
skippedShipments[] |
略過所有出貨項目的清單。 |
validationErrors[] |
我們獨立偵測到的所有驗證錯誤清單。請參閱 |
metrics |
這項解決方案的持續時間、距離和用量指標。 |
OptimizeToursValidationError
說明驗證 OptimizeToursRequest 時發生的錯誤。
| JSON 表示法 |
|---|
{
"code": integer,
"displayName": string,
"fields": [
{
object ( |
| 欄位 | |
|---|---|
code |
驗證錯誤是由一律存在的組合 ( 其他欄位 (如下方所示) 會提供更多錯誤相關資訊。 多個錯誤:如有多個錯誤,驗證程序會試著輸出數個錯誤。與編譯器類似,這個程序不完美。部分驗證錯誤屬於「嚴重」錯誤,也就是說,這類錯誤會停止整個驗證程序。以上就是 STability: 參考資料:所有 (代碼、名稱) 組合的清單:
|
displayName |
錯誤顯示名稱。 |
fields[] |
錯誤內容可能包含 0、1 (大多數時間) 或多個欄位。舉例來說,參照第 4 號車輛和第 2 批第 2 項取貨方式可按照以下方式完成: 不過,請注意, |
errorMessage |
使用者容易理解的錯誤說明字串。 STABILITY:不穩定:與指定 |
offendingValues |
可能包含欄位的值。您不一定每次都能使用這個代碼。請務必不要依賴這項功能,並且只用於手動模型偵錯。 |
FieldReference
指定驗證錯誤的內容。FieldReference 一律會參照這個檔案中的特定欄位,並採用相同的階層結構。舉例來說,您可以透過以下程式碼,指定車輛 #5 的 startTimeWindows 元素 #2:
name: "vehicles" index: 5 subField { name: "endTimeWindows" index: 2 }
不過,我們會省略 OptimizeToursRequest 或 ShipmentModel 等頂層實體,以免訊息過於擁擠。
| JSON 表示法 |
|---|
{ "name": string, "subField": { object ( |
| 欄位 | |
|---|---|
name |
欄位名稱,例如「車輛」。 |
subField |
視需要以遞迴方式建立子欄位。 |
聯集欄位
|
|
index |
欄位的索引 (如果重複)。 |
key |
若欄位為對應項,則為索引鍵。 |
指標
匯總所有路徑的整體指標。
| JSON 表示法 |
|---|
{
"aggregatedRouteMetrics": {
object ( |
| 欄位 | |
|---|---|
aggregatedRouteMetrics |
按照路徑匯總。每個指標都是所有同名 |
skippedMandatoryShipmentCount |
略過的必要出貨數量。 |
usedVehicleCount |
使用的車輛數量。注意:如果車輛路線為空白,且 |
earliestVehicleStartTime |
二手車最早的開始時間,計算方式為 RFC3339 世界標準時間「Zulu」格式的時間戳記,解析度以奈秒為單位,小數點後最多 9 位。範例: |
latestVehicleEndTime |
二手車的最新結束時間,計算方式為 RFC3339 世界標準時間「Zulu」格式的時間戳記,精確度達奈秒單位,最多九個小數位數。範例: |
costs |
解決方案的費用,依費用相關要求欄位細分。索引鍵是 proto 路徑 (相對於輸入的 OptimizeToursRequest,例如「model.shipments.pickups.cost」),而值則是對應費用欄位產生且匯總整個解決方案的總費用。換句話說,成本 ["model.shipments.pickups.cost"] 是解決方案中所有取貨費用的總和。這裡會詳細列出模型中定義的所有費用,但 TransitionAttributes 相關費用除外,因為這類費用自 2022 年 1 月起只會以匯總方式呈報。 這個物件中包含 |
totalCost |
解決方案的總費用。成本對應項目中的所有值總和。 |