OptimizeToursResponse

Odpowiedź po rozwiązaniu problemu optymalizacji trasy zawierająca trasy pokonane przez każdy pojazd, pominięte przesyłki i całkowity koszt rozwiązania.

Zapis JSON 
{
  "routes": [
    {
      object (ShipmentRoute)
    }
  ],
  "requestLabel": string,
  "skippedShipments": [
    {
      object (SkippedShipment)
    }
  ],
  "validationErrors": [
    {
      object (OptimizeToursValidationError)
    }
  ],
  "processedRequest": {
    object (OptimizeToursRequest)
  },
  "metrics": {
    object (Metrics)
  }
}
Pola
routes[]

object (ShipmentRoute)

Trasy obliczone dla każdego pojazdu. i-ta trasa odpowiada i-temu pojazdowi w modelu.
requestLabel

string

Kopia OptimizeToursRequest.label, jeśli w żądaniu określono etykietę.
skippedShipments[]

object (SkippedShipment)

Lista wszystkich pominiętych przesyłek.
validationErrors[]

object (OptimizeToursValidationError)

Lista wszystkich błędów weryfikacji, które udało nam się wykryć niezależnie. Wyjaśnienie komunikatu OptimizeToursValidationError znajdziesz w sekcji „MULTIPLE ERRORS”. Zamiast błędów będą tu uwzględniane ostrzeżenia, jeśli solvingMode ma wartość DEFAULT_SOLVE.
processedRequest

object (OptimizeToursRequest)

W niektórych przypadkach modyfikujemy przychodzące żądanie przed jego rozwiązaniem, np. dodając koszty. Jeśli solvingMode == TRANSFORM_AND_RETURN_REQUEST, zmodyfikowane żądanie jest zwracane tutaj.

Eksperymentalne: więcej informacji znajdziesz na stronie https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request.
metrics

object (Metrics)

Czas trwania, odległość i statystyki użytkowania tego rozwiązania.

OptimizeToursValidationError

Opisuje błąd lub ostrzeżenie napotkane podczas weryfikacji OptimizeToursRequest.

Zapis JSON 
{
  "code": integer,
  "displayName": string,
  "fields": [
    {
      object (FieldReference)
    }
  ],
  "errorMessage": string,
  "offendingValues": string
}
Pola
code

integer

Błąd weryfikacji jest określany przez parę (code, displayName), która jest zawsze obecna.

Pola w sekcji poniżej zawierają więcej informacji o błędzie.

MULTIPLE ERRORS: jeśli występuje wiele błędów, proces weryfikacji próbuje wyświetlić kilka z nich. Podobnie jak w przypadku kompilatora jest to proces niedoskonały. Niektóre błędy weryfikacji będą „krytyczne”, co oznacza, że zatrzymają cały proces weryfikacji. Dotyczy to m.in. błędów displayName="UNSPECIFIED". Niektóre błędy mogą powodować pomijanie innych błędów w procesie weryfikacji.

STABILNOŚĆ: wartości code i displayName powinny być bardzo stabilne. Z czasem mogą jednak pojawić się nowe kody i nazwy wyświetlane, co może spowodować, że dane (nieprawidłowe) żądanie zwróci inną parę (code, displayName), ponieważ nowy błąd ukrył stary. Na przykład zobacz sekcję „WIELOKROTNE BŁĘDY”.
displayName

string

Wyświetlana nazwa błędu.
fields[]

object (FieldReference)

Kontekst błędu może obejmować 0, 1 (najczęściej) lub więcej pól. Na przykład odniesienie się do pierwszego odbioru pojazdu 4 i dostawy 2 może wyglądać tak:

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

Pamiętaj jednak, że liczność fields nie powinna się zmieniać w przypadku danego kodu błędu.
errorMessage

string

Zrozumiały dla człowieka ciąg tekstowy opisujący błąd. Istnieje mapowanie 1:1 między code a errorMessage (gdy kod != „UNSPECIFIED”).

STABILNOŚĆ: niestabilna: komunikat o błędzie powiązany z danym code może się z czasem zmienić (mamy nadzieję, że na bardziej zrozumiały). Zamiast tego polegaj na zasadach displayName i code.
offendingValues

string

Może zawierać wartości pól. Nie zawsze jest to możliwe. Nie należy na nim polegać i należy go używać tylko do ręcznego debugowania modelu.

FieldReference

Określa kontekst błędu weryfikacji. FieldReference zawsze odnosi się do danego pola w tym pliku i ma taką samą strukturę hierarchiczną. Na przykład element 2 z startTimeWindows pojazdu 5 możemy określić za pomocą tego kodu:

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

Pomijamy jednak podmioty najwyższego poziomu, takie jak OptimizeToursRequest lub ShipmentModel, aby nie przeładować wiadomości.

Zapis 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.
}
Pola
name

string

Nazwa pola, np. „vehicles”.
subField

object (FieldReference)

W razie potrzeby zagnieżdżone rekurencyjnie pole podrzędne.

Pole zbiorcze index_or_key.

Pole index_or_key może mieć tylko jedną z tych wartości:
index

integer

Indeks pola, jeśli jest powtarzane.
key

string

Klucz, jeśli pole jest mapą.

Dane

Ogólne dane zagregowane ze wszystkich tras.

Zapis JSON 
{
  "aggregatedRouteMetrics": {
    object (AggregatedMetrics)
  },
  "skippedMandatoryShipmentCount": integer,
  "usedVehicleCount": integer,
  "earliestVehicleStartTime": string,
  "latestVehicleEndTime": string,
  "costs": {
    string: number,
    ...
  },
  "totalCost": number
}
Pola
aggregatedRouteMetrics

object (AggregatedMetrics)

Zagregowane na trasach. Każda wartość to suma (lub maksymalna wartość w przypadku wczytań) wszystkich pól ShipmentRoute.metrics o tej samej nazwie.
skippedMandatoryShipmentCount

integer

Liczba pominiętych obowiązkowych przesyłek.
usedVehicleCount

integer

Liczba używanych pojazdów. Uwaga: jeśli trasa pojazdu jest pusta, a wartość Vehicle.used_if_route_is_empty to „prawda”, pojazd jest uznawany za używany.
earliestVehicleStartTime

string (Timestamp format)

Najwcześniejszy czas rozpoczęcia dla pojazdu używanego, obliczony jako minimum ze wszystkich pojazdów używanych ShipmentRoute.vehicle_start_time.

Korzysta ze standardu RFC 3339, w którym wygenerowane dane wyjściowe są zawsze znormalizowane do formatu Z i zawierają 0, 3, 6 lub 9 cyfr po przecinku. Akceptowane są też przesunięcia inne niż „Z”. Przykłady: "2014-10-02T15:01:23Z", "2014-10-02T15:01:23.045123456Z" lub "2014-10-02T15:01:23+05:30".
latestVehicleEndTime

string (Timestamp format)

Najpóźniejsza godzina zakończenia dla używanego pojazdu, obliczona jako maksimum ze wszystkich używanych pojazdów ShipmentRoute.vehicle_end_time.

Korzysta ze standardu RFC 3339, w którym wygenerowane dane wyjściowe są zawsze znormalizowane do formatu Z i zawierają 0, 3, 6 lub 9 cyfr po przecinku. Akceptowane są też przesunięcia inne niż „Z”. Przykłady: "2014-10-02T15:01:23Z", "2014-10-02T15:01:23.045123456Z" lub "2014-10-02T15:01:23+05:30".
costs

map (key: string, value: number)

Koszt rozwiązania podzielony według pól żądań związanych z kosztami. Kluczami są ścieżki protokołu, względne w stosunku do wejściowego OptimizeToursRequest, np. „model.shipments.pickups.cost”, a wartościami są łączne koszty wygenerowane przez odpowiednie pole kosztu, zagregowane w całym rozwiązaniu. Inaczej mówiąc, costs["model.shipments.pickups.cost"] to suma wszystkich kosztów odbioru w ramach rozwiązania. Wszystkie koszty zdefiniowane w modelu są tu szczegółowo raportowane, z wyjątkiem kosztów związanych z atrybutami przejścia, które od 2022 r. są raportowane tylko w formie zagregowanej.
totalCost

number

Całkowity koszt rozwiązania. Suma wszystkich wartości na mapie kosztów.