索引
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(訊息)OptimizeToursLongRunningMetadata(訊息)OptimizeToursRequest(訊息)OptimizeToursRequest.SearchMode(列舉)OptimizeToursRequest.SolvingMode(列舉)OptimizeToursResponse(訊息)OptimizeToursResponse.Metrics(訊息)OptimizeToursUriMetadata(訊息)OptimizeToursUriRequest(訊息)OptimizeToursUriResponse(訊息)OptimizeToursValidationError(訊息)OptimizeToursValidationError.FieldReference(訊息)OutputConfig(訊息)RouteModifiers(訊息)Shipment(訊息)Shipment.Load(訊息)Shipment.VisitRequest(訊息)ShipmentModel(訊息)ShipmentModel.DurationDistanceMatrix(訊息)ShipmentModel.DurationDistanceMatrix.Row(訊息)ShipmentModel.Objective(訊息)ShipmentModel.Objective.Type(列舉)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(訊息)Uri(訊息)Vehicle(訊息)Vehicle.DurationLimit(訊息)Vehicle.LoadLimit(訊息)Vehicle.LoadLimit.Interval(訊息)Vehicle.LoadLimit.LoadCost(訊息)Vehicle.TravelMode(列舉)Vehicle.UnloadingPolicy(列舉)VehicleFullness(訊息)Waypoint(訊息)
RouteOptimization
這項服務可最佳化車輛導覽。
特定類型欄位的有效性:
google.protobuf.Timestamp- 時間採用 Unix 時間格式,也就是自 1970 年 1 月 1 日 00:00:00 (UTC) 起算的秒數。
- 秒數必須介於 [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)。最佳化輸入內容 ( 使用者可以輪詢 如果 LRO 如果 LRO 的
|
| OptimizeTours |
|---|
|
傳送包含
目標是將
|
| OptimizeToursLongRunning |
|---|
|
這是 傳回的 實驗功能:詳情請參閱 https://developers.google.com/maps/tt/route-optimization/experimental/otlr/make-request。
|
| OptimizeToursUri |
|---|
|
這是 用戶端會指定儲存在 Google Cloud Storage 中的 如果最佳化作業需要幾分鐘以上的時間,且輸入/輸出大小超過 8 MB,建議使用這個方法,而非 傳回的 實驗功能:詳情請參閱 https://developers.google.com/maps/tt/route-optimization/experimental/otlr/make-request。
|
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 |
整個路線 (或解決方案) 達成的最大負載,針對該路線 (或解決方案) 上的每個數量,計算為所有 |
performed_mandatory_shipment_count |
執行的強制出貨次數。 實驗性:這個欄位的行為或存在狀態日後可能會變更。 |
performed_shipment_penalty_cost_sum |
已執行出貨的 實驗性:這個欄位的行為或存在狀態日後可能會變更。 |
BatchOptimizeToursMetadata
這個類型沒有任何欄位。
BatchOptimizeToursRequest 呼叫的作業中繼資料。
BatchOptimizeToursRequest
要求以非同步作業批次最佳化導覽。每個輸入檔案應包含一個 OptimizeToursRequest,每個輸出檔案則會包含一個 OptimizeToursResponse。要求包含讀取/寫入及剖析檔案的資訊。所有輸入和輸出檔案都應位於同一專案中。
| 欄位 | |
|---|---|
parent |
必要欄位。用於發出呼叫的目標專案和位置。 格式:
如未指定位置,系統會自動選擇區域。 |
model_configs[] |
必要欄位。每個購買模型的輸入/輸出資訊,例如檔案路徑和資料格式。 |
AsyncModelConfig
用於非同步解決單一最佳化模型的資訊。
| 欄位 | |
|---|---|
display_name |
(選用步驟) 使用者定義的模型名稱,可做為別名,方便使用者追蹤模型。 |
input_config |
必要欄位。輸入模型的相關資訊。 |
output_config |
必要欄位。所需的輸出位置資訊。 |
BatchOptimizeToursResponse
這個類型沒有任何欄位。
回覆 BatchOptimizeToursRequest。作業完成後,系統會在長時間執行的作業中傳回這項資訊。
BreakRule
為車輛產生休息時間 (例如午休) 的規則。休息是指車輛在目前位置閒置的一段連續時間,期間無法執行任何拜訪。休息時間可能會在以下情況發生:
- 兩次造訪之間的行程 (包括造訪前或造訪後的時間,但不包括造訪期間),在這種情況下,系統會延長兩次造訪之間的相應轉乘時間,
- 或在車輛啟動前 (車輛可能不會在休息期間啟動),在這種情況下,車輛啟動時間不會受到影響。
- 或車輛結束後 (同樣會顯示車輛結束時間)。
| 欄位 | |
|---|---|
break_requests[] |
休息時間的順序。請參閱 |
frequency_constraints[] |
可能適用多個 |
BreakRequest
必須事先瞭解適用於每輛車的休息順序 (即休息次數和順序)。重複的 BreakRequests 會定義該序列,且必須按照出現順序發生。時間範圍 (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_below_soft_max |
每公里產生的費用,最高可達
|
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 中所有拜訪行程的開始時間和順序,且無法在這些路線中插入或新增拜訪行程。此外,除非車輛為空 (即沒有任何拜訪行程,且模型中的 used_if_route_is_empty 設為 false),否則 routes 中的車輛開始和結束時間會受到完全限制。
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 時新增兩個 relaxations,並設定相同的 level,一個只設定 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 指定正東方的航向,依此類推。 |
OptimizeToursLongRunningMetadata
這個類型沒有任何欄位。
OptimizeToursLongRunning 呼叫的作業中繼資料。
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:
這項解讀適用於 如果是 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,否則這些錯誤通常會以 BadRequest 錯誤詳細資料 (https://cloud.google.com/apis/design/errors#error_details) 附加至 INVALID_ARGUMENT 錯誤酬載:請參閱 |
SearchMode
定義搜尋行為的模式,在延遲時間與解決方案品質之間取捨。無論採用何種模式,系統都會強制執行全域要求截止時間。
| 列舉 | |
|---|---|
SEARCH_MODE_UNSPECIFIED |
未指定搜尋模式,等同於 RETURN_FAST。 |
RETURN_FAST |
找到第一個合適的解決方案後,請停止搜尋。 |
CONSUME_ALL_AVAILABLE_TIME |
盡量花時間尋找更好的解決方案。 |
SolvingMode
定義求解器應如何處理要求。在 VALIDATE_ONLY 以外的所有模式中,如果要求無效,您會收到 INVALID_REQUEST 錯誤。如要限制傳回的錯誤數量,請參閱max_validation_errors。
| 列舉 | |
|---|---|
DEFAULT_SOLVE |
解出模型。警告可能會在 [OptimizeToursResponse.validation_errors][google.cloud.optimization.v1.OptimizeToursResponse.validation_errors] 中發出。 |
VALIDATE_ONLY |
只驗證模型,但不求解:盡可能填入 OptimizeToursResponse.validation_errors。 |
DETECT_SOME_INFEASIBLE_SHIPMENTS |
只會填入 重要事項:這裡不會傳回所有不可行的出貨,只會傳回在預先處理期間偵測到不可行的出貨。 |
TRANSFORM_AND_RETURN_REQUEST |
只有在 實驗功能:詳情請參閱 https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request。 |
OptimizeToursResponse
解決導覽最佳化問題後的回應,其中包含每輛車輛行駛的路徑、已略過的貨物,以及解決方案的整體成本。
| 欄位 | |
|---|---|
routes[] |
為每部車輛計算的路線;第 i 條路線對應模型中的第 i 部車輛。 |
request_label |
如果要求中指定標籤,則為 |
skipped_shipments[] |
所有已略過的出貨清單。 |
validation_errors[] |
我們獨立偵測到的所有驗證錯誤清單。請參閱「MULTIPLE ERRORS」說明,瞭解 |
processed_request |
在某些情況下,我們會先修改傳入的要求 (例如新增費用),再解決問題。如果 solving_mode == TRANSFORM_AND_RETURN_REQUEST,則修改後的要求會在此處傳回。 實驗功能:詳情請參閱 https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request。 |
metrics |
這項解決方案的時長、距離和用量指標。 |
指標
所有路線的匯總整體指標。
| 欄位 | |
|---|---|
aggregated_route_metrics |
匯總所有路線的資料。每個指標都是所有同名 |
skipped_mandatory_shipment_count |
略過的強制出貨次數。 |
used_vehicle_count |
使用的車輛數量。注意:如果車輛路線為空白且 |
earliest_vehicle_start_time |
二手車的最早開始時間,計算方式為所有二手車的 |
latest_vehicle_end_time |
二手車的最新結束時間,計算方式為所有二手車的 |
costs |
解決方案的費用,依費用相關要求欄位細分。鍵是相對於輸入 OptimizeToursRequest 的原型路徑,例如「model.shipments.pickups.cost」,值則是對應費用欄位產生的總費用,並彙整整個解決方案。換句話說,costs["model.shipments.pickups.cost"] 是解決方案中所有取貨費用的總和。模型中定義的所有費用都會在此詳細列出,但與 TransitionAttributes 相關的費用除外,這類費用自 2022 年 1 月起只會以匯總方式列出。 |
total_cost |
解決方案的總費用。費用對應中的所有值總和。 |
OptimizeToursUriMetadata
這個類型沒有任何欄位。
OptimizeToursUri 呼叫的作業中繼資料。
OptimizeToursUriRequest
OptimizeToursUri 方法使用的要求。
| 欄位 | |
|---|---|
parent |
必要欄位。要發出呼叫的目標專案或位置。 格式:
如未指定位置,系統會自動選擇區域。 |
input |
必要欄位。包含 |
output |
必要欄位。將包含 |
OptimizeToursUriResponse
OptimizeToursUri 方法傳回的回應。
| 欄位 | |
|---|---|
output |
(選用步驟) 包含 資源的 |
OptimizeToursValidationError
說明驗證 OptimizeToursRequest 時發生的錯誤或警告。
| 欄位 | |
|---|---|
code |
驗證錯誤是由一對 ( 這個部分後方的欄位會提供更多錯誤相關背景資訊。 多項錯誤:如果有多項錯誤,驗證程序會嘗試輸出多項錯誤。與編譯器類似,這項程序並不完美。部分驗證錯誤屬於「嚴重」錯誤,會導致整個驗證程序停止。 穩定性: |
display_name |
錯誤顯示名稱。 |
fields[] |
錯誤情境可能涉及 0 個、1 個 (大部分時間) 或多個欄位。舉例來說,如要參照車輛 #4 和貨運 #2 的首次取貨,可以按照下列方式操作: 但請注意,特定錯誤碼的基數不應變更。 |
error_message |
使用者容易理解的錯誤說明字串。 穩定性:不穩定:與特定 |
offending_values |
可能包含欄位的值。這項功能不一定適用於所有裝置。您絕對不應依賴這項功能,只能用於手動偵錯模型。 |
FieldReference
指定驗證錯誤的環境。FieldReference 一律是指這個檔案中的特定欄位,並遵循相同的階層結構。舉例來說,我們可以使用以下程式碼,指定車輛 #5 的元素 #2:start_time_windows
name: "vehicles" index: 5 sub_field { name: "end_time_windows" index: 2 }
不過,我們會省略 OptimizeToursRequest 或 ShipmentModel 等頂層實體,避免訊息過於擁擠。
| 欄位 | |
|---|---|
name |
欄位名稱,例如「vehicles」。 |
sub_field |
視需要遞迴巢狀子欄位。 |
聯集欄位
|
|
index |
如果是重複欄位,則為欄位的索引。 |
key |
如果欄位是對應項,則為鍵。 |
OutputConfig
指定 [BatchOptimizeTours][google.maps.routeoptimization.v1.RouteOptimizationService.BatchOptimizeTours] 結果的目的地。
| 欄位 | |
|---|---|
data_format |
必要欄位。輸出資料格式。 |
聯集欄位 destination。必要欄位。destination 只能是下列其中一項: |
|
gcs_destination |
要寫入輸出內容的 Google Cloud Storage 位置。 |
RouteModifiers
封裝一組選用條件,用於計算車輛路線時。這與 Google 地圖平台 Routes Preferred API 中的 RouteModifiers 類似,詳情請參閱:https://developers.google.com/maps/documentation/routes/reference/rest/v2/RouteModifiers。
| 欄位 | |
|---|---|
avoid_tolls |
指定是否要盡量避開收費道路。系統會優先選擇不含收費道路的路線。僅適用於機動交通方式。 |
avoid_highways |
指定是否要盡量避開高速公路。系統會優先選擇不含高速公路的路徑。僅適用於機動交通方式。 |
avoid_ferries |
指定是否應盡量避開渡輪。系統會優先顯示不含渡輪的路線。僅適用於機動交通方式。 |
avoid_indoor |
(選用步驟) 指定是否應盡量避免室內導航。系統會優先提供不含室內導航的路線。僅適用於「 |
運送地址
單一商品的運送過程,從其中一個取貨地點到其中一個送達地點。如要將運送視為已完成,專屬車輛必須前往其中一個取貨地點 (並相應減少備用容量),然後前往其中一個送貨地點 (並相應增加備用容量)。
| 欄位 | |
|---|---|
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 |
指定與取貨地點到送達地點之間最短路徑相比,絕對繞路時間上限。如要指定,必須為非負值,且出貨內容至少須包含取貨和送達。 舉例來說,假設 t 是從所選取貨替代方案直接前往所選送貨替代方案的最短時間。然後設定 如果同一批貨物同時指定相對和絕對限制,系統會針對每個可能的取貨/送達配對,採用較嚴格的限制。自 2017 年 10 月起,只有在行程時間不取決於車輛時,系統才會支援繞道。 |
pickup_to_delivery_time_limit |
指定貨件從取貨開始到開始運送之間的最長時間。如要指定,必須為非負值,且出貨內容至少須包含取貨和送達。這與取貨和送貨的替代方案或車輛速度無關。這項限制可以與最大繞道限制一併指定,解決方案會同時遵守這兩項規格。 |
shipment_type |
非空白字串,指定這批貨件的「類型」。這項功能可用於定義 與單次取貨/送貨的 |
label |
指定這批貨件的標籤。這個標籤會在對應 |
ignore |
如果為 true,請略過這批貨,但不要套用 如果模型中含有任何 你可以忽略在 |
penalty_cost |
如果未完成出貨,這筆罰款會加到路線的總成本中。如果選擇自取或替代運送方式,且已前往取貨地點,系統就會將該貨件視為已完成運送。費用可採用模型中所有其他費用相關欄位使用的相同單位,且必須為正數。 重要事項:如未指定這項處罰,系統會視為無限期,也就是必須完成出貨。 |
pickup_to_delivery_relative_detour_limit |
指定與取貨到送達之間最短路徑相比,可接受的最大相對繞道時間。如要指定,必須為非負值,且出貨內容至少須包含取貨和送達。 舉例來說,假設 t 是從所選取貨替代方案直接前往所選送貨替代方案的最短時間。然後設定 如果同一批貨物同時指定相對和絕對限制,系統會針對每個可能的取貨/送達配對,採用較嚴格的限制。自 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 |
指定這個 |
avoid_u_turns |
指定在這個地點的行車路線中是否應避開迴轉。系統會盡量避免迴轉,但不保證完全不會迴轉。這項功能仍在實驗階段,行為可能會變更。 實驗功能:詳情請參閱 https://developers.google.com/maps/tt/route-optimization/experimental/u-turn-avoidance/make-request。 |
ShipmentModel
貨運模型包含一組必須由一組車輛執行的貨運,同時盡量減少總成本,也就是下列各項的總和:
- 車輛路線規劃費用 (所有車輛的總時間費用、行車時間費用和固定費用總和)。
- 未履行運送的違規處置。
- 全球運送時間的成本
| 欄位 | |
|---|---|
shipments[] |
模型中必須執行的出貨作業組合。 |
vehicles[] |
可用於執行拜訪作業的車輛組合。 |
objectives[] |
這個模型的目標組合,我們會將其轉換為費用。如果不是空白,輸入模型必須免費。如要取得修改後的要求,請使用 實驗功能:詳情請參閱 https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request。 |
global_start_time |
模型的全球開始和結束時間:超出這個範圍的時間一律無效。 模型的時間範圍必須少於一年,也就是說, 使用 |
global_end_time |
如未設定,系統會使用預設值:世界標準時間 1971 年 1 月 1 日 00:00:00 (亦即秒數:31536000,奈秒數:0)。 |
global_duration_cost_per_hour |
整體方案的「全球時間長度」是指所有車輛最早的生效開始時間與最晚的生效結束時間之間的差異。使用者可以為該數量指派每小時的費用,盡量縮短作業完成時間。這個費用必須與 |
duration_distance_matrices[] |
指定模型中使用的時間和距離矩陣。如果這個欄位空白,系統會改用 Google 地圖或測地距離,具體取決於 使用範例:
|
duration_distance_matrix_src_tags[] |
定義時間長度和距離矩陣來源的標記; 標記會對應至 |
duration_distance_matrix_dst_tags[] |
定義時間和距離矩陣目的地的標記; 標記會對應至 |
transition_attributes[] |
新增至模型的轉場屬性。 |
shipment_type_incompatibilities[] |
不相容的 shipment_type 組合 (請參閱 |
shipment_type_requirements[] |
|
precedence_rules[] |
模型中必須強制執行的優先順序規則集。 重要事項:使用優先順序規則會限制可最佳化問題的大小。如果優先順序規則包含大量出貨內容,系統可能會拒絕要求。 |
max_active_vehicles |
限制有效車輛數量上限。如果車輛的路線至少執行一次出貨作業,該車輛就會處於有效狀態。如果車輛數多於駕駛人數,且車隊車輛種類不一,這項功能可限制路線數量。最佳化功能會選取最適合的車輛子集。必須為嚴格正數。 |
DurationDistanceMatrix
指定從拜訪地點和車輛起點到拜訪地點和車輛終點的距離和時間矩陣。
| 欄位 | |
|---|---|
rows[] |
指定時間和距離矩陣的資料列。元素數量必須與 |
vehicle_start_tag |
標記,定義這項時間長度和距離矩陣適用於哪些車輛。如果留空,則適用於所有車輛,且只能有一個矩陣。 每輛車的起點都必須與一個矩陣完全相符,也就是說,車輛的 所有矩陣的 |
列
指定時間和距離矩陣的資料列。
| 欄位 | |
|---|---|
durations[] |
指定資料列的持續時間值。元素數量必須與 |
meters[] |
指定資料列的距離值。如果模型中沒有任何成本或限制是指距離,則可以留空;否則必須與 |
目標
目標會完全取代費用模式,因此與先前的費用不相容。每個目標都會對應到預先定義的成本,例如車輛、貨運或轉移屬性。
實驗功能:詳情請參閱 https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request。
| 欄位 | |
|---|---|
type |
目標類型。 |
weight |
這個目標相對於其他目標的權重。可以是任何非負數,權重總和不必為 1。權重預設為 1.0。 |
類型
要對應一組費用的目標類型。
| 列舉 | |
|---|---|
DEFAULT |
系統會使用預設費用組合,確保提供合理的解決方案。注意:這項目標可以單獨使用,但如果使用者指定的目標中沒有這項目標,系統一律會以權重 1.0 新增這項目標做為基準。 |
MIN_DISTANCE |
「MIN」目標。盡量縮短總行駛距離。 |
MIN_WORKING_TIME |
盡量縮短所有車輛的總工作時間。 |
MIN_TRAVEL_TIME |
與上述相同,但僅著重於旅行時間。 |
MIN_NUM_VEHICLES |
盡量減少使用的車輛數量。 |
PrecedenceRule
兩個事件 (分別是貨件的取貨或送達) 之間的優先順序規則:「第二個」事件必須在「第一個」事件開始後至少 offset_duration 開始。
多個優先順序可參照相同 (或相關) 事件,例如「B 的取貨時間在 A 送達後」和「C 的取貨時間在 B 取貨後」。
此外,優先順序只會在兩批貨物都出貨時套用,否則會遭到忽略。
| 欄位 | |
|---|---|
first_is_delivery |
指出「第一個」事件是否為運送。 |
second_is_delivery |
指出「第二個」事件是否為運送。 |
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
最後,以下說明如何在轉場期間安排 TRAVEL、BREAKS、DELAY 和 WAIT。
- 不會重疊。
- DELAY 是獨一無二的,且必須是下一次拜訪 (或車輛結束) 前的連續時間。因此,只要知道延遲時間長度,就能得知延遲的開始和結束時間。
- 中斷時間是連續且不重疊的時間範圍。回應會指定每個休息時間的開始時間和長度。
- 「TRAVEL」和「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[] |
代表路線的造訪順序。visits[i] 是路線中的第 i 個造訪地點。如果這個欄位空白,系統會將車輛視為未使用。 |
transitions[] |
路徑的轉場效果排序清單。 |
has_traffic_infeasibilities |
如果 由於交通流量增加,預估行程時間也隨之增加 |
route_polyline |
路線的編碼折線表示法。只有在 |
breaks[] |
這條路線的車輛排定休息時間。 |
metrics |
這條路線的時長、距離和負重指標。視情況而定, |
vehicle_fullness |
實驗性:這個欄位的行為或存在狀態日後可能會變更。 |
route_costs |
路線費用,依費用相關要求欄位細分。這些鍵是相對於輸入 OptimizeToursRequest 的原型路徑,例如「model.shipments.pickups.cost」,值則是對應費用欄位產生的總費用,並彙整整個路線的費用。換句話說,costs["model.shipments.pickups.cost"] 是路線上所有取貨費用的總和。模型中定義的所有費用都會在此詳細列出,但與 TransitionAttributes 相關的費用除外,這類費用自 2022 年 1 月起只會以匯總方式列出。 |
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 |
遷移期間所遵循路線的編碼折線表示法。只有在 |
route_token |
僅供輸出。這個不透明權杖可傳遞至 Navigation SDK,在導航期間重建路線,並在重新規劃路線時,根據建立路線時的原始意圖進行規劃。請將這個權杖視為不透明的 Blob。請勿比較不同要求中的值,因為即使服務傳回完全相同的路線,這個值也可能會變更。只有在 |
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 |
如果 |
injected_solution_location_token |
不透明權杖,代表造訪地點的相關資訊。 如果這個造訪的 實驗功能:詳情請參閱 https://developers.google.com/maps/tt/route-optimization/experimental/u-turn-avoidance/make-request。 |
ShipmentTypeIncompatibility
根據 shipment_type 指定出貨內容之間的不相容性。系統會根據不相容模式,限制同一路線上不相容貨件的顯示方式。
| 欄位 | |
|---|---|
types[] |
不相容的類型清單。如果清單中的兩批貨件有不同的 |
incompatibility_mode |
套用至不相容項目的模式。 |
IncompatibilityMode
模式:定義如何限制同一路線上不相容的出貨內容。
| 列舉 | |
|---|---|
INCOMPATIBILITY_MODE_UNSPECIFIED |
未指定不相容模式。請一律不要使用這個值。 |
NOT_PERFORMED_BY_SAME_VEHICLE |
在此模式下,類型不相容的兩批貨物絕不會共用同一輛車。 |
NOT_IN_SAME_VEHICLE_SIMULTANEOUSLY |
在此模式下,類型不相容的兩批貨物絕不會同時出現在同一輛車上:
|
ShipmentTypeRequirement
根據出貨類型,指定出貨之間的規定。具體要求取決於需求模式。
| 欄位 | |
|---|---|
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[] |
說明貨件遭略過原因的清單。請參閱上方的留言 |
penalty_cost |
這是 實驗性:這個欄位的行為或存在狀態日後可能會變更。 |
estimated_incompatible_vehicle_ratio |
預估無法執行這項出貨作業的車輛比例,原因至少包括下列其中一項。注意:只有在原因與車輛有關時,才會填寫這項資訊。 實驗性:這個欄位的行為或存在狀態日後可能會變更。 |
原因
如果我們能說明為何跳過出貨,原因會列在這裡。如果所有車輛的理由不盡相同,reason 會有多個元素。略過的貨件不得有重複原因,也就是說,除了 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_vehicle_indices[] |
與 實驗性:這個欄位的行為或存在狀態日後可能會變更。 |
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 欄位不為空白,且這輛車不屬於該欄位。 |
VEHICLE_IGNORED |
車輛的 實驗性:這個欄位的行為或存在狀態日後可能會變更。 |
SHIPMENT_IGNORED |
出貨商品的 實驗性:這個欄位的行為或存在狀態日後可能會變更。 |
SKIPPED_IN_INJECTED_SOLUTION_CONSTRAINT |
系統已在 實驗性:這個欄位的行為或存在狀態日後可能會變更。 |
VEHICLE_ROUTE_IS_FULLY_SEQUENCE_CONSTRAINED |
實驗性:這個欄位的行為或存在狀態日後可能會變更。 |
ZERO_PENALTY_COST |
貨件的違規費用為零。雖然這項進階模型選項很有用,但事後也可能說明為何系統略過某項出貨作業。 實驗性:這個欄位的行為或存在狀態日後可能會變更。 |
TimeWindow
時間範圍會限制事件的時間,例如到訪時間,或是車輛的開始和結束時間。
硬性時間範圍界線 start_time 和 end_time 會強制執行事件的最早和最晚時間,因此 start_time <= event_time <=
end_time。軟性時間範圍下限 soft_start_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` <= `end_time` and
0 <= `start_time` <= `soft_start_time` and
0 <= `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 |
指定執行這項轉換時發生的延遲。 這項延遲一律發生在完成來源造訪後,以及開始目的地造訪前。 |
URI
通用資源 ID,指向可由 Route Optimization API 讀取及寫入的資源。
| 欄位 | |
|---|---|
uri |
資源的 URI。資源可能尚未存在。 資源內容會編碼為 JSON 或 textproto。僅支援 Google Cloud Storage 資源。如果資源是以 JSON 格式編碼,資源名稱的尾碼必須為 |
車輛
此模型會模擬出貨問題中的車輛。解決貨運問題後,系統會為這部車輛建立從 start_location 開始到 end_location 結束的路線。路線是指一連串的拜訪行程 (請參閱ShipmentRoute)。
| 欄位 | |
|---|---|
display_name |
車輛的使用者定義顯示名稱。長度上限為 63 個半形字元,可以使用 UTF-8 字元。 |
travel_mode |
旅行模式會影響車輛可使用的道路和車速。另請參閱 |
route_modifiers |
一組要滿足的條件,會影響特定車輛的路徑計算方式。 |
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 |
可接受的負載量上限。 |
cost_per_kilometer |
這輛車每移動一公里,運送一單位負載的成本。這可做為燃料消耗量的替代指標:如果負載是重量 (以牛頓為單位),則負載*公里具有能量的維度。 實驗功能:詳情請參閱 https://developers.google.com/maps/tt/route-optimization/experimental/load-cost/make-request。 |
cost_per_traveled_hour |
這輛車每小時的單位負重行駛成本。 實驗功能:詳情請參閱 https://developers.google.com/maps/tt/route-optimization/experimental/load-cost/make-request。 |
時間間隔
可接受的載入金額間隔。
| 欄位 | |
|---|---|
min |
|
max |
|
LoadCost
在 Transition 期間移動一個負載單位的費用。特定負載的費用是下列兩部分的總和:
- min(load,
load_threshold) *cost_per_unit_below_threshold - max(0, load -
load_threshold) *cost_per_unit_above_threshold
有了這項成本,解決方案會優先處理高需求,或最後才處理高需求。舉例來說,如果車輛有
load_limit {
key: "weight"
value {
cost_per_kilometer {
load_threshold: 15
cost_per_unit_below_threshold: 2.0
cost_per_unit_above_threshold: 10.0
}
}
}
路線為 start、pickup、pickup、delivery、delivery、end,並包含以下轉換:
transition { vehicle_load['weight'] { amount: 0 }
travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 20 }
travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 0 }
travel_distance_meters: 1000.0 }
則此 LoadCost 產生的費用為 (cost_below * load_below * kilometers + cost_above * load_above * kms)
- 轉場 0:0.0
- 轉場 1:2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
- 轉換 2:2.0 * 15 * 1.0 + 10.0 * (20 - 15) * 1.0 = 80.0
- 轉場 3:2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
- 轉場 4:0.0
因此路線的 LoadCost 為 120.0。
不過,如果路線是「開始、取貨、送貨、取貨、送貨、結束」,且包含轉場效果:
transition { vehicle_load['weight'] { amount: 0 }
travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 0 }
travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 0 }
travel_distance_meters: 1000.0 }
則這項 LoadCost 產生的費用為
- 轉場 0:0.0
- 轉場 1:2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
- 轉換區停留時間 2:0.0
- 轉場 3:2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
- 轉場 4:0.0
這裡的路線LoadCost為 40.0。
LoadCost,導致轉換負載量大的解決方案成本較高。
實驗功能:詳情請參閱 https://developers.google.com/maps/tt/route-optimization/experimental/load-cost/make-request。
| 欄位 | |
|---|---|
load_threshold |
負載量超過此值後,移動單位負載的費用會從 cost_per_unit_below_threshold 變更為 cost_per_unit_above_threshold。必須大於或等於 0。 |
cost_per_unit_below_threshold |
移動一個負載單位的成本,每個單位介於 0 和門檻之間。必須是有限值,且 >= 0。 |
cost_per_unit_above_threshold |
超過門檻的每個負載單位的移動成本。在門檻 = 0 的特殊情況下,這是每單位的固定費用。必須是有限值,且 >= 0。 |
TravelMode
車輛可使用的交通方式。
這些應是 Google 地圖平台 Routes API 交通方式的子集,請參閱:https://developers.google.com/maps/documentation/routes/reference/rest/v2/RouteTravelMode
注意:WALKING 路線目前為 Beta 版,有時可能缺少明確的人行道或行人路徑。您必須在應用程式中顯示的所有步行路線中,向使用者顯示這項警告。
| 列舉 | |
|---|---|
TRAVEL_MODE_UNSPECIFIED |
未指定交通方式,相當於 DRIVING。 |
DRIVING |
與行車路線 (汽車等) 對應的交通方式。 |
WALKING |
步行路線對應的交通方式。 |
UnloadingPolicy
車輛卸貨方式的政策。僅適用於同時有取貨和送貨的貨件。
其他出貨作業可發生在路線上的任何位置,不受 unloading_policy 限制。
| 列舉 | |
|---|---|
UNLOADING_POLICY_UNSPECIFIED |
未指定卸貨政策;送貨時間必須在取貨時間之後。 |
LAST_IN_FIRST_OUT |
交貨順序必須與取貨順序相反 |
FIRST_IN_FIRST_OUT |
送達順序必須與取貨順序相同 |
VehicleFullness
VehicleFullness 是計算車輛裝載量的指標。每個 VehicleFullness 欄位介於 0 和 1 之間,計算方式為上限指標欄位 (例如 AggregatedMetrics.travel_distance_meters) 與相關車輛限制 (例如 Vehicle.route_distance_limit) 之間的比例 (如果有的話)。否則飽和度比率會維持未設定狀態。如果上限為 0,則欄位會設為 1。注意:如果路線因交通狀況而不可行,部分原始滿載率可能會超過 1.0,例如車輛可能超出距離限制。在這些情況下,飽和度值上限為 1.0。
| 欄位 | |
|---|---|
max_fullness |
這則訊息中所有其他欄位的最大值。 |
distance |
|
travel_duration |
[AggregatedMetrics.travel_duration_seconds][] 與 |
active_duration |
[AggregatedMetrics.total_duration_seconds][] 與 |
max_load |
所有類型的 [AggregatedMetrics.max_load][] 和各自 |
active_span |
特定車輛的比例 (vehicle_end_time - vehicle_start_time) / (latest_vehicle_end_time - earliest_vehicle_start_time)。如果沒有分母,則會改用 ( |
途經點
封裝路徑點。途經點會標示 VisitRequest 的抵達和出發地點,以及車輛的起點和終點。
| 欄位 | |
|---|---|
side_of_road |
(選用步驟) 表示這個路線控點的位置偏好車輛停靠在道路的特定一側。設定這個值後,路線會經過該位置,車輛就能在道路中心偏向該位置的一側停靠。這個選項不適用於「步行」交通模式。 |
vehicle_stopover |
指出控點是供車輛停靠,目的是接送乘客。這個選項僅適用於「DRIVING」交通方式,且「location_type」為「location」時。 實驗性:這個欄位的行為或存在狀態日後可能會變更。 |
聯集欄位 location_type。表示位置的不同方式。location_type 只能是下列其中一項: |
|
location |
使用地理座標指定的點,包括選用航向。 |
place_id |
與途中的航點相關聯的 POI 地點 ID。 使用地點 ID 指定 VisitRequest 的抵達或出發地點時,請使用足夠具體的地點 ID,以判斷導航至該地點的 LatLng 位置。舉例來說,代表建築物的地點 ID 適合使用,但代表道路的地點 ID 則不建議。 |