索引
RouteOptimization
(介面)AggregatedMetrics
(訊息)BatchOptimizeToursMetadata
(訊息)BatchOptimizeToursRequest
(訊息)BatchOptimizeToursRequest.AsyncModelConfig
(訊息)BatchOptimizeToursResponse
(訊息)BreakRule
(訊息)BreakRule.BreakRequest
(訊息)BreakRule.FrequencyConstraint
(訊息)DataFormat
(列舉)DistanceLimit
(訊息)GcsDestination
(訊息)GcsSource
(訊息)InjectedSolutionConstraint
(訊息)InjectedSolutionConstraint.ConstraintRelaxation
(訊息)InjectedSolutionConstraint.ConstraintRelaxation.Relaxation
(訊息)InjectedSolutionConstraint.ConstraintRelaxation.Relaxation.Level
(列舉)InputConfig
(訊息)Location
(訊息)OptimizeToursRequest
(訊息)OptimizeToursRequest.SearchMode
(列舉)OptimizeToursRequest.SolvingMode
(列舉)OptimizeToursResponse
(訊息)OptimizeToursResponse.Metrics
(訊息)OptimizeToursValidationError
(訊息)OptimizeToursValidationError.FieldReference
(訊息)OutputConfig
(訊息)Shipment
(訊息)Shipment.Load
(訊息)Shipment.VisitRequest
(訊息)ShipmentModel
(訊息)ShipmentModel.DurationDistanceMatrix
(訊息)ShipmentModel.DurationDistanceMatrix.Row
(訊息)ShipmentModel.PrecedenceRule
(訊息)ShipmentRoute
(訊息)ShipmentRoute.Break
(訊息)ShipmentRoute.EncodedPolyline
(訊息)ShipmentRoute.Transition
(訊息)ShipmentRoute.VehicleLoad
(訊息)ShipmentRoute.Visit
(訊息)ShipmentTypeIncompatibility
(訊息)ShipmentTypeIncompatibility.IncompatibilityMode
(列舉)ShipmentTypeRequirement
(訊息)ShipmentTypeRequirement.RequirementMode
(列舉)SkippedShipment
(訊息)SkippedShipment.Reason
(訊息)SkippedShipment.Reason.Code
(列舉)TimeWindow
(訊息)TransitionAttributes
(訊息)Vehicle
(訊息)Vehicle.DurationLimit
(訊息)Vehicle.LoadLimit
(訊息)Vehicle.LoadLimit.Interval
(訊息)Vehicle.TravelMode
(列舉)Vehicle.UnloadingPolicy
(列舉)Waypoint
(訊息)
RouteOptimization
用於最佳化車輛行程的服務。
特定類型欄位的有效性:
google.protobuf.Timestamp
- 時間是以 Unix 時間為準:從 1970-01-01T00:00:00+00:00 開始的秒數。
- 秒數必須是 [0, 253402300799],亦即位於 [1970-01-01T00:00:00+00:00, 9999-12-31T23:59:59+00:00]。
- 必須設定 nanos 或將其設為 0。
google.protobuf.Duration
- 秒數必須是 [0, 253402300799],亦即位於 [1970-01-01T00:00:00+00:00, 9999-12-31T23:59:59+00:00]。
- 必須設定 nanos 或將其設為 0。
google.type.LatLng
- 緯度必須是 [-90.0, 90.0]。
- 經度必須介於 [-180.0, 180.0] 之間。
- 經度和緯度必須至少為一個為非零。
BatchOptimizeTours |
---|
以批次的形式,將一或多則 此方法為長時間執行的作業 (LRO)。最佳化輸入內容 (
|
OptimizeTours |
---|
傳送包含
我們的目標是提供
|
AggregatedMetrics
ShipmentRoute
的匯總指標,(針對所有 Transition
和/或 Visit
(所有 ShipmentRoute
) 元素的 OptimizeToursResponse
的匯總指標。
欄位 | |
---|---|
performed_shipment_count |
執行的出貨數量。請注意,取貨和運送組合只會計算一次。 |
travel_duration |
路線或解決方案的總交通時間。 |
wait_duration |
路線或解決方案的總等待時間。 |
delay_duration |
路線或解決方案的總延遲時間。 |
break_duration |
路線或解決方案的總中斷時間。 |
visit_duration |
路線或解決方案的總造訪時間長度。 |
total_duration |
總時間長度應等於以上所有時間長度的總和。至於路線,它也會對應:
|
travel_distance_meters |
路線或解決方案的總移動距離。 |
max_loads |
整個路線 (復原解決方案) 中各路線的負載量上限,計算依據為所有 |
BatchOptimizeToursMetadata
這個類型沒有任何欄位。
BatchOptimizeToursRequest
呼叫的作業中繼資料。
BatchOptimizeToursRequest
以非同步作業的形式要求批次最佳化導覽。每個輸入檔案應包含一個 OptimizeToursRequest
,而每個輸出檔案都包含一個 OptimizeToursResponse
。要求中包含讀取/寫入及剖析檔案的資訊。所有輸入和輸出檔案都應位於同一個專案下。
欄位 | |
---|---|
parent |
必要欄位。目標專案和位置即可進行通話。 格式:* 如未指定位置,系統會自動選擇區域。 |
model_configs[] |
必要欄位。各購買模型的輸入/輸出資訊,例如檔案路徑和資料格式。 |
AsyncModelConfig
以非同步方式解決一個最佳化模型的相關資訊。
欄位 | |
---|---|
display_name |
選用設定。使用者定義的模型名稱可以做為別名,供使用者追蹤模型。 |
input_config |
必要欄位。輸入模型的相關資訊。 |
output_config |
必要欄位。所需的輸出位置資訊。 |
BatchOptimizeToursResponse
這個類型沒有任何欄位。
對 BatchOptimizeToursRequest
的回應。這項作業會在作業完成後於長時間執行的作業中傳回。
BreakRule
產生車輛休息時間 (例如午休時間) 的規則。「休息時間」是指車輛在目前位置保持閒置狀態且無法進行任何造訪的連續時間範圍。可能會發生下列狀況:
- 在兩次造訪間來回移動的期間 (包括造訪前後的等待時間,但不在造訪中途),此時,您便可延長訪客兩次造訪之間的相應運送時間。
- 或車輛開始之前 (車輛不得在休息中開始),這樣就不會影響車輛的開始時間。
- 或車輛結束後 (Ditto,車輛結束時間)。
欄位 | |
---|---|
break_requests[] |
廣告插播的順序。請參閱 |
frequency_constraints[] |
可能會套用多種 |
BreakRequest
您必須事先得知適用於每輛車的休息時間順序 (例如編號和順序)。重複的 BreakRequest
會按照建立順序定義這個序列。他們的時間範圍 (earliest_start_time
/ latest_start_time
) 可能會重疊,但必須與訂單相容 (已勾選)。
欄位 | |
---|---|
earliest_start_time |
必要欄位。休息時間的下限 (含)。 |
latest_start_time |
必要欄位。廣告插播的開頭上限 (含)。 |
min_duration |
必要欄位。廣告插播的時間長度下限。必須為正數。 |
FrequencyConstraint
您可以強制執行最短廣告插播頻率,藉此進一步限制上述廣告插播的頻率和時間長度,例如「每 12 小時必須休息至少 1 小時」。假設這個結果可以解讀為「在 12 小時的任何滑動時間範圍內,至少要有一個間隔至少一小時」,則範例會轉譯為下列 FrequencyConstraint
:
{
min_break_duration { seconds: 3600 } # 1 hour.
max_inter_break_duration { seconds: 39600 } # 11 hours (12 - 1 = 11).
}
除了已在 BreakRequest
中指定的時間範圍和最短持續時間,解決方案中的廣告插播時間點與時間長度會尊重所有這類限制。
FrequencyConstraint
在實務上可能會適用於非連續的廣告插播。例如,下列排程會遵循「每 12 小時 1 小時」的範例:
04:00 vehicle start
.. performing travel and visits ..
09:00 1 hour break
10:00 end of the break
.. performing travel and visits ..
12:00 20-min lunch break
12:20 end of the break
.. performing travel and visits ..
21:00 1 hour break
22:00 end of the break
.. performing travel and visits ..
23:59 vehicle end
欄位 | |
---|---|
min_break_duration |
必要欄位。這項限制的最短廣告插播時間長度。非負數。請參閱 |
max_inter_break_duration |
必要欄位。路線中任何時間間隔的最長間隔時間 (不包含至少一部分的 |
DataFormat
輸入和輸出檔案的資料格式。
列舉 | |
---|---|
DATA_FORMAT_UNSPECIFIED |
輸入的值無效,格式不得為 UNSPECIFIED。 |
JSON |
JavaScript 物件標記法。 |
PROTO_TEXT |
通訊協定緩衝區文字格式。詳情請參閱 https://protobuf.dev/reference/protobuf/textformat-spec/ |
DistanceLimit
用於定義可以行駛的距離上限。包括硬性或軟性問題。
如果定義了軟性限制,則 soft_max_meters
和 cost_per_kilometer_above_soft_max
都必須定義,且不得為負數。
欄位 | |
---|---|
max_meters |
嚴格限制會將距離限制在 max_meters 以內。限制不得為負數。 |
soft_max_meters |
非強制性的距離上限不會強制執行距離上限,但當用量超出上限時,其費用會加計到模型中定義的其他費用,也就是相同的單位。 如果已定義的 soft_max_meters 必須小於 max_meters,且不得為負數。 |
cost_per_kilometer_above_soft_max |
如果距離超過
費用不得為負數。 |
GcsDestination
要寫入輸出檔案的 Google Cloud Storage 位置。
欄位 | |
---|---|
uri |
必要欄位。Google Cloud Storage URI。 |
GcsSource
用於讀取輸入檔案的 Google Cloud Storage 位置。
欄位 | |
---|---|
uri |
必要欄位。Google Cloud Storage 物件的 URI,格式為 |
InjectedSolutionConstraint
在要求中插入的解決方案,包括要限製造訪類型的相關資訊,以及必須限制的造訪方式。
欄位 | |
---|---|
routes[] |
要插入的解決方案路徑。原始解決方案可能會省略部分路線。路線和略過的運送方式必須符合 |
skipped_shipments[] |
已略過要插入的解決方案運送。有些可能會從原始解決方案中排除。請參閱 |
constraint_relaxations[] |
如果是零或多個車輛群組,請指定限制條件放寬限制條件的時間和程度。如果這個欄位空白,所有非空白的車輛路線都會完全受限。 |
ConstraintRelaxation
如果是車輛群組,請指定造訪限制的門檻和等級。skipped_shipment
欄位中列出的出貨作業僅限略過,因此無法進行。
欄位 | |
---|---|
relaxations[] |
所有造訪限制放寬條件,會套用至 |
vehicle_indices[] |
指定造訪限制 如果 |
休閒場所
如果 relaxations
為空白,routes
上所有造訪的開始時間和順序都完全受限,因此無法插入或新增這些路線的新造訪記錄。此外,routes
中的車輛開始和結束時間完全受限,除非車輛沒有空 (也就是說,沒有行駛,且模型中的 used_if_route_is_empty
會設為 false)。
relaxations(i).level
會指定對符合 #j 的造訪要求套用的限制放寬等級:
route.visits(j).start_time >= relaxations(i).threshold_time
和j + 1 >= relaxations(i).threshold_visit_count
同樣地,如果車輛符合下列條件,啟動狀態會放寬為 relaxations(i).level
:
vehicle_start_time >= relaxations(i).threshold_time
和- 如果「
relaxations(i).threshold_visit_count == 0
」和車輛裝置符合下列要求,就會放寬為relaxations(i).level
: vehicle_end_time >= relaxations(i).threshold_time
和route.visits_size() + 1 >= relaxations(i).threshold_visit_count
在造訪符合 threshold_visit_count
時套用放鬆等級,或 threshold_time
新增兩個具有相同 level
的 relaxations
:一個僅設定 threshold_visit_count
,另一個則僅設定 threshold_time
。如果造訪符合多個 relaxations
的條件,就會套用最寬鬆的層級。因此,從車輛開始行駛路線到車輛結束,放鬆程度就會變得越來越放鬆:也就是說,隨著路線的進行,放鬆程度保持不變。
不符合任何 relaxations
的門檻條件時,路線造訪的時間和順序完全受限,且任何造訪記錄都不會插入這些序列。此外,如果車輛的起點或終點不符合任何放鬆的條件,除非車輛沒有空,否則我們會修正時間。
欄位 | |
---|---|
level |
符合 |
threshold_time |
可以套用放鬆 |
threshold_visit_count |
可以套用放鬆 如果為 |
等級
表示不同的限制放寬等級,適用於造訪和符合門檻條件的情況。
以下列舉是為了提昇放鬆程度。
列舉 | |
---|---|
LEVEL_UNSPECIFIED |
隱含預設的放鬆層級:沒有限制會寬鬆,也就是所有造訪都完全受到限制。 不得在 |
RELAX_VISIT_TIMES_AFTER_THRESHOLD |
造訪開始時間和車輛的開始/結束時間會放寬,但每次造訪仍繫結至同一輛車,且務必觀察造訪順序:造訪之間或前後無法插入任何造訪。 |
RELAX_VISIT_TIMES_AND_SEQUENCE_AFTER_THRESHOLD |
與 RELAX_VISIT_TIMES_AFTER_THRESHOLD 相同,但造訪順序也很寬鬆:造訪仍然只受限於其車輛。 |
RELAX_ALL_AFTER_THRESHOLD |
與 RELAX_VISIT_TIMES_AND_SEQUENCE_AFTER_THRESHOLD 相同,但車輛也相當放鬆:在達到閾值時間上限或之後,乘客可能就無法充電,而且有可能無法提升效能。 |
InputConfig
指定 [BatchOptimizeTours][google.maps.routeoptimization.v1.RouteOptimizationService.BatchOptimizeTours] 的輸入內容。
欄位 | |
---|---|
data_format |
必要欄位。輸入資料格式。 |
聯集欄位 source 。必要欄位。source 只能是下列其中一項: |
|
gcs_source |
Google Cloud Storage 位置。這必須是單一物件 (檔案)。 |
位置
封裝位置 (地理位置點和選用標題)。
欄位 | |
---|---|
lat_lng |
路線控點的地理座標。 |
heading |
與車流方向相關的指南針標題。這個值用於指定要用於上車和下車的道路側邊。方向值可以介於 0 到 360 之間,其中 0 可指定朝北方的方向,90 則指定截止朝向的方向等等。 |
OptimizeToursRequest
要求傳送給導覽最佳化解題工具,該解析器定義要解決的運送模型以及最佳化參數。
欄位 | |
---|---|
parent |
必要欄位。目標專案或位置即可進行通話。 格式:* 如未指定位置,系統會自動選擇區域。 |
timeout |
如果設定了逾時,伺服器會在逾時期限前或伺服器達到同步要求的期限時傳回回應 (以較早者為準)。 對於非同步要求,伺服器會在逾時逾時前產生解決方案 (如果可行)。 |
model |
要解決的運送模型。 |
solving_mode |
根據預設,解題模式為 |
search_mode |
用於解決要求的搜尋模式。 |
injected_first_solution_routes[] |
引導最佳化演算法,找出與先前解決方案相似的第一個解決方案。 建立第一個解決方案時,模型會受到限制。在第一個解決方案中,系統會自動略過未在路線上做出的任何運輸,但可以透過連續的解決方案進行。 解決方案必須滿足一些基本的有效性假設:
如果插入的解決方案無法運作,系統不一定會傳回驗證錯誤,且可能會改為傳回不可行的錯誤。 |
injected_solution_constraint |
限制最佳化演算法,找出與先前解決方案類似的最終解決方案。舉例來說,這個引數可用來凍結部分已完成或即將完成但不能修改的路線。 如果插入的解決方案無法運作,系統不一定會傳回驗證錯誤,且可能會改為傳回不可行的錯誤。 |
refresh_details_routes[] |
如果不是空白,指定路線就會重新整理,而不會修改其基礎的造訪順序或交通時間:僅會更新其他詳細資訊。這無法解決模型的問題。 自 2020 年 11 月起,這項操作只會填入非空白路線的折線,而且需要 傳入路徑的 這個欄位不得與
|
interpret_injected_solutions_using_labels |
如為 true:
此解釋適用於 如果設為「是」,以下類別的標籤最多只能出現一次:
如果插入解決方案中的 從插入的解決方案中移除路線造訪記錄或整個路徑可能會對隱含的限制產生影響,進而導致解決方案改變、驗證錯誤或無法發揮作用。 注意:呼叫端必須確保每個 |
consider_road_traffic |
計算 |
populate_polylines |
如果為 true,回應 |
populate_transition_polylines |
如果為 true,則回應 |
allow_large_deadline_despite_interruption_risk |
如果設定了這個值,該要求便會有最多 60 分鐘的期限 (請參閱 https://grpc.io/blog/deadlines)。否則,期限最長只有 30 分鐘。請注意,長期要求會大幅提高 (但仍然很少) 中斷風險。 |
use_geodesic_distances |
如果為 true,系統會使用測地距離 (而非 Google 地圖距離) 計算移動距離,並使用測地線距離 (由 |
label |
可用來識別這項要求的標籤,並回報至 |
geodesic_meters_per_second |
如果 |
max_validation_errors |
縮短傳回的驗證錯誤數量。除非 solving_mode=VALIDATE_ONLY:查看 |
SearchMode
定義搜尋行為、解決延遲時間與解決方案品質的模式。在所有模式下,全域要求期限都會強制執行。
列舉 | |
---|---|
SEARCH_MODE_UNSPECIFIED |
未指定的搜尋模式,相當於 RETURN_FAST 。 |
RETURN_FAST |
找到第一個最佳解決方案後,停止搜尋。 |
CONSUME_ALL_AVAILABLE_TIME |
投注所有可用時間,尋找更優質的解決方案。 |
SolvingMode
定義解題工具應如何處理要求。在 VALIDATE_ONLY
以外的所有模式中,如果要求無效,您就會收到 INVALID_REQUEST
錯誤。請參閱 max_validation_errors
,以便限制傳回的錯誤數量。
列舉 | |
---|---|
DEFAULT_SOLVE |
解答模型 |
VALIDATE_ONLY |
只驗證模型而不解決問題:盡可能填入最多的 OptimizeToursResponse.validation_errors 。 |
DETECT_SOME_INFEASIBLE_SHIPMENTS |
只會填入 重要事項:並非所有不可行的貨件都會在這裡傳回,只有在預先處理期間認定為不可行的貨運項目。 |
OptimizeToursResponse
解決包含路線圖最佳化問題、車輛略過的運輸以及解決方案的整體成本後的回應。
欄位 | |
---|---|
routes[] |
為每個車輛計算的路線, i-th 路線對應到模型中的 i-th 交通工具。 |
request_label |
|
skipped_shipments[] |
已略過的所有出貨商品清單。 |
validation_errors[] |
這裡列出了我們可獨立偵測到的所有驗證錯誤。請參閱 |
metrics |
這個解決方案的時間長度、距離和用量指標。 |
指標
所有路線的匯總總體指標。
欄位 | |
---|---|
aggregated_route_metrics |
這些路徑的匯總資料。每項指標都是相同名稱所有 |
skipped_mandatory_shipment_count |
略過的必要運送數量。 |
used_vehicle_count |
使用的車輛數量。注意:如果車輛路線為空白且 |
earliest_vehicle_start_time |
二手車輛的最早開始時間,以 |
latest_vehicle_end_time |
二手車輛的最晚結束時間,以 |
costs |
解決方案的費用,按照費用相關要求欄位細分。索引鍵是相對於輸入最佳化工具 ToursRequest 的 proto 路徑 (例如「model.shipments.pickups.cost」),值則是對應費用欄位產生的總費用,並匯總到整個解決方案的資料。換句話說,cost["model.shipments.pickups.cost"] 是解決方案的所有取貨費用總和。這裡會列出模型定義的所有費用,但截至 2022 年 1 月為止,僅以匯總方式回報 TransitionAttributes 相關費用的情況除外。 |
total_cost |
解決方案的總費用。費用對應中所有值的總和。 |
OptimizeToursValidationError
說明驗證 OptimizeToursRequest
時發生的錯誤。
欄位 | |
---|---|
code |
驗證錯誤是由一直顯示的組合 ( 其他欄位 (下方) 則提供與錯誤相關的更多內容。 多個錯誤:如有多個錯誤,驗證程序會嘗試輸出多個錯誤。與編譯器非常類似,這是不完美的過程。部分驗證錯誤屬於「嚴重」問題,這表示會停止整個驗證程序。這種情況包括 穩定性: REFERENCE:所有 (代碼、名稱) 組合的清單:
|
display_name |
錯誤顯示名稱。 |
fields[] |
錯誤內容可能涉及 0、1 (大部分時間) 或多個欄位。舉例來說,可以按照以下方式指定第 4 號車輛和第 2 件的第一件取貨:
不過請注意,錯誤代碼的 |
error_message |
使用者容易理解的錯誤說明字串。 STABILITY:不穩定:與特定 |
offending_values |
可能包含欄位的值。但不一定每次都適用。這個 API 僅供手動模型偵錯使用,絕對不然。 |
FieldReference
指定驗證錯誤的背景資訊。FieldReference
一律是指這個檔案中的特定欄位,並採用相同的階層結構。舉例來說,我們可以使用以下方式指定 start_time_windows
交通工具 #5 的元素 #2:
name: "vehicles" index: 5 sub_field { name: "end_time_windows" index: 2 }
但會省略頂層實體 (例如 OptimizeToursRequest
或 ShipmentModel
),以避免訊息擁擠。
欄位 | |
---|---|
name |
欄位名稱,例如「汽車」。 |
sub_field |
視需要建立遞迴巢狀子欄位。 |
聯集欄位
|
|
index |
欄位索引 (如果重複)。 |
key |
如果欄位是對應的鍵, |
OutputConfig
為 [BatchOptimizeTours][google.maps.routeoptimization.v1.RouteOptimizationService.BatchOptimizeTours] 結果指定目的地。
欄位 | |
---|---|
data_format |
必要欄位。輸出資料格式。 |
聯集欄位 destination 。必要欄位。destination 只能是下列其中一項: |
|
gcs_destination |
要寫入輸出內容的 Google Cloud Storage 位置。 |
運送地址
單一商品的運送方式,從某個到貨到其中一個貨品交付。任何不重複的車輛都必須前往其中一個上車地點 (並據此降低剩餘容量),才將運送行為判定為運轉,並於日後造訪其中一個送貨地點 (並據此重新提高剩餘容量)。
欄位 | |
---|---|
display_name |
使用者定義的貨件顯示名稱。長度上限為 63 個半形字元,可以使用 UTF-8 字元。 |
pickups[] |
與運送相關的取貨替代品組。如未指定,車輛只需要前往送貨地點即可。 |
deliveries[] |
與出貨相關的一組運送替代品。如未指定,車輛只需要前往上車地點對應的地點。 |
load_demands |
貨物運送需求 (例如重量、體積、棧板數量等)。地圖上的鍵必須是說明對應負載類型的 ID (最好同時包含單位)。例如:「weight_kg"、"volume_gallons"、"pallet_count」等。如果特定鍵沒有出現在地圖中,則相對應的載入會被視為空值。 |
allowed_vehicle_indices[] |
可能提供運送作業的一組車輛。如果空白,所有車輛都可以執行這項動作。車輛是按照 |
costs_per_vehicle[] |
指定每輛車出貨時產生的費用。如有指定,則必須具備以下條件:
這些費用必須與 |
costs_per_vehicle_indices[] |
|
pickup_to_delivery_absolute_detour_limit |
指定相較於從上車到到貨的最短路徑,指定絕對差道時間。指定的值必須為正數,且運送資訊必須至少包含自取和外送。 舉例來說,對於從所選取貨替代選項直接前往指定配送替代地址的時間,請耐心等候。然後設定
如果在同一批貨物上同時指定相對和絕對限制,則每組可能的自取/外送組合會使用較多限制。自 2017 年 10 月起,只有在未以車輛屬性為依據的行程期間,系統才會支援改道活動。 |
pickup_to_delivery_time_limit |
指定從開始取貨到開始出貨的最長時間。指定的值必須為正數,且運送資訊必須至少包含自取和外送。這不受取貨和外送選取的替代品項,或車輛速度而定。這可以同時指定最大轉乘限制條件:解決方案會同時遵循兩個規格。 |
shipment_type |
非空白字串,用於指定本次出貨的「類型」。這項功能可用於定義 從「 |
label |
指定這項貨物的標籤。這個標籤會在相應 |
ignore |
如果為 true,請略過此運送程序,但不要套用 如果模型中沒有任何 系統允許忽略在 |
penalty_cost |
如果商品未能出貨,該罰金會加計路線的整體費用。如果使用者造訪了取貨和外送替代品,系統會將其視為已出貨。費用可用單位表示模型中所有其他費用相關欄位所使用的單位,而且必須為正數。 重要事項:如未指明這項罰金,即視為無限制,也就是必須完成出貨。 |
pickup_to_delivery_relative_detour_limit |
指定從上車到下車的最短路徑,比較最長的相對往返時間。指定的值必須為正數,且運送資訊必須至少包含自取和外送。 舉例來說,對於從所選取貨替代選項直接前往指定配送替代地址的時間,請耐心等候。然後設定
如果在同一批貨物上同時指定相對和絕對限制,則每組可能的自取/外送組合會使用較多限制。自 2017 年 10 月起,只有在未以車輛屬性為依據的行程期間,系統才會支援改道活動。 |
載入
進行巡訪時,如果為上車地點,系統可能會將預先定義的金額加為自動載客量,如果送貨則會扣除。這類訊息的數量。查看《load_demands
》。
欄位 | |
---|---|
amount |
執行相應造訪的車輛負載量不同。由於這是整數,因此建議使用者選擇適當的單位,以免失去精確度。必須是 0 以上的數字。 |
VisitRequest
可由車輛完成造訪的要求:設有地理位置 (或下方兩個)、開始和打烊時間 (請見下方說明)、開始和打烊時間 (按時間範圍顯示),以及服務時間長度 (車輛抵達上車或下車後所花費的時間)。
欄位 | |
---|---|
arrival_location |
執行這個 |
arrival_waypoint |
執行這個 |
departure_location |
完成這個 |
departure_waypoint |
完成這個 |
tags[] |
指定造訪要求中附加的代碼。不允許空白或重複的字串。 |
time_windows[] |
限製造訪時的抵達時間。請注意,車輛可能會在抵達時間外離開,意即抵達時間 + 持續時間不限於特定時間範圍內。如果車輛在 缺少 時間範圍不得相互重疊,也就是說,時間範圍不得與其他時間範圍重疊或彼此相鄰,且必須以遞增順序排列。
|
duration |
造訪時間,例如從抵達到離開之間車輛花費的時間 (會加入可能的等待時間;請參閱 |
cost |
在車輛路線上處理此造訪要求的費用。這可用於針對不同的上車上車或貨物運送支付不同的費用。此費用必須與 |
load_demands |
這項造訪要求的載入需求。這與 |
visit_types[] |
指定造訪的類型。這項設定可用於分配車輛完成本次造訪所需的額外時間 (請參閱 類型只能出現一次。 |
label |
指定這個 |
ShipmentModel
貨運模型包含一組由一組車輛運作的貨物,同時將總成本降到最低,亦即下列項目的總和:
- 車輛路線費用 (所有車輛的每趟航程費用總和、每趟交通時間的費用和固定費用)。
- 未履行的出貨懲處。
- 全球貨運作業持續時間的費用
欄位 | |
---|---|
shipments[] |
必須在模型中執行的一組貨運組合。 |
vehicles[] |
用於進行巡訪的車組。 |
global_start_time |
模型的全域開始和結束時間:如果範圍超出這個範圍,就無法視為有效。 模型的時間範圍必須小於一年,也就是 使用 |
global_end_time |
如未設定,系統會預設使用世界標準時間 1971 年 1 月 1 日 00:00:00 (亦即秒數:31536000,nanos: 0)。 |
global_duration_cost_per_hour |
整體計畫的「全球持續時間」,是指所有車輛的最早有效開始時間和最新有效結束時間之間的差異。舉例來說,使用者可以為該數量指定每小時費用,嘗試並嘗試盡可能早完成工作。這筆費用必須與 |
duration_distance_matrices[] |
指定模型中使用的時間長度和距離矩陣。如果這個欄位空白,系統會根據 使用範例:
|
duration_distance_matrix_src_tags[] |
定義時間長度和距離矩陣來源的代碼; 標記與 |
duration_distance_matrix_dst_tags[] |
定義持續時間和距離矩陣目的地的代碼; 標記與 |
transition_attributes[] |
轉換屬性已新增至模型。 |
shipment_type_incompatibilities[] |
不相容的 shipping_types 集合 (請參閱 |
shipment_type_requirements[] |
|
precedence_rules[] |
必須在模型中強制執行的一組優先順序規則。 |
max_active_vehicles |
限制中車數量上限。如果路線至少執行一次運送,則車輛為活躍狀態。這可用於限制路線數量,以防駕駛人少於車輛,且車隊為異質車輛。系統會執行最佳化調整,選出最適合的車輛組合。必須為正數。 |
DurationDistanceMatrix
指定從造訪地點和車輛起點前往造訪地點的持續時間與距離矩陣。
欄位 | |
---|---|
rows[] |
指定時間長度與距離矩陣的資料列。元素數量必須和 |
vehicle_start_tag |
定義此時間長度和距離矩陣適用的車輛標記。如果空白,這項決定會套用至所有車輛,且只能有一個矩陣。 每個車輛起點都必須與一個矩陣完全相符,也就是與其其中一個 所有矩陣都必須有不同的 |
資料列
指定時間長度與距離矩陣的資料列。
欄位 | |
---|---|
durations[] |
指定資料列的時間長度值。元素數量必須和 |
meters[] |
指定資料列的距離值。如果模型中的距離沒有費用或限制,可以留空;否則,元素數量必須和 |
PrecedenceRule
兩個事件之間的優先規則 (每個事件為取貨或運送交付):「第二」事件必須在「第一個」開始後至少 offset_duration
開始。
有多個優先順序可指相同 (或相關的) 事件,例如:「B 點取餐後發生」和「到 A 點上車後進行 C 取貨」。
此外,優先順序只會在這兩件出貨時套用,否則會遭到忽略。
欄位 | |
---|---|
first_is_delivery |
指出「第一個」事件是否為提交事件。 |
second_is_delivery |
表示「second」事件是否為提交。 |
offset_duration |
「第一個」和「秒」事件之間的偏移值。可以是負數。 |
first_index |
「第一個」事件的運送索引。必須指定這個欄位。 |
second_index |
「第二件」事件的出貨索引。必須指定這個欄位。 |
ShipmentRoute
車輛的路線可以沿著時間軸分解,如下圖所示 (假設有人造訪了 n 次):
| | | | | T[2], | | |
| Transition | Visit #0 | | | V[2], | | |
| #0 | aka | T[1] | V[1] | ... | V[n-1] | T[n] |
| aka T[0] | V[0] | | | V[n-2],| | |
| | | | | T[n-1] | | |
^ ^ ^ ^ ^ ^ ^ ^
vehicle V[0].start V[0].end V[1]. V[1]. V[n]. V[n]. vehicle
start (arrival) (departure) start end start end end
請注意,我們會採用不同的做法:
- 「即時事件」,例如車輛的開始和結束,以及每次造訪的開始和結束 (又稱抵達和離開)。它們會在特定的一秒內發生。
- 「時間間隔」,例如造訪本身以及每次造訪之間的轉換。雖然時間間隔有時的時間長度可能為零,例如開始和在同一秒都結束,但持續時間通常是正值。
不變:
- 如果造訪為 n 次,則會有 n+1 次轉場。
- 造訪之前一律會先進行轉換 (相同索引) 加上在轉換之後 (索引 + 1) 的轉場。
- 車輛發動裝置後面一律是轉換 #0。
- 車輛終點一律在轉換 #n 前面。
放大後,以下是 Transition
和 Visit
期間的情況:
---+-------------------------------------+-----------------------------+-->
| TRANSITION[i] | VISIT[i] |
| | |
| * TRAVEL: the vehicle moves from | PERFORM the visit: |
| VISIT[i-1].departure_location to | |
| VISIT[i].arrival_location, which | * Spend some time: |
| takes a given travel duration | the "visit duration". |
| and distance | |
| | * Load or unload |
| * BREAKS: the driver may have | some quantities from the |
| breaks (e.g. lunch break). | vehicle: the "demand". |
| | |
| * WAIT: the driver/vehicle does | |
| nothing. This can happen for | |
| many reasons, for example when | |
| the vehicle reaches the next | |
| event's destination before the | |
| start of its time window | |
| | |
| * DELAY: *right before* the next | |
| arrival. E.g. the vehicle and/or | |
| driver spends time unloading. | |
| | |
---+-------------------------------------+-----------------------------+-->
^ ^ ^
V[i-1].end V[i].start V[i].end
最後,以下是轉換期間的旅遊、BREAK、延遲和 WAIT 方法。
- 不會重疊。
- 延遲是唯一的,而且必須是下次造訪 (或車輛結束) 前的連續時段。如此一來,您就能得知延遲時間的延遲時間和結束時間。
- BREAKS 是連續且不重疊的時段。回應會指定每個廣告插播的開始時間和持續時間。
- 旅遊和 WAIT 會「先佔」:在轉換期間,這些憑證可能會中斷數次。客戶可以假設旅遊「盡快」,「等待」會填入剩餘的時間。
複雜 (複雜) 範例:
TRANSITION[i]
--++-----+-----------------------------------------------------------++-->
|| | | | | | | ||
|| T | B | T | | B | | D ||
|| r | r | r | W | r | W | e ||
|| a | e | a | a | e | a | l ||
|| v | a | v | i | a | i | a ||
|| e | k | e | t | k | t | y ||
|| l | | l | | | | ||
|| | | | | | | ||
--++-----------------------------------------------------------------++-->
欄位 | |
---|---|
vehicle_index |
車輛正在執行路線,依來源 |
vehicle_label |
執行這條路線的車輛標籤,如指定,等於 |
vehicle_start_time |
車輛開始行駛路線的時間。 |
vehicle_end_time |
車輛完成路線的時間。 |
visits[] |
代表路線的一連串造訪。訪客 [i] 是指路線中的第 1 次造訪。如果這個欄位空白,系統會將車輛視為未使用。 |
transitions[] |
路線的轉換已排序清單。 |
has_traffic_infeasibilities |
如果
由於交通時間預估增加 ( |
route_polyline |
路線的編碼折線表示法。只有在 |
breaks[] |
執行這條路線的車輛排定的休息時間。 |
metrics |
這條路線的行車時間、距離和負載指標。視情境而定, |
route_costs |
路線費用,按照費用相關要求欄位細分。索引鍵是相對於輸入最佳化工具 ToursRequest 的 proto 路徑 (例如「model.shipments.pickups.cost」),值則是對應費用欄位產生的總費用,並經過整條路線匯總。換句話說,cost["model.shipments.pickups.cost"] 是航線的所有上車費用總和。這裡會列出模型定義的所有費用,但截至 2022 年 1 月為止,僅以匯總方式回報 TransitionAttributes 相關費用的情況除外。 |
route_total_cost |
路線總費用。費用對應中的所有費用總和。 |
休息一下
代表休息時間執行的資料。
欄位 | |
---|---|
start_time |
休息片刻的開始時間。 |
duration |
休息的時間長度。 |
EncodedPolyline
折線的編碼表示法。如要進一步瞭解折線編碼,請參閱:https://developers.google.com/maps/documentation/utilities/polylinealgorithm https://developers.google.com/maps/documentation/javascript/reference/geometry#encoding。
欄位 | |
---|---|
points |
代表折線編碼點的字串。 |
轉場
路線上兩個事件之間的轉換。請參閱 ShipmentRoute
的說明。
如果車輛沒有 start_location
和/或 end_location
,則對應的旅遊指標為 0。
欄位 | |
---|---|
travel_duration |
行程時間。 |
travel_distance_meters |
轉換期間行走的距離。 |
traffic_info_unavailable |
當透過 |
delay_duration |
套用至此轉換後的延遲時間總和。如果有的話,則延遲是從下一個事件 (造訪或車輛結束) 前 |
break_duration |
轉換期間發生的所有廣告插播時間總和 (如果有的話)。每個廣告插播的開始時間和時間長度詳細資料會儲存在 |
wait_duration |
轉換期間的等待時間。等待時間與閒置時間對應,不含休息時間。另請注意,這個等待時間可能會分成數個不連續的間隔。 |
total_duration |
轉換的總時間 (為了方便起見)。等於:
|
start_time |
轉換的開始時間。 |
route_polyline |
轉換期間採用的路徑編碼折線表示法。只有在 |
vehicle_loads |
車輛會在這段過渡期間載入,適用於這輛車 首次轉換期間的載入項目是車輛路線的起始載入。然後在每次造訪後,將造訪的 |
VehicleLoad
回報指定類型 (請參閱 Transition.vehicle_loads
) 路線中某點的實際負載量。
欄位 | |
---|---|
amount |
特定類型的車輛承載量。載入單位通常會由類型表示。查看《 |
前往
路線期間進行了一次造訪。這次造訪對應至 Shipment
的取貨或貨品交付。
欄位 | |
---|---|
shipment_index |
來源 |
is_pickup |
如果為 true,則造訪對應了 |
visit_request_index |
|
start_time |
造訪開始的時間。請注意,車輛可能會在抵達地點之前提早抵達。時間與 |
load_demands |
總造訪載入需求為出貨和造訪要求 |
detour |
旅客抵達目的地之前,系統會去索取貨物,並考量時間範圍內的潛在等待時間,因此可增加額外的班次時間。如果造訪為外送,則會從相應的上車造訪計算轉乘,且等於:
否則,系統會從車輛
|
shipment_label |
|
visit_label |
|
ShipmentTypeIncompatibility
根據 shipping_type 指定貨件之間的不相容問題。根據不相容模式,同一條路線上出現不相容的貨運情況也會受到限制。
欄位 | |
---|---|
types[] |
不相容類型清單。其中兩件出貨商品的 |
incompatibility_mode |
已套用至不相容的模式。 |
IncompatibilityMode
用於定義同一條路線中不相容貨物外觀受到限制的模式。
列舉 | |
---|---|
INCOMPATIBILITY_MODE_UNSPECIFIED |
未指定不相容的模式。請一律不要使用這個值。 |
NOT_PERFORMED_BY_SAME_VEHICLE |
在這個模式中,不相容類型的兩件運送不可共用同一輛車。 |
NOT_IN_SAME_VEHICLE_SIMULTANEOUSLY |
如果兩種運送方式與
|
ShipmentTypeRequirement
根據 shipping_type 指定不同出貨商品的運送需求。要求細節由需求模式定義。
欄位 | |
---|---|
required_shipment_type_alternatives[] |
「 |
dependent_shipment_types[] |
凡是在 注意:不允許鏈結規定,以便 |
requirement_mode |
已對要求套用模式。 |
RequirementMode
用於定義路線上依附運送情形的模式。
列舉 | |
---|---|
REQUIREMENT_MODE_UNSPECIFIED |
未指定的要求模式。請一律不要使用這個值。 |
PERFORMED_BY_SAME_VEHICLE |
在這個模式下,所有「相依」運送資訊都必須與至少其中一份「必要」運送共乘車輛相同。 |
IN_SAME_VEHICLE_AT_PICKUP_TIME |
使用 因此,「相依」運送的取貨服務必須具有下列其中一項條件:
|
IN_SAME_VEHICLE_AT_DELIVERY_TIME |
和先前相同,不過「相依」出貨時,交付時必須在車上安排「必要」運送事宜。 |
SkippedShipment
指定解決方案中未運轉的詳細資料。針對情節基本且/或可以找出略過的原因,我們會在這裡回報原因。
欄位 | |
---|---|
index |
這個索引會對應至來源 |
label |
|
reasons[] |
說明訂單遭略過的原因清單。請參閱 |
原因
這裡會列出原因,方便我們說明為何略過這項商品。如果所有車輛都基於不同的原因,reason
就會包含超過 1 個元素。略過的出貨資訊必須有重複的原因,也就是說,除了 example_vehicle_index
以外的所有欄位皆相同。示例:
reasons {
code: DEMAND_EXCEEDS_VEHICLE_CAPACITY
example_vehicle_index: 1
example_exceeded_capacity_type: "Apples"
}
reasons {
code: DEMAND_EXCEEDS_VEHICLE_CAPACITY
example_vehicle_index: 3
example_exceeded_capacity_type: "Pears"
}
reasons {
code: CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DISTANCE_LIMIT
example_vehicle_index: 1
}
略過的運送方式不適用於所有車輛。原因可能各不相同,但至少包括一輛車的「蘋果」容量 (包括車輛 1)、至少一部車輛的「梨子」容量超過一個車輛 (包括車輛 3),且至少車輛的距離超過一輛 (包括車輛 1)。
欄位 | |
---|---|
code |
請參閱程式碼的註解。 |
example_exceeded_capacity_type |
如果原因代碼為 |
example_vehicle_index |
如果原因與運送車輛不相容的原因有關,這個欄位會提供一輛相關車輛的索引。 |
程式碼
用於識別原因類型的代碼。此處的順序沒有任何意義。具體而言,它不會反映出指定原因是否在解決方案中的另一個之前顯示 (如果兩者都適用)。
列舉 | |
---|---|
CODE_UNSPECIFIED |
請一律不要使用。如果我們無法瞭解訂單遭到略過的原因,我們只會傳回空白的原因。 |
NO_VEHICLE |
款式沒有任何交通工具使所有貨物都無法運送。 |
DEMAND_EXCEEDS_VEHICLE_CAPACITY |
運送需求已超出車輛可容納某些容量類型的車輛容量,其中一項為 example_exceeded_capacity_type 。 |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DISTANCE_LIMIT |
執行這項運送作業所需的最短距離,例如從車輛的 請注意,我們在進行此計算時使用測地距離。 |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT |
完成出貨作業所需的最短時間,包括交通時間、等待時間和服務時間超過車輛的 注意:交通時間是以最佳情況計算,稱為測地距離 x 36 公尺/秒 (約/每小時 130 公里)。 |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TRAVEL_DURATION_LIMIT |
與上述相同,但我們只比較最短交通時間和車輛的 travel_duration_limit 。 |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TIME_WINDOWS |
如果車輛是在最佳情況下開始運送,則無法在最佳情況下執行此運送作業 (請參閱 CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT 有關時間計算的說明):總時間會使車輛在最晚的結束時間後結束。 |
VEHICLE_NOT_ALLOWED |
運送項目的 allowed_vehicle_indices 欄位並非空白,且這輛車不屬於該欄位。 |
TimeWindow
時段會限制事件的時間,例如造訪時的抵達時間或車輛的開始和結束時間。
硬性時間範圍邊界 (start_time
和 end_time
) 會強制執行事件的最早和最晚時間,例如 start_time <= event_time <=
end_time
。軟性視窗下限 (soft_start_time
) 代表在 soft_start_time
當天或之後發生事件的偏好,使用與 soft_start_time 事件發生前多少比例相成的比例計算。軟性時間範圍上限 (soft_end_time
) 代表在 soft_end_time
當天或之前發生事件的偏好,產生與事件發生 soft_end_time
後所需費用的比例相等。start_time
、end_time
、soft_start_time
和 soft_end_time
應符合全球時間限制 (請參閱 ShipmentModel.global_start_time
和 ShipmentModel.global_end_time
),且必須遵循以下規定:
0 <= `start_time` <= `soft_start_time` <= `end_time` and
0 <= `start_time` <= `soft_end_time` <= `end_time`.
欄位 | |
---|---|
start_time |
硬性時間範圍的開始時間。如未指定,系統會將該值設為 |
end_time |
硬性時間範圍的結束時間。如未指定,系統會將該值設為 |
soft_start_time |
時間範圍的軟開始時間。 |
soft_end_time |
時間範圍的軟結束時間。 |
cost_per_hour_before_soft_start_time |
如果在 soft_start_time 前發生事件,模型中其他費用加上的每小時費用,計算方式如下:
成本必須是正數,且只有在已設定 soft_start_time 時才能設定該欄位。 |
cost_per_hour_after_soft_end_time |
如果事件發生在
這筆費用必須是正數,且只有在已設定 |
TransitionAttributes
指定路線上連續兩次造訪間的轉場屬性。同一種轉場效果可能會有多個 TransitionAttributes
:在這種情況下,所有額外費用會增加,並套用最嚴格的限製或限制 (以下自然的「AND」語意)。
欄位 | |
---|---|
src_tag |
定義這些屬性組合 (src->dst) 轉換的代碼會套用到這些屬性。 如果 |
excluded_src_tag |
查看《 |
dst_tag |
如果目的地造訪或車輛結束的 |
excluded_dst_tag |
查看《 |
cost |
指定執行這項轉換作業的費用。這與模型內所有其他費用的單位相同,而且不得為負數。此費用會與所有其他現有費用相加。 |
cost_per_kilometer |
指定執行這個轉換作業時,系統對移動距離所套用的每公里費用。這會增加車輛上指定的任何 |
distance_limit |
指定執行轉換時移動的距離限制。 自 2021 年 6 月起,僅支援軟性限制。 |
delay |
指定執行這項轉場效果時發生的延遲時間。 這類延遲一律會在來源造訪完成「之後」以及開始目的地造訪「之前」, |
車輛
模擬運送問題的車輛。如要解決運送問題,這會為這輛車建立從 start_location
開始並在 end_location
結束的路線。路徑是指一連串的造訪 (請參閱 ShipmentRoute
)。
欄位 | |
---|---|
display_name |
使用者定義的車輛顯示名稱。長度上限為 63 個半形字元,可以使用 UTF-8 字元。 |
travel_mode |
交通模式會影響車輛可使用的道路和速度。另請參閱 |
start_location |
車輛在收件前開始的地理位置。如未指定,車輛會從車輛第一次上車地點開始。如果運送模型包含時間長度和距離矩陣,就不得指定 |
start_waypoint |
這個路線控點代表車輛出發前的地理位置。如未指定 |
end_location |
車輛在上次 |
end_waypoint |
代表車輛在上次 |
start_tags[] |
指定附加至車輛路線起點的標記。 不允許空白或重複的字串。 |
end_tags[] |
指定附加至車輛路線終點的標記。 不允許空白或重複的字串。 |
start_time_windows[] |
車輛可能離開發車地點的時間範圍。這些限制不得超過全球時間限制 (請參閱 屬於相同重複欄位的時段必須不連續,也就是說,所有時間範圍不得與另一個時間範圍重疊或相鄰,且必須按照時間順序排列。
|
end_time_windows[] |
車輛可能抵達終點的時段。這些限制不得超過全球時間限制 (請參閱 屬於相同重複欄位的時段必須不連續,也就是說,所有時間範圍不得與另一個時間範圍重疊或相鄰,且必須按照時間順序排列。
|
unloading_policy |
正在卸載對車輛強制執行的政策。 |
load_limits |
車輛容量 (例如重量、體積、棧板數量)。地圖上的鍵是載入類型的 ID,與 |
cost_per_hour |
車輛費用:所有費用加總,且必須與 車輛路線每小時費用。系統會根據路線的總時間計算這筆費用,包括交通時間、等待時間和造訪時間。如果使用 |
cost_per_traveled_hour |
車輛每經過一小時的費用。這筆費用僅適用於路線行駛時間 (如 |
cost_per_kilometer |
車輛路線每公里的費用。此費用適用於 |
fixed_cost |
此車輛用來處理運送事宜時須支付固定費用。 |
used_if_route_is_empty |
這個欄位僅適用於車輛路線不提供任何貨運的車輛。指出車輛是否應視為二手車。 如果為 true,車輛會從起點到終點,即使沒有供貨,也會將起點途中出發的時間和距離成本納入考量。 否則,車輛無法從起點到終點之間移動,而這輛車沒有排定的 |
route_duration_limit |
適用於車輛路線總時間長度的限制。在特定 |
travel_duration_limit |
適用於車輛路線的行駛時間限制。在指定的 |
route_distance_limit |
適用於車輛路線總距離的限制。在指定的 |
extra_visit_duration_for_visit_type |
指定從 Visit_types 字串到持續時間的對應。時間長度除了 如果造訪要求有多個類型,系統會在地圖上為每種類型加入一個時間長度。 |
break_rule |
說明這輛車要強制執行的休息時間表。如果留空,這輛車不會安排休息時間。 |
label |
指定這輛車的標籤。這個標籤會在回應中回報為相應 |
ignore |
如果為 true, 如果運送由 如果運送資訊是由 |
travel_duration_multiple |
指定乘法係數,可用於增加或減少這輛車的交通時間。舉例來說,如果設為 2.0,代表這輛車的速度較慢,且交通時間是標準車輛的兩倍。但這不會影響造訪停留時間。如果指定 警告:套用此倍數後,系統會將交通時間四捨五入至最接近的秒數,但在執行數字運算之前,因此如果計算精確度,可能會降低精確度。 另請參閱下方的 |
DurationLimit
用於定義車輛路線最長持續時間的限制。包括硬性或軟性問題。
定義非強制性限制欄位時,必須同時定義「軟上限」門檻及其相關費用。
欄位 | |
---|---|
max_duration |
嚴格限制會將時間長度限制在 max_duration 內。 |
soft_max_duration |
軟性限制不會強制執行持續時間上限,但如果違反,則會導致路線產生費用。這筆費用會併入模型中定義的其他費用,而單位也相同。 如已定義, |
quadratic_soft_max_duration |
軟性限制不會強制執行持續時間上限,但如果違反,會導致路徑在期間產生二次級費用。這筆費用會併入模型中定義的其他費用,而單位也相同。 如已定義,
|
cost_per_hour_after_soft_max |
違反
費用不得為負數。 |
cost_per_square_hour_after_quadratic_soft_max |
違反 如果時間長度未達門檻,額外費用則為 0。如果時間長度未達門檻,則費用取決於持續時間:
費用不得為負數。 |
LoadLimit
定義車輛適用的負載限制,例如:「這輛卡車最多只能攜帶 3500 公斤。」查看《load_limits
》。
欄位 | |
---|---|
soft_max_load |
負載的軟限制。查看《 |
cost_per_unit_above_soft_max |
如果這輛車路線的負載超過 |
start_load_interval |
車輛在路線起點時可接受的裝載間隔。 |
end_load_interval |
路線終點的可接受載客間隔。 |
max_load |
可接受的負載量上限。 |
時間間隔
可接受的負載量間隔。
欄位 | |
---|---|
min |
|
max |
可接受的最大負載。必須是 0 以上的數字。如未指定,則不受這個訊息限制的負載上限。如果兩者同時指定, |
TravelMode
供車輛使用的交通方式。
這些應是 Google 地圖平台路線優先 API 交通模式的子集,詳情請參閱:https://developers.google.com/maps/documentation/routes_preferred/reference/rest/Shared.Types/RouteTravelMode。
列舉 | |
---|---|
TRAVEL_MODE_UNSPECIFIED |
未指定交通方式,相當於 DRIVING 。 |
DRIVING |
與行車路線 (汽車、...) 對應的交通模式。 |
WALKING |
與步行路線對應的交通模式。 |
UnloadingPolicy
車輛卸載方式的政策。僅適用於有自取和外送服務的運送。
其他運輸公司可在 unloading_policy
以外的任何路線上免費運送。
列舉 | |
---|---|
UNLOADING_POLICY_UNSPECIFIED |
未指定且未載入的政策;遞送作業必須在相應的上車地點後不久。 |
LAST_IN_FIRST_OUT |
商品必須以反向取貨順序舉行 |
FIRST_IN_FIRST_OUT |
配送地點必須與取貨順序相同 |
途經點
封裝路線點。路線控點會標出 VisitRequests 的抵達和出發地點,以及車輛的起點和終點。
欄位 | |
---|---|
side_of_road |
選用設定。表示這個路線控點的位置為優先於車輛在特定道路上停下。設定這個值後,路線就會通過該位置,這樣一來,車輛就會在該位置偏離道路中心的一側停靠。這個選項不適用於「WALKING」交通模式。 |
聯集欄位 location_type 。代表地點的各種方式。location_type 只能是下列其中一項: |
|
location |
使用地理座標指定的點,包括選用方向。 |
place_id |
與路線控點相關聯的搜尋點地點 ID。 |