Odpowiedź po rozwiązaniu problemu z optymalizacją wycieczki, który obejmuje trasy, po których poruszają się poszczególne pojazdy, przesyłki, które zostały pominięte, oraz ogólny koszt rozwiązania.
Zapis JSON |
---|
{ "routes": [ { object ( |
Pola | |
---|---|
routes[] |
Trasy obliczane dla każdego pojazdu; i-ta trasa odpowiada i-tego 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. Zapoznaj się z wyjaśnieniem „WIELE BŁĘDÓW” dla komunikatu |
metrics |
Dane dotyczące czasu trwania, odległości i wykorzystania dla tego rozwiązania. |
OptimizeToursValidationError
Opisuje błąd, który wystąpił podczas weryfikacji elementu OptimizeToursRequest
.
Zapis JSON |
---|
{
"code": integer,
"displayName": string,
"fields": [
{
object ( |
Pola | |
---|---|
code |
Błąd weryfikacji jest definiowany przez parę ( W pozostałych polach (poniżej) znajdziesz więcej informacji o błędzie. WIELE BŁĘDÓW: jeśli błędów jest wiele, proces weryfikacji próbuje wyświetlić kilka z nich. Ten proces nie jest doskonały, podobnie jak kompilator. Niektóre błędy weryfikacji będą „krytyczne”, co oznacza, że zatrzymują cały proces weryfikacji. Dotyczy to między innymi błędów Stabilność: REFERENCE: lista wszystkich par (kodu, nazwy):
|
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 w przypadku pojazdu nr 4 i pierwszego odbioru przesyłki nr 2 można:
Pamiętaj jednak, że moc zbioru |
errorMessage |
Zrozumiały dla człowieka ciąg tekstowy opisujący błąd. Między stabilność: niestabilny: komunikat o błędzie powiązany z danym elementem |
offendingValues |
Może zawierać wartości pól. Ta funkcja nie zawsze jest dostępna. Zdecydowanie nie należy na niej polegać i służy ona wyłącznie do ręcznego debugowania modelu. |
FieldReference
Określa kontekst błędu weryfikacji. Pole FieldReference
zawsze odwołuje się do danego pola w tym pliku i ma taką samą strukturę hierarchiczną. Na przykład możemy określić element nr 2 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 ( |
Pola | |
---|---|
name |
Nazwa pola, np. „pojazdy”. |
subField |
W razie potrzeby rekurencyjnie zagnieżdżone pole podrzędne. |
Pole sumy
|
|
index |
Indeks pola, jeśli się powtarza. |
key |
Klucz, jeśli pole jest mapą. |
Wskaźniki
Wskaźniki ogólne, zagregowane dla wszystkich tras.
Zapis JSON |
---|
{
"aggregatedRouteMetrics": {
object ( |
Pola | |
---|---|
aggregatedRouteMetrics |
Dane zbiorcze po trasach. Poszczególne dane to suma (lub maksymalna w przypadku obciążeń) wszystkich pól |
skippedMandatoryShipmentCount |
Liczba pominiętych obowiązkowych dostaw. |
usedVehicleCount |
Liczba używanych pojazdów. Uwaga: jeśli trasa pojazdu jest pusta, a zasada |
earliestVehicleStartTime |
Najwcześniejsza godzina rozpoczęcia użytkowania używanego pojazdu, obliczona jako minimalna wartość dla wszystkich używanych pojazdów z Sygnatura czasowa w formacie „Zulu” RFC3339 UTC z rozdzielczością nanosekundową i maksymalnie 9 cyframi po przecinku. Przykłady: |
latestVehicleEndTime |
Ostatni czas zakończenia użytkowania używanego pojazdu obliczony jako maksymalny czas zakończenia obsługi wszystkich używanych pojazdów w okresie Sygnatura czasowa w formacie „Zulu” RFC3339 UTC z rozdzielczością nanosekundową i maksymalnie 9 cyframi po przecinku. Przykłady: |
costs |
Koszt rozwiązania z podziałem na pola żądań związane z kosztami. Klucze to ścieżki proto powiązane z danymi wejściowymi OptimizeToursRequest, np. „model.shipments.pickups.cost”, a wartościami są łączny koszt wygenerowany przez odpowiednie pole kosztu, zagregowany dla całego rozwiązania. Inaczej mówiąc, koszt["model.shipments.pickups.cost"] to suma wszystkich kosztów odbioru w stosunku do rozwiązania. Wszystkie koszty zdefiniowane w modelu są raportowane tutaj szczegółowo z wyjątkiem kosztów związanych z atrybutami przejścia, które od 2022 r. są raportowane tylko w postaci zbiorczej. Obiekt zawierający listę par |
totalCost |
Całkowity koszt rozwiązania. Suma wszystkich wartości na mapie kosztów. |