OptimizeToursResponse

Odpowiedź po rozwiązaniu problemu optymalizacji trasy zawierająca trasy przebyte przez każdy pojazd, przesyłki, które zostały pominięte, oraz łączny koszt rozwiązania.

Zapis JSON 
{
  "routes": [
    {
      object (ShipmentRoute)
    }
  ],
  "requestLabel": string,
  "skippedShipments": [
    {
      object (SkippedShipment)
    }
  ],
  "validationErrors": [
    {
      object (OptimizeToursValidationError)
    }
  ],
  "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 podano 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ć. Więcej informacji o komunikacie OptimizeToursValidationError znajdziesz w sekcji „WIELE BŁĘDÓW”. W przypadku wartości solvingMode DEFAULT_SOLVE zamiast błędów będą wyświetlane ostrzeżenia.
metrics

object (Metrics)

Dane o czasie trwania, odległości i użytkowaniu tego rozwiązania.

OptimizeToursValidationError

Opisuje błąd lub ostrzeżenie występujące podczas sprawdzania OptimizeToursRequest.

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

integer

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

Pola w sekcji po tej sekcji zawierają więcej informacji o błędzie.

WIELE BŁĘDÓW: gdy występuje wiele błędów, proces weryfikacji próbuje wygenerować kilka z nich. Podobnie jak w przypadku kompilatorów, 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ą spowodować pominięcie innych błędów podczas procesu weryfikacji.

STABILNOŚĆ: code i displayName powinny być bardzo stabilne. Z czasem mogą jednak pojawić się nowe kody i nazwy wyświetlania, co może spowodować, że dana (nieprawidłowa) prośba zwróci inną parę (code, displayName), ponieważ nowy błąd zastąpi stary. Przykład: „WIELE BŁĘDÓW”.
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 pierwszy odbiór pojazdu 4 w ramach dostawy 2 można wykonać w ten sposób:

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

Pamiętaj jednak, że liczba elementów 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. Wartości code i errorMessage są ze sobą powiązane 1:1 (gdy kod != „UNSPECIFIED”).

STAŁOŚĆ: niestabilna: komunikat o błędzie powiązany z danym code może z czasem ulec zmianie (miejmy nadzieję, że na lepsze). Zamiast tego użyj zasad displayName i code.
offendingValues

string

Może zawierać wartości pól. Ta opcja nie jest zawsze dostępna. Nie należy się na niego w żaden sposób opierać. Należy go używać tylko do ręcznego debugowania modelu.

FieldReference

Określa kontekst błędu weryfikacji. FieldReference zawsze odnosi się do określonego pola w tym pliku i podąża za tą samą strukturą hierarchiczną. Możemy na przykład określić element 2 w elementach startTimeWindows pojazdu 5 za pomocą:

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

Jednak pomijamy elementy najwyższego poziomu, takie jak OptimizeToursRequest lub ShipmentModel, aby nie zaśmiecać 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 rekurencyjnie zagnieżdżone podpole.

Pole unii index_or_key.

index_or_key może być tylko jednym z tych elementów:
index

integer

Indeks pola, jeśli jest powtarzany.
key

string

klucz, jeśli pole jest mapą;

Dane

Ogólne dane, zagregowane na podstawie 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 dotyczące tras. Każde dane to suma (lub wartość maksymalna w przypadku obciążeń) wszystkich pól ShipmentRoute.metrics o tej samej nazwie.
skippedMandatoryShipmentCount

integer

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

integer

Liczba używanych pojazdów. Uwaga: jeśli trasa pojazdu jest pusta, a wartość atrybutu Vehicle.used_if_route_is_empty to Prawda, pojazd jest uważany za używany.
earliestVehicleStartTime

string (Timestamp format)

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

Sygnatura czasowa w formacie UTC „Zulu” zdefiniowanym w dokumencie RFC 3339, z dokładnością do nanosekund i maksymalnie 9 miejsc po przecinku. Przykłady: "2014-10-02T15:01:23Z" i "2014-10-02T15:01:23.045123456Z".
latestVehicleEndTime

string (Timestamp format)

Najpóźniejszy czas zakończenia dla używanego pojazdu, obliczony jako maksymalny dla wszystkich używanych pojazdów ShipmentRoute.vehicle_end_time.

Sygnatura czasowa w formacie UTC „Zulu” zdefiniowanym w dokumencie RFC 3339, z dokładnością do nanosekund i maksymalnie 9 miejsc po przecinku. Przykłady: "2014-10-02T15:01:23Z" i "2014-10-02T15:01:23.045123456Z".
costs

map (key: string, value: number)

Koszt rozwiązania z podziałem według pól żądania związanych z kosztami. Klucze to ścieżki proto, odnoszące się do wejścia OptimizeToursRequest, np. „model.shipments.pickups.cost”, a wartości to łączny koszt wygenerowany przez odpowiednie pole kosztu, zsumowany 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ą tutaj szczegółowo raportowane, z wyjątkiem kosztów związanych z atributem TransitionAttributes, które od 1 stycznia 2022 r. są raportowane tylko w sposób zagregowany.
totalCost

number

Łączny koszt rozwiązania. Suma wszystkich wartości w mapie kosztów.