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 wyświetlane ostrzeżenia, jeśli w przypadku solvingMode wartość to DEFAULT_SOLVE.
processedRequest

object (OptimizeToursRequest)

W niektórych przypadkach przed rozwiązaniem problemu modyfikujemy przychodzące zgłoszenie, 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)

Dane dotyczące czasu trwania, odległości i użycia tego rozwiązania.

OptimizeToursValidationError

Opisuje błąd lub ostrzeżenie napotkane podczas sprawdzania poprawności OptimizeToursRequest.

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

integer

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

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

WIĘCEJ BŁĘDÓW: jeśli występuje więcej 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 spowodują przerwanie całego procesu 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 wyświetlane nazwy, co może spowodować, że dane (nieprawidłowe) żądanie zwróci inną parę (code, displayName), ponieważ nowy błąd ukryje stary. Przykład znajdziesz w sekcji „MULTIPLE ERRORS” (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ŚĆ: niestabilny: komunikat o błędzie powiązany z danym code może się z czasem zmienić (mamy nadzieję, że na bardziej zrozumiały). Zamiast niej używaj zasad 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ą. Możemy na przykład określić element 2 z startTimeWindows pojazdu 5 za pomocą tego kodu:

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

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

Zapis JSON 
{
  "name": string,
  "subField": {
    object (FieldReference)
  },

  // The following is a list of mutually exclusive fields. At most one of the
  // fields will be set in a response:
  "index": integer,
  "key": string
  // End of mutually exclusive fields.
}
Pola
name

string

Nazwa pola, np. „vehicles”.
subField

object (FieldReference)

W razie potrzeby pole podrzędne zagnieżdżone rekurencyjnie.
Poniżej znajduje się lista pól, które się wzajemnie wykluczają. W odpowiedzi zostanie ustawione co najwyżej jedno z tych pól:
index

integer

Indeks pola, jeśli jest powtarzane.
key

string

Klucz, jeśli pole jest mapą.
Koniec pól wykluczających się nawzajem.

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)

Dane zbiorcze z tras. Każda wartość to suma (lub maksymalna wartość w przypadku obciążeń) wszystkich pól ShipmentRoute.metrics o tej samej nazwie.
skippedMandatoryShipmentCount

integer

Liczba pominiętych obowiązkowych dostaw.
usedVehicleCount

integer

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

string (Timestamp format)

Najwcześniejszy czas rozpoczęcia dla używanego pojazdu, obliczony jako minimum ze wszystkich używanych pojazdów 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 żądania związanych z kosztami. Kluczami są ścieżki proto, 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ą szczegółowo podane w tym miejscu, z wyjątkiem kosztów związanych z atrybutami przejścia, które od 2022 r. są podawane tylko w formie zagregowanej.
totalCost

number

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