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 ( |
| Pola | |
|---|---|
routes[] |
Trasy wyznaczone dla każdego pojazdu; i-te trasa odpowiada i-temu pojazdowi w modelu. |
requestLabel |
Kopia |
skippedShipments[] |
Lista wszystkich pominiętych przesyłek. |
validationErrors[] |
Lista wszystkich błędów weryfikacji, które udało nam się wykryć niezależnie. Więcej informacji o komunikacie |
metrics |
Dane o czasie trwania, odległości i użytkowaniu tego rozwiązania. |
OptimizeToursValidationError
Opisuje błąd, który wystąpił podczas weryfikowania elementu OptimizeToursRequest.
| Zapis JSON |
|---|
{
"code": integer,
"displayName": string,
"fields": [
{
object ( |
| Pola | |
|---|---|
code |
Błąd weryfikacji jest definiowany przez parę ( Pozostałe pola (poniżej) 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 powodują zatrzymanie całego procesu weryfikacji. Dotyczy to m.in. błędów Stabilność: rozwiązania REFERENCYJNE: lista wszystkich par (kod, nazwa):
|
displayName |
Wyświetlana nazwa błędu. |
fields[] |
Kontekst błędu może mieć wartość 0, 1 (w większości przypadków) lub większą liczbę pól. Na przykład pierwszy odbiór pojazdu 4 w ramach dostawy 2 można wykonać w ten sposób: Pamiętaj jednak, że liczba elementów |
errorMessage |
Zrozumiały dla człowieka ciąg tekstowy opisujący błąd. Między STAŁOŚĆ: niestabilna: komunikat o błędzie powiązany z danym |
offendingValues |
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 danego pola w tym pliku i ma taką 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 }
Jednak pomijamy elementy najwyższego poziomu, takie jak OptimizeToursRequest lub ShipmentModel, aby nie zaśmiecać wiadomości.
| Zapis JSON |
|---|
{ "name": string, "subField": { object ( |
| Pola | |
|---|---|
name |
Nazwa pola, np. „pojazdy”. |
subField |
W razie potrzeby zagnieżdżone pole podrzędne. |
Pole sumy
|
|
index |
Indeks pola, jeśli jest powtarzany. |
key |
klucz, jeśli pole jest mapą; |
Dane
Zbiorcze wskaźniki, zagregowane dla wszystkich tras.
| Zapis JSON |
|---|
{
"aggregatedRouteMetrics": {
object ( |
| Pola | |
|---|---|
aggregatedRouteMetrics |
Dane zagregowane na trasach. Poszczególne dane to suma (lub maksimum, w przypadku obciążeń) we wszystkich polach |
skippedMandatoryShipmentCount |
Liczba pominiętych przesyłek obowiązkowych. |
usedVehicleCount |
Liczba używanych pojazdów. Uwaga: jeśli trasa pojazdu jest pusta, a |
earliestVehicleStartTime |
Najwcześniejszy czas uruchomienia używanego pojazdu, obliczany jako minimum dla wszystkich używanych pojazdów w okresie 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: |
latestVehicleEndTime |
Najpóźniejszy czas zakończenia dla używanego pojazdu, obliczony jako maksymalny dla wszystkich używanych pojazdów 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: |
costs |
Koszt rozwiązania z podziałem na pola żądania związane 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, 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. Obiekt zawierający listę par |
totalCost |
Całkowity koszt rozwiązania. Suma wszystkich wartości na mapie kosztów. |