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 wyznaczone dla każdego pojazdu; i-te 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. 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)

Czas trwania, odległość i wskaźniki wykorzystania w tym rozwiązaniu.

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 znajdujące się poniżej 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. Ten proces, podobnie jak w przypadku kompilatora, nie jest idealny. Niektóre błędy weryfikacji są „krytyczne”, co oznacza, że zatrzymują cały proces weryfikacji. Dotyczy to między innymi displayName="UNSPECIFIED" błędów. Niektóre błędy mogą spowodować, że podczas weryfikacji zostaną pominięte inne błędy.

Stabilność: rozwiązania code i displayName powinny być bardzo stabilne. Z czasem mogą jednak pojawiać się nowe kody i wyświetlane nazwy, co może spowodować, że dane (nieprawidłowe) żądanie wygeneruje inną parę (code, displayName), ponieważ nowy błąd ukrył starą. Zobacz np. „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 moc zbioru funkcji 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. Między code a errorMessage występuje mapowanie 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. Nie zawsze jest to możliwe. Nie należy polegać wyłącznie na tym narzędziu i używać go wyłącznie 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 nr 2 w atrybucie startTimeWindows pojazdu nr 5 za pomocą:

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

Pomijamy jednak elementy najwyższego poziomu, takie jak OptimizeToursRequest czy ShipmentModel, aby uniknąć zatłoczenia 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. „pojazdy”.
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 zagregowane na trasach. 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 Vehicle.used_if_route_is_empty ma wartość prawda, pojazd jest uznawany 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 RFC3339 UTC „Zulu” z rozdzielczością nanosekundy i maksymalnie 9 cyframi 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 są ścieżkami proto w odniesieniu do danych wejściowych OptimizeToursRequest, np. „model.shipments.pickups.cost”, a ich wartości to łączny koszt wygenerowany przez odpowiednie pole kosztu, zsumowany dla całego rozwiązania. Inaczej mówiąc, koszt["model.shipments.pickups.cost"] to suma wszystkich kosztów odbioru w ramach danego 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

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