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 obliczone dla każdego pojazdu; i-ta 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. Zobacz wyjaśnienie „WIELE BŁĘDÓW” dotyczące komunikatu |
metrics |
Dane o czasie trwania, odległości i użytkowaniu tego rozwiązania. |
OptimizeToursValidationError
Opisuje błąd lub ostrzeżenie napotkane podczas weryfikowania elementu OptimizeToursRequest
.
Zapis JSON |
---|
{
"code": integer,
"displayName": string,
"fields": [
{
object ( |
Pola | |
---|---|
code |
Błąd weryfikacji jest definiowany przez parę ( Inne pola (poniżej) zawierają więcej informacji o błędzie. WIELU BŁĘDÓW: jeśli wystąpiło wiele błędów, proces weryfikacji próbuje zwrócić kilka z nich. Podobnie jak w przypadku kompilatorów, jest to proces niedoskonały. 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 PRZEDŁOŻENIE: 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 moc zbioru funkcji |
errorMessage |
Zrozumiały dla człowieka ciąg tekstowy opisujący błąd. Wartości 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 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 danego pola w tym pliku i ma taką 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 ( |
Pola | |
---|---|
name |
Nazwa pola, np. „pojazdy”. |
subField |
W razie potrzeby zagnieżdżone pole podrzędne. |
Pole unii
|
|
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. Każde dane to suma (lub wartość maksymalna w przypadku obciążeń) wszystkich pól |
skippedMandatoryShipmentCount |
Liczba pominiętych przesyłek obowiązkowych. |
usedVehicleCount |
Liczba wykorzystywanych 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. |