解決導覽最佳化問題後,系統會回應,其中包含每輛車的路線、遭略過的貨物,以及解決方案的總費用。
JSON 表示法 |
---|
{ "routes": [ { object ( |
欄位 | |
---|---|
routes[] |
針對每輛車計算的路線第 2 條路線與型號中的第 i 個車輛對應。 |
requestLabel |
如果要求中已指定標籤,則 |
skippedShipments[] |
略過所有出貨項目的清單。 |
validationErrors[] |
列出可獨立偵測的所有驗證錯誤。查看「多個錯誤」 |
metrics |
這項解決方案的持續時間、距離和用量指標。 |
OptimizeToursValidationError
說明驗證 OptimizeToursRequest
時出現的錯誤或警告。
JSON 表示法 |
---|
{
"code": integer,
"displayName": string,
"fields": [
{
object ( |
欄位 | |
---|---|
code |
驗證錯誤是由一律存在的組合 ( 其他欄位 (請見下方) 提供更多與錯誤相關的資訊。 多個錯誤:如有多個錯誤,驗證程序會試著輸出數個錯誤。與編譯器類似,這個程序不完美。部分驗證錯誤屬於「嚴重」錯誤,也就是說,這類錯誤會停止整個驗證程序。以上就是 STability: REFERENCE:所有 (代碼、名稱) 組合的清單:
|
displayName |
錯誤顯示名稱。 |
fields[] |
錯誤內容可能包含 0、1 (大多數時間) 或多個欄位。舉例來說,參照第 4 號車輛和第 2 批第 2 項取貨方式可按照以下方式完成:
不過請注意,特定錯誤代碼不會變更 |
errorMessage |
使用者容易理解的錯誤說明字串。 STABILITY:不穩定:與指定 |
offendingValues |
可能包含欄位值。您不一定每次都能使用這個代碼。因此,建議您不要仰賴此演算法,並僅用於手動模型偵錯。 |
欄位參照
指定驗證錯誤的內容。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」的時間戳記格式,解析度不超過奈秒,最多 9 個小數位數。範例: |
costs |
解決方案的費用,按費用相關要求欄位細分。這些鍵是 proto 路徑,相對於輸入的 OptimizeToursRequest,例如:「model.shipments.pickups.cost」和「模型」的值則為對應費用欄位產生的總費用,並匯總為整個解決方案。換句話說,成本 ["model.shipments.pickups.cost"] 是解決方案中所有取貨費用的總和。這裡詳細列出模型中定義的所有費用,但 TransitionAttributes 的相關費用除外。這些費用只以 2022 年 1 月的匯總方式呈現。 這個物件中包含 |
totalCost |
解決方案的總費用。費用對應中所有值的總和。 |