OptimizeToursResponse

Phản hồi sau khi giải quyết vấn đề tối ưu hoá hành trình, bao gồm các tuyến đường mà mỗi xe đã đi, các lô hàng đã bị bỏ qua và tổng chi phí của giải pháp.

Biểu diễn dưới dạng JSON 
{
  "routes": [
    {
      object (ShipmentRoute)
    }
  ],
  "requestLabel": string,
  "skippedShipments": [
    {
      object (SkippedShipment)
    }
  ],
  "validationErrors": [
    {
      object (OptimizeToursValidationError)
    }
  ],
  "processedRequest": {
    object (OptimizeToursRequest)
  },
  "metrics": {
    object (Metrics)
  }
}
Trường
routes[]

object (ShipmentRoute)

Các tuyến đường được tính toán cho từng xe; tuyến đường thứ i tương ứng với xe thứ i trong mô hình.
requestLabel

string

Bản sao của OptimizeToursRequest.label, nếu bạn đã chỉ định một nhãn trong yêu cầu.
skippedShipments[]

object (SkippedShipment)

Danh sách tất cả các lô hàng bị bỏ qua.
validationErrors[]

object (OptimizeToursValidationError)

Danh sách tất cả các lỗi xác thực mà chúng tôi có thể phát hiện một cách độc lập. Xem phần giải thích "NHIỀU LỖI" cho thông báo OptimizeToursValidationError. Thay vì lỗi, trường hợp này sẽ bao gồm cả cảnh báo nếu solvingMode là DEFAULT_SOLVE.
processedRequest

object (OptimizeToursRequest)

Trong một số trường hợp, chúng tôi sửa đổi yêu cầu nhận được trước khi giải quyết, tức là thêm chi phí. Nếu solvingMode == TRANSFORM_AND_RETURN_REQUEST, thì yêu cầu đã sửa đổi sẽ được trả về tại đây.

Thử nghiệm: Xem https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request để biết thêm thông tin chi tiết.
metrics

object (Metrics)

Thời lượng, khoảng cách và chỉ số sử dụng cho giải pháp này.

OptimizeToursValidationError

Mô tả lỗi hoặc cảnh báo gặp phải khi xác thực một OptimizeToursRequest.

Biểu diễn dưới dạng JSON 
{
  "code": integer,
  "displayName": string,
  "fields": [
    {
      object (FieldReference)
    }
  ],
  "errorMessage": string,
  "offendingValues": string
}
Trường
code

integer

Lỗi xác thực được xác định bằng cặp (code, displayName) luôn xuất hiện.

Các trường sau phần này cung cấp thêm bối cảnh về lỗi.

NHIỀU LỖI: Khi có nhiều lỗi, quy trình xác thực sẽ cố gắng xuất một số lỗi trong số đó. Giống như trình biên dịch, đây là một quy trình không hoàn hảo. Một số lỗi xác thực sẽ là "nghiêm trọng", tức là những lỗi này sẽ dừng toàn bộ quy trình xác thực. Đây là trường hợp đối với lỗi displayName="UNSPECIFIED", trong số những lỗi khác. Một số lỗi có thể khiến quy trình xác thực bỏ qua các lỗi khác.

TÍNH ỔN ĐỊNH: code và displayName phải rất ổn định. Tuy nhiên, mã và tên hiển thị mới có thể xuất hiện theo thời gian, điều này có thể khiến một yêu cầu nhất định (không hợp lệ) tạo ra một cặp (code, displayName) khác vì lỗi mới đã ẩn lỗi cũ. Ví dụ: xem "NHIỀU LỖI".
displayName

string

Tên hiển thị của lỗi.
fields[]

object (FieldReference)

Bối cảnh lỗi có thể liên quan đến 0, 1 (hầu hết thời gian) hoặc nhiều trường. Ví dụ: bạn có thể tham khảo lần nhận hàng đầu tiên của xe số 4 và lô hàng số 2 như sau:

fields { name: "vehicles" index: 4}
fields { name: "shipments" index: 2 subField {name: "pickups" index: 0} }

Tuy nhiên, lưu ý rằng số lượng fields không được thay đổi đối với một mã lỗi nhất định.
errorMessage

string

Chuỗi ký tự mà con người đọc được, dùng để mô tả lỗi. Có mối liên kết 1:1 giữa code và errorMessage (khi mã != "UNSPECIFIED").

ĐỘ ỔN ĐỊNH: Không ổn định: thông báo lỗi liên kết với một code nhất định có thể thay đổi (hy vọng là để làm rõ) theo thời gian. Thay vào đó, vui lòng dựa vào displayName và code.
offendingValues

string

Có thể chứa(các) giá trị của(các) trường. Tính năng này không phải lúc nào cũng có sẵn. Bạn tuyệt đối không nên dựa vào thông tin này và chỉ sử dụng cho mục đích gỡ lỗi mô hình theo cách thủ công.

FieldReference

Chỉ định một bối cảnh cho lỗi xác thực. FieldReference luôn đề cập đến một trường nhất định trong tệp này và tuân theo cùng một cấu trúc phân cấp. Ví dụ: chúng ta có thể chỉ định phần tử số 2 của startTimeWindows của xe số 5 bằng cách sử dụng:

name: "vehicles" index: 5 subField { name: "endTimeWindows" index: 2 }

Tuy nhiên, chúng tôi sẽ bỏ qua các thực thể cấp cao nhất như OptimizeToursRequest hoặc ShipmentModel để tránh làm thông báo trở nên rối rắm.

Biểu diễn dưới dạng JSON 
{
  "name": string,
  "subField": {
    object (FieldReference)
  },

  // Union field index_or_key can be only one of the following:
  "index": integer,
  "key": string
  // End of list of possible types for union field index_or_key.
}
Trường
name

string

Tên của trường, ví dụ: "vehicles".
subField

object (FieldReference)

Trường con lồng nhau đệ quy (nếu cần).

Trường nhóm index_or_key.

index_or_key chỉ có thể là một trong những trạng thái sau:
index

integer

Chỉ mục của trường nếu được lặp lại.
key

string

Khoá nếu trường là một bản đồ.

Chỉ số

Các chỉ số tổng thể, được tổng hợp trên tất cả các tuyến đường.

Biểu diễn dưới dạng JSON 
{
  "aggregatedRouteMetrics": {
    object (AggregatedMetrics)
  },
  "skippedMandatoryShipmentCount": integer,
  "usedVehicleCount": integer,
  "earliestVehicleStartTime": string,
  "latestVehicleEndTime": string,
  "costs": {
    string: number,
    ...
  },
  "totalCost": number
}
Trường
aggregatedRouteMetrics

object (AggregatedMetrics)

Dữ liệu được tổng hợp trên các tuyến đường. Mỗi chỉ số là tổng (hoặc tối đa, đối với tải) trên tất cả các trường ShipmentRoute.metrics có cùng tên.
skippedMandatoryShipmentCount

integer

Số lượng lô hàng bắt buộc bị bỏ qua.
usedVehicleCount

integer

Số lượng xe được sử dụng. Lưu ý: nếu tuyến đường của xe trống và Vehicle.used_if_route_is_empty là true, thì xe được coi là đã qua sử dụng.
earliestVehicleStartTime

string (Timestamp format)

Thời gian bắt đầu sớm nhất cho một chiếc xe đã qua sử dụng, được tính là thời gian tối thiểu của tất cả các xe đã qua sử dụng là ShipmentRoute.vehicle_start_time.

Hãy dùng RFC 3339, trong đó dữ liệu đầu ra được tạo sẽ luôn được chuẩn hoá theo múi giờ và sử dụng 0, 3, 6 hoặc 9 chữ số thập phân. Các khoảng lệch khác ngoài "Z" cũng được chấp nhận. Ví dụ: "2014-10-02T15:01:23Z", "2014-10-02T15:01:23.045123456Z" hoặc "2014-10-02T15:01:23+05:30".
latestVehicleEndTime

string (Timestamp format)

Thời gian kết thúc mới nhất cho một chiếc xe đã qua sử dụng, được tính là thời gian tối đa của tất cả các xe đã qua sử dụng của ShipmentRoute.vehicle_end_time.

Hãy dùng RFC 3339, trong đó dữ liệu đầu ra được tạo sẽ luôn được chuẩn hoá theo múi giờ và sử dụng 0, 3, 6 hoặc 9 chữ số thập phân. Các khoảng lệch khác ngoài "Z" cũng được chấp nhận. Ví dụ: "2014-10-02T15:01:23Z", "2014-10-02T15:01:23.045123456Z" hoặc "2014-10-02T15:01:23+05:30".
costs

map (key: string, value: number)

Chi phí của giải pháp, được chia nhỏ theo các trường yêu cầu liên quan đến chi phí. Khoá là đường dẫn proto, tương ứng với OptimizeToursRequest đầu vào, ví dụ: "model.shipments.pickups.cost" và giá trị là tổng chi phí do trường chi phí tương ứng tạo ra, được tổng hợp trên toàn bộ giải pháp. Nói cách khác, costs["model.shipments.pickups.cost"] là tổng của tất cả chi phí lấy hàng trong giải pháp. Tất cả chi phí được xác định trong mô hình đều được báo cáo chi tiết tại đây, ngoại trừ chi phí liên quan đến TransitionAttributes (Thuộc tính chuyển đổi) chỉ được báo cáo theo cách tổng hợp kể từ ngày 1/1/2022.
totalCost

number

Tổng chi phí của giải pháp. Tổng của tất cả các giá trị trong bản đồ chi phí.