Indeks
RouteOptimization
(interfejs)AggregatedMetrics
(komunikat)BatchOptimizeToursMetadata
(komunikat)BatchOptimizeToursRequest
(komunikat)BatchOptimizeToursRequest.AsyncModelConfig
(komunikat)BatchOptimizeToursResponse
(komunikat)BreakRule
(komunikat)BreakRule.BreakRequest
(komunikat)BreakRule.FrequencyConstraint
(komunikat)DataFormat
(wyliczenie)DistanceLimit
(komunikat)GcsDestination
(komunikat)GcsSource
(komunikat)InjectedSolutionConstraint
(komunikat)InjectedSolutionConstraint.ConstraintRelaxation
(komunikat)InjectedSolutionConstraint.ConstraintRelaxation.Relaxation
(komunikat)InjectedSolutionConstraint.ConstraintRelaxation.Relaxation.Level
(wyliczenie)InputConfig
(komunikat)Location
(komunikat)OptimizeToursRequest
(komunikat)OptimizeToursRequest.SearchMode
(wyliczenie)OptimizeToursRequest.SolvingMode
(wyliczenie)OptimizeToursResponse
(komunikat)OptimizeToursResponse.Metrics
(komunikat)OptimizeToursValidationError
(komunikat)OptimizeToursValidationError.FieldReference
(komunikat)OutputConfig
(komunikat)RouteModifiers
(komunikat)Shipment
(komunikat)Shipment.Load
(komunikat)Shipment.VisitRequest
(komunikat)ShipmentModel
(komunikat)ShipmentModel.DurationDistanceMatrix
(komunikat)ShipmentModel.DurationDistanceMatrix.Row
(komunikat)ShipmentModel.PrecedenceRule
(komunikat)ShipmentRoute
(komunikat)ShipmentRoute.Break
(komunikat)ShipmentRoute.EncodedPolyline
(komunikat)ShipmentRoute.Transition
(komunikat)ShipmentRoute.VehicleLoad
(komunikat)ShipmentRoute.Visit
(komunikat)ShipmentTypeIncompatibility
(komunikat)ShipmentTypeIncompatibility.IncompatibilityMode
(wyliczenie)ShipmentTypeRequirement
(komunikat)ShipmentTypeRequirement.RequirementMode
(wyliczenie)SkippedShipment
(komunikat)SkippedShipment.Reason
(komunikat)SkippedShipment.Reason.Code
(wyliczenie)TimeWindow
(komunikat)TransitionAttributes
(komunikat)Vehicle
(komunikat)Vehicle.DurationLimit
(komunikat)Vehicle.LoadLimit
(komunikat)Vehicle.LoadLimit.Interval
(komunikat)Vehicle.TravelMode
(wyliczenie)Vehicle.UnloadingPolicy
(wyliczenie)Waypoint
(komunikat)
RouteOptimization
Usługa optymalizacji trasy pojazdu.
Ważność niektórych typów pól:
google.protobuf.Timestamp
- Czas jest podany w czasie uniksowym: sekundy od 1970-01-01T00:00:00+00:00.
- sekundy musi zawierać się w przedziale [0, 253402300799], czyli w przedziale [1970-01-01T00:00:00+00:00, 9999-12-31T23:59:59+00:00].
- nanos musi być nieustawiony lub ustawiony na 0.
google.protobuf.Duration
- sekundy musi mieścić się w przedziale [0, 253402300799], czyli w przedziale [1970-01-01T00:00:00+00:00, 9999-12-31T23:59:59+00:00].
- nanos musi być ustawiony na wartość nieokreślona lub 0.
google.type.LatLng
- Szerokość geograficzna musi mieścić się w zakresie [-90,0, 90,0].
- Długość geograficzna musi mieścić się w przedziale [-180,0, 180,0].
- co najmniej jedna z szerokości i długości geograficznej musi być różna od 0;
BatchOptimizeTours |
---|
Optymalizuje wycieczki po pojeździe w przypadku co najmniej 1 wiadomości Ta metoda jest długotrwałą operacją (LRO). Dane wejściowe służące do optymalizacji (wiadomości Użytkownik może wysłać zapytanie Jeśli pole LRO Jeśli pole
|
OptimizeTours |
---|
Wysyła Model Celem jest przypisanie
|
AggregatedMetrics
Dane zbiorcze dotyczące ShipmentRoute
(odpowiednio OptimizeToursResponse
dla wszystkich elementów Transition
lub Visit
(odpowiednio dla wszystkich elementów ShipmentRoute
).
Pola | |
---|---|
performed_ |
Liczba zrealizowanych przesyłek. Pamiętaj, że para „odbiór” i „dostawa” jest liczona tylko raz. |
travel_ |
Łączny czas podróży na danej trasie lub w ramach danego rozwiązania. |
wait_ |
Łączny czas oczekiwania na trasę lub rozwiązanie. |
delay_ |
Łączny czas opóźnienia na trasie lub w rozwiązaniu. |
break_ |
Łączny czas przerwy na trasie lub w rozwiązaniu. |
visit_ |
Łączny czas trwania wizyty na trasie lub w ramach rozwiązania. |
total_ |
Łączny czas trwania powinien być równy sumie wszystkich czasów trwania powyżej. W przypadku tras odpowiada ona też:
|
travel_ |
Całkowita odległość do przebycia na trasie lub w ramach rozwiązania. |
max_ |
Maksymalne obciążenie osiągnięte na całej trasie (odpowiednio: w rozwiązaniu) dla każdej ilości na tej trasie (odpowiednio: w rozwiązaniu) obliczone jako maksimum wszystkich |
BatchOptimizeToursMetadata
Ten typ nie ma pól.
Metadane operacji dla wywołań BatchOptimizeToursRequest
.
BatchOptimizeToursRequest
Przesyłanie żądania zbiorczej optymalizacji tras jako operacji asynchronicznej. Każdy plik wejściowy powinien zawierać 1 plik OptimizeToursRequest
, a każdy plik wyjściowy – 1 plik OptimizeToursResponse
. Żądanie zawiera informacje potrzebne do odczytania, zapisania i przeanalizowania plików. Wszystkie pliki wejściowe i wyjściowe powinny znajdować się w tym samym projekcie.
Pola | |
---|---|
parent |
Wymagane. Wybierz projekt i lokalizację, aby wykonać połączenie. Format: * Jeśli nie określisz lokalizacji, region zostanie wybrany automatycznie. |
model_ |
Wymagane. Informacje wejściowe/wyjściowe dotyczące każdego modelu zakupu, takie jak ścieżki plików i formaty danych. |
AsyncModelConfig
Informacje potrzebne do asynchronicznego rozwiązywania jednego modelu optymalizacji.
Pola | |
---|---|
display_ |
Opcjonalnie: Nazwa modelu zdefiniowana przez użytkownika, która może być używana jako alias do śledzenia modeli. |
input_ |
Wymagane. Informacje o modelu wejściowym. |
output_ |
Wymagane. Informacje o chcianej lokalizacji wyjściowej. |
BatchOptimizeToursResponse
Ten typ nie ma pól.
Odpowiedź na BatchOptimizeToursRequest
. Zwracany jest on w operacji długotrwałej po jej zakończeniu.
BreakRule
Reguły generowania przerw czasowych dla pojazdu (np. przerwa na lunch). Przerwa to ciągły okres czasu, w którym pojazd pozostaje w swojej bieżącej pozycji i nie może wykonywać żadnych wizyt. Przerwa może wystąpić:
- podczas przemieszczania się między 2 wizytami (co obejmuje czas bezpośrednio przed wizytą lub bezpośrednio po niej, ale nie w jej trakcie), w którym przypadku wydłuża się czas przemieszczania się między wizytami,
- lub przed uruchomieniem pojazdu (samochód nie może się uruchomić w trakcie przerwy), w którym to przypadku nie wpływa na czas uruchomienia pojazdu.
- lub po zakończeniu korzystania z pojazdu (w tym przypadku również podaj godzinę zakończenia korzystania z pojazdu).
Pola | |
---|---|
break_ |
Sekwencja przerw. Zobacz wiadomość |
frequency_ |
Mogą obowiązywać różne |
BreakRequest
Sekwencja przerw (czyli ich liczba i kolejność) obowiązująca w przypadku każdego pojazdu musi być znana z wyprzedzeniem. Powtarzające się BreakRequest
definiują tę sekwencję w kolejności, w jakiej muszą wystąpić. Okna czasowe (earliest_start_time
/ latest_start_time
) mogą się na siebie nakładać, ale muszą być zgodne z kolejnością (jest to sprawdzane).
Pola | |
---|---|
earliest_ |
Wymagane. Dolna granica (włącznie) na początku przerwy. |
latest_ |
Wymagane. Górna granica (włącznie) na początku przerwy. |
min_ |
Wymagane. Minimalny czas trwania przerwy. Musi być dodatni. |
FrequencyConstraint
Można też dodatkowo ograniczyć częstotliwość i czas trwania przerw określonych powyżej, narzucając minimalną częstotliwość przerwy, np. „Co 12 godzin musi być przerwa trwająca co najmniej 1 godzinę”. Zakładając, że można to interpretować jako „W dowolnym przesuwającym się oknie czasowym o długości 12 godzin musi być co najmniej 1 przerwa trwająca co najmniej 1 godzinę”, przykład ten przetłumaczylibyśmy w ten sposób: FrequencyConstraint
:
{
min_break_duration { seconds: 3600 } # 1 hour.
max_inter_break_duration { seconds: 39600 } # 11 hours (12 - 1 = 11).
}
Czas trwania i częstotliwość przerw w rozwiązaniu będą uwzględniać wszystkie te ograniczenia, a także okna czasowe i minimalne czasy trwania określone w BreakRequest
.
FrequencyConstraint
może w praktyce dotyczyć przerw nieciągłych. Na przykład poniższy harmonogram uwzględnia przykład „1 godzina co 12 godzin”:
04:00 vehicle start
.. performing travel and visits ..
09:00 1 hour break
10:00 end of the break
.. performing travel and visits ..
12:00 20-min lunch break
12:20 end of the break
.. performing travel and visits ..
21:00 1 hour break
22:00 end of the break
.. performing travel and visits ..
23:59 vehicle end
Pola | |
---|---|
min_ |
Wymagane. Minimalny czas trwania przerwy dla tego ograniczenia. Nieujemna. Zobacz opis |
max_ |
Wymagane. Maksymalny dozwolony przedział czasu na trasie, który nie obejmuje co najmniej częściowej przerwy |
DataFormat
Formaty danych plików wejściowych i wyjściowych.
Wartości w polu enum | |
---|---|
DATA_FORMAT_UNSPECIFIED |
Nieprawidłowa wartość. Format nie może być UNSPECIFIED. |
JSON |
JavaScript Object Notation. |
PROTO_TEXT |
Format tekstowy buforów protokołu. https://protobuf.dev/reference/protobuf/textformat-spec/ |
DistanceLimit
Limit określający maksymalną odległość, jaką można pokonać. Może być twardy lub miękki.
Jeśli zdefiniowany jest miękki limit, wartości soft_max_meters
i cost_per_kilometer_above_soft_max
muszą być zdefiniowane i nieujemne.
Pola | |
---|---|
max_ |
twardy limit ograniczający odległość do maksymalnie max_metrów. Limit nie może być liczbą ujemną. |
soft_ |
miękki limit, który nie narzuca maksymalnego limitu odległości, ale w przypadku jego naruszenia powoduje koszt, który jest dodawany do innych kosztów zdefiniowanych w modelu, z tą samą jednostką. Jeśli parametr soft_max_meters jest zdefiniowany, musi być mniejszy niż max_meters i nie może być liczbą ujemną. |
cost_ |
Koszty na kilometr, które mogą wzrosnąć do
Te koszty nie są obsługiwane w |
cost_ |
Koszt za kilometr, jeśli odległość przekracza limit
Koszt musi być nieujemny. |
GcsDestination
Lokalizacja w Google Cloud Storage, w której będą zapisywane pliki wyjściowe.
Pola | |
---|---|
uri |
Wymagane. Identyfikator URI obiektu w Google Cloud Storage. |
GcsSource
Lokalizacja w Google Cloud Storage, z której będzie odczytywany plik wejściowy.
Pola | |
---|---|
uri |
Wymagane. Identyfikator URI obiektu w Google Cloud Storage w formacie |
InjectedSolutionConstraint
Rozwiązanie wstrzyknięte w żądanie, w tym informacje o tym, które wizyty muszą być ograniczone i w jaki sposób.
Pola | |
---|---|
routes[] |
Trasy, którymi roztwór ma być podawany. Niektóre trasy mogą zostać pominięte w początkowym rozwiązaniu. Trasy i przesyłki pominięte muszą spełniać podstawowe założenia oparte na |
skipped_ |
Pominięte przesyłki rozwiązania do wstrzyknięcia. Niektóre z nich mogą zostać pominięte w pierwotnym rozwiązaniu. Zapoznaj się z polem |
constraint_ |
W przypadku co najmniej 1 grupy pojazdów określa, kiedy i w jakim stopniu można złagodzić ograniczenia. Jeśli to pole jest puste, wszystkie niepuste trasy pojazdów są w pełni ograniczone. |
ConstraintRelaxation
W przypadku grupy pojazdów określa, przy jakich wartościach progowych i o ile zostaną złagodzone ograniczenia dotyczące wizyt. Przesyłki wymienione w polu skipped_shipment
są przeznaczone do pominięcia, co oznacza, że nie można ich realizować.
Pola | |
---|---|
relaxations[] |
Wszystkie łagodniejsze ograniczenia dotyczące wizyt, które będą obowiązywać w przypadku wizyt na trasach z pojazdami w |
vehicle_ |
Określa indeksy pojazdów, do których ma zastosowanie ograniczenie wizyt Indeks pojazdu jest mapowany tak samo jak |
Relaks
Jeśli relaxations
jest pusty, czas rozpoczęcia i kolejność wszystkich wizyt na routes
są całkowicie ograniczone, a do tych tras nie można dodawać nowych wizyt. Czas rozpoczęcia i zakończenia w elementach routes
jest też całkowicie ograniczony, chyba że pojazd jest pusty (czyli nie ma żadnych wizyt i w modelu element used_if_route_is_empty
ma wartość false).
relaxations(i).level
określa poziom zniesienia ograniczeń zastosowany do wizyty #j, która spełnia te warunki:
route.visits(j).start_time >= relaxations(i).threshold_time
ORAZj + 1 >= relaxations(i).threshold_visit_count
Podobnie, uruchomienie pojazdu jest łagodzone do relaxations(i).level
, jeśli spełnia te kryteria:
vehicle_start_time >= relaxations(i).threshold_time
ORAZrelaxations(i).threshold_visit_count == 0
, a na końcu pojazdurelaxations(i).level
, jeśli spełnia te wymagania:vehicle_end_time >= relaxations(i).threshold_time
ORAZroute.visits_size() + 1 >= relaxations(i).threshold_visit_count
Aby zastosować poziom zrelaksowania, jeśli wizyta spełnia kryterium threshold_visit_count
LUB threshold_time
, dodaj 2 elementy relaxations
z tym samym elementem level
: jeden z ustawionym tylko parametrem threshold_visit_count
, a drugi tylko parametrem threshold_time
. Jeśli wizyta spełnia warunki wielu relaxations
, stosuje się najbardziej liberalny poziom. W efekcie od początku do końca przejazdu poziom relaksacji staje się coraz niższy: innymi słowy, nie maleje w miarę upływu czasu.
Czas i kolejność wizyt w trasach, które nie spełniają warunków progowych dotyczących żadnego relaxations
, są całkowicie ograniczone i nie można w tych sekwencjach wstawiać żadnych wizyt. Jeśli początek lub koniec okresu użytkowania pojazdu nie spełnia warunków żadnego poluzowania, czas jest stały, chyba że pojazd jest pusty.
Pola | |
---|---|
level |
Poziom zniesienia ograniczenia, który ma zastosowanie, gdy warunki na poziomie |
threshold_ |
Czas, w którym lub po którym można zastosować |
threshold_ |
Liczba wizyt, po których można zastosować Jeśli jest to |
Poziom
Określa różne poziomy zniesienia ograniczeń, które są stosowane w przypadku wizyty i tych, które następują po spełnieniu warunków progowych.
Wyliczenie poniżej jest uporządkowane według rosnącego stopnia relaksacji.
Wartości w polu enum | |
---|---|
LEVEL_UNSPECIFIED |
Domyślny dopuszczalny poziom zawężenia: nie ma żadnych zawężeń, co oznacza, że wszystkie wizyty są w pełni ograniczone. Ta wartość nie może być używana w sekcji |
RELAX_VISIT_TIMES_AFTER_THRESHOLD |
Czasy rozpoczęcia i zakończenia wizyty oraz czasy rozpoczęcia i zakończenia jazdy pojazdem zostaną złagodzone, ale każda wizyta będzie nadal powiązana z tym samym pojazdem i musi być zachowana kolejność wizyt: nie można wstawiać wizyt między sobą ani przed nimi. |
RELAX_VISIT_TIMES_AND_SEQUENCE_AFTER_THRESHOLD |
To samo co RELAX_VISIT_TIMES_AFTER_THRESHOLD , ale z mniej restrykcyjną sekwencją wizyt: wizyty mogą być wykonywane tylko przez ten pojazd, ale mogą też zostać anulowane. |
RELAX_ALL_AFTER_THRESHOLD |
To samo co RELAX_VISIT_TIMES_AND_SEQUENCE_AFTER_THRESHOLD , ale pojazd jest też zrelaksowany: wizyty są całkowicie bezpłatne w czasie progowym lub po nim i potencjalnie mogą zostać anulowane. |
InputConfig
Określ dane wejściowe dla [BatchOptimizeTours][google.maps.routeoptimization.v1.RouteOptimizationService.BatchOptimizeTours].
Pola | |
---|---|
data_ |
Wymagane. Format danych wejściowych. |
Pole unii source . Wymagane. source może być tylko jednym z tych elementów: |
|
gcs_ |
lokalizacja w Google Cloud Storage, Musi to być pojedynczy obiekt (plik). |
Lokalizacja
Zawiera lokalizację (punkt geograficzny i opcjonalnie nagłówek).
Pola | |
---|---|
lat_ |
Współrzędne geograficzne punktu drogi. |
heading |
Kierunek kompasu związany z kierunkiem ruchu. Ta wartość służy do określenia strony drogi, z której ma nastąpić odbiór i zwrot. Wartości kierunku mogą wynosić od 0 do 360, gdzie 0 to kierunek na północ, 90 to kierunek na wschód itd. |
OptimizeToursRequest
Prośba o przekazanie danych do rozwiązywania problemu optymalizacji trasy, który definiuje model dostawy do rozwiązania, a także parametry optymalizacji.
Pola | |
---|---|
parent |
Wymagane. Wybierz projekt lub lokalizację, do których chcesz zadzwonić. Format: * Jeśli nie określisz lokalizacji, region zostanie wybrany automatycznie. |
timeout |
Jeśli ten czas oczekiwania jest ustawiony, serwer zwraca odpowiedź, zanim upłynie czas oczekiwania lub termin serwera dla żądań synchronicznych, w zależności od tego, co nastąpi wcześniej. W przypadku żądań asynchronicznych serwer wygeneruje rozwiązanie (jeśli to możliwe) przed upływem limitu czasu. |
model |
Model dostawy do rozwiązania. |
solving_ |
Domyślny tryb rozwiązywania to |
search_ |
Tryb wyszukiwania użyty do rozwiązania żądania. |
injected_ |
Pomaga algorytmowi optymalizacji w znalezieniu pierwszego rozwiązania, które jest podobne do poprzedniego. Model jest ograniczony podczas tworzenia pierwszego rozwiązania. W pierwszym rozwiązaniu wszystkie przesyłki, które nie zostały zrealizowane na trasie, są domyślnie pomijane, ale mogą być realizowane w kolejnych rozwiązaniach. Rozwiązanie musi spełniać podstawowe założenia dotyczące ważności:
Jeśli wstrzyknięty kod nie jest wykonalny, niekoniecznie zwracany jest błąd weryfikacji. Zamiast tego może zostać zwrócony błąd wskazujący na brak możliwości wykonania. |
injected_ |
Ograniczenie algorytmu optymalizacji do znalezienia ostatecznego rozwiązania podobnego do poprzedniego. Można go na przykład użyć do zamrożenia części tras, które zostały już ukończone lub mają zostać ukończone, ale nie mogą być modyfikowane. Jeśli wstrzyknięty kod nie jest wykonalny, niekoniecznie zwracany jest błąd weryfikacji. Zamiast tego może zostać zwrócony błąd wskazujący na brak możliwości wykonania. |
refresh_ |
Jeśli nie jest pusty, dane trasy zostaną odświeżone bez zmiany ich sekwencji wizyt lub czasu podróży: zostaną zaktualizowane tylko inne szczegóły. Nie rozwiązuje to problemu. Od listopada 2020 r. ta opcja wypełnia tylko linie wielokątów na niepustych trasach i wymaga, aby parametr Pola Nie można używać tego pola razem z polem
|
interpret_ |
Jeśli wartość to prawda:
Ta interpretacja dotyczy pól Jeśli ma wartość true, etykiety w tych kategoriach mogą się pojawiać maksymalnie raz w danej kategorii:
Jeśli Usunięcie wizyt na trasie lub całych tras z wstrzykniętego rozwiązania może mieć wpływ na implikowane ograniczenia, co może spowodować zmianę rozwiązania, błędy walidacji lub niemożliwość jego wykonania. UWAGA: osoba dzwoniąca musi się upewnić, że każda wartość |
consider_ |
Warto uwzględnić prognozę ruchu podczas obliczania pól |
populate_ |
Jeśli ma wartość Prawda, w odpowiedzi |
populate_ |
Jeśli ma wartość Prawda, w odpowiedzi |
allow_ |
Jeśli ta opcja jest ustawiona, żądanie może mieć termin (patrz https://grpc.io/blog/deadlines) do 60 minut. W przeciwnym razie maksymalny termin to tylko 30 minut. Pamiętaj, że w przypadku długotrwałych żądań występuje znacznie większe (choć nadal niewielkie) ryzyko przerwania. |
use_ |
Jeśli to ustawienie ma wartość true, odległości przebycia zostaną obliczone na podstawie odległości geodezyjnych zamiast odległości w Mapach Google, a czasy przejazdu zostaną obliczone na podstawie odległości geodezyjnych przy prędkości określonej przez parametr |
label |
Etykieta, która może służyć do identyfikowania tego żądania, zgłoszonego w formularzu |
geodesic_ |
Gdy |
max_ |
Obcina zwracaną liczbę błędów weryfikacji. Te błędy są zwykle dołączane do pakietu błędu INVALID_ARGUMENT jako szczegóły błędu BadRequest (https://cloud.google.com/apis/design/errors#error_details), chyba że parametr solving_mode=VALIDATE_ONLY: patrz pole |
SearchMode
Tryb definiujący zachowanie wyszukiwania, który umożliwia zrównoważenie opóźnienia i jakości rozwiązania. W przypadku wszystkich trybów obowiązuje globalny termin składania żądań.
Wartości w polu enum | |
---|---|
SEARCH_MODE_UNSPECIFIED |
Tryb wyszukiwania nieokreślony, równoważny z RETURN_FAST . |
RETURN_FAST |
Zatrzymaj wyszukiwanie po znalezieniu pierwszego odpowiedniego rozwiązania. |
CONSUME_ALL_AVAILABLE_TIME |
Poświęć cały dostępny czas na poszukiwanie lepszych rozwiązań. |
SolvingMode
Określa, jak rozwiązanie ma obsłużyć żądanie. W wszystkich trybach oprócz VALIDATE_ONLY
, jeśli żądanie jest nieprawidłowe, otrzymasz błąd INVALID_REQUEST
. Aby ograniczyć liczbę zwracanych błędów, zobacz max_validation_errors
.
Wartości w polu enum | |
---|---|
DEFAULT_SOLVE |
Rozwiąż model. Ostrzeżenia mogą być wydawane w ramach [OptimizeToursResponse.validation_errors][google.cloud.optimization.v1.OptimizeToursResponse.validation_errors]. |
VALIDATE_ONLY |
Weryfikuje tylko model bez rozwiązywania: wypełnia jak najwięcej OptimizeToursResponse.validation_errors . |
DETECT_SOME_INFEASIBLE_SHIPMENTS |
Wypełnia tylko pola WAŻNE: zwracane są tylko te przesyłki, które zostały wykryte jako niemożliwe do zrealizowania podczas wstępnego przetwarzania. |
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.
Pola | |
---|---|
routes[] |
Trasy obliczone dla każdego pojazdu; i-ta trasa odpowiada i-temu pojazdowi w modelu. |
request_ |
Kopia |
skipped_ |
Lista wszystkich pominiętych przesyłek. |
validation_ |
Lista wszystkich błędów weryfikacji, które udało nam się wykryć. Więcej informacji o komunikacie |
metrics |
Dane o czasie trwania, odległości i użytkowaniu tego rozwiązania. |
Dane
Ogólne dane, zagregowane na podstawie wszystkich tras.
Pola | |
---|---|
aggregated_ |
Dane zbiorcze dotyczące tras. Każde dane to suma (lub wartość maksymalna w przypadku obciążeń) we wszystkich polach |
skipped_ |
Liczba pominiętych przesyłek obowiązkowych. |
used_ |
Liczba używanych pojazdów. Uwaga: jeśli trasa pojazdu jest pusta, a wartość atrybutu |
earliest_ |
Najwcześniejszy czas rozpoczęcia używania pojazdu, obliczony jako minimalny dla wszystkich używanych pojazdów |
latest_ |
Najpóźniejszy czas zakończenia dla używanego pojazdu, obliczony jako maksymalny dla wszystkich używanych pojazdów |
costs |
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. |
total_ |
Łączny koszt rozwiązania. Suma wszystkich wartości w mapie kosztów. |
OptimizeToursValidationError
Opisuje błąd lub ostrzeżenie występujące podczas sprawdzania OptimizeToursRequest
.
Pola | |
---|---|
code |
Błąd weryfikacji jest zdefiniowany przez parę ( 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 STABILNOŚĆ: |
display_ |
Wyświetlana nazwa błędu. |
fields[] |
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:
Pamiętaj jednak, że liczba elementów |
error_ |
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 |
offending_ |
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 start_time_windows
pojazdu 5 za pomocą:
name: "vehicles" index: 5 sub_field { name: "end_time_windows" index: 2 }
Jednak pomijamy elementy najwyższego poziomu, takie jak OptimizeToursRequest
lub ShipmentModel
, aby nie zaśmiecać wiadomości.
Pola | |
---|---|
name |
Nazwa pola, np. „vehicles”. |
sub_ |
W razie potrzeby rekurencyjnie zagnieżdżone podpole. |
Pole unii
|
|
index |
Indeks pola, jeśli jest powtarzany. |
key |
klucz, jeśli pole jest mapą; |
OutputConfig
Określ miejsce docelowe dla wyników [BatchOptimizeTours][google.maps.routeoptimization.v1.RouteOptimizationService.BatchOptimizeTours].
Pola | |
---|---|
data_ |
Wymagane. Format danych wyjściowych. |
Pole unii destination . Wymagane. destination może być tylko jednym z tych elementów: |
|
gcs_ |
Lokalizacja w Google Cloud Storage, w której mają być zapisywane dane wyjściowe. |
RouteModifiers
Zawiera zestaw opcjonalnych warunków, które należy spełnić podczas obliczania tras pojazdów. Jest to podobne do RouteModifiers
w interfejsie API Preferowane trasy na platformie Mapy Google (https://developers.google.com/maps/documentation/routes/reference/rest/v2/RouteModifiers).
Pola | |
---|---|
avoid_ |
Określa, czy w uzasadnionych przypadkach należy unikać dróg płatnych. Preferowane będą trasy nieobejmujące dróg płatnych. Dotyczy to tylko pojazdów mechanicznych. |
avoid_ |
Określa, czy w uzasadnionych przypadkach ma być unikana jazda autostradami. Preferowane będą trasy nieobejmujące autostrad. Dotyczy to tylko pojazdów mechanicznych. |
avoid_ |
Określa, czy w uzasadnionych przypadkach ma być unikana przeprawa promowa. Preferowane będą trasy nieobejmujące przejazdów promem. Dotyczy to tylko pojazdów mechanicznych. |
avoid_ |
Opcjonalnie: Określa, czy w uzasadnionych przypadkach ma być unikana nawigacja wewnątrz budynków. Preferowane będą trasy nieobejmujące nawigacji wewnątrz budynków. Dotyczy tylko trybu podróży |
Wysyłka
Przesyłka pojedynczego produktu, od momentu jego odebrania do momentu dostarczenia. Aby przesyłka została uznana za zrealizowaną, pojazd musi odwiedzić jedną z lokalizacji odbioru (i odpowiednio zmniejszyć ilość wolnych miejsc), a następnie odwiedzić jedną z lokalizacji dostawy (i odpowiednio zwiększyć ilość wolnych miejsc).
Pola | |
---|---|
display_ |
Zdefiniowana przez użytkownika nazwa wyświetlana przesyłki. Może on zawierać maksymalnie 63 znaki i znaki UTF-8. |
pickups[] |
Zestaw alternatyw odbioru powiązanych z przesyłką. Jeśli nie określono inaczej, pojazd musi tylko odwiedzić lokalizację odpowiadającą dostawom. |
deliveries[] |
Zestaw alternatyw dostawy powiązanych z przesyłką. Jeśli nie wskażesz lokalizacji, pojazd musi tylko odwiedzić lokalizację odpowiadającą odbiorowi. |
load_ |
wymagania dotyczące ładunku (np. waga, objętość, liczba palet itp.); Klucze w mapie powinny być identyfikatorami, które opisują typ odpowiadającego im obciążenia. W idealnej sytuacji powinny też zawierać jednostki. Na przykład: „weight_kg”, „volume_gallons”, „pallet_count” itp. Jeśli dany klucz nie pojawia się na mapie, odpowiadający mu ładunek jest uważany za pusty. |
allowed_ |
Zestaw pojazdów, które mogą wykonać tę dostawę. Jeśli pole jest puste, wszystkie pojazdy mogą je wykonać. Pojazdy są identyfikowane przez ich numer na liście |
costs_ |
Określa koszt poniesiony podczas dostawy przesyłki przez dany pojazd. Jeśli jest podany, musi zawierać 1 z tych elementów:
Te koszty muszą być wyrażone w tych samych jednostkach co |
costs_ |
Indeksy pojazdów, do których ma zastosowanie |
pickup_ |
Określa maksymalny bezwzględny czas objazdu w porównaniu z najkrótszą ścieżką od odbioru do dostawy. Jeśli jest podany, musi być dodatni, a przesyłka musi zawierać co najmniej odbiór i dostawę. Niech na przykład t będzie najkrótszym czasem potrzebnym na dotarcie z wybranego miejsca odbioru bezpośrednio do wybranego miejsca dostawy. Ustawienie
Jeśli w przypadku jednej przesyłki są określone zarówno względne, jak i bezwzględne limity, w przypadku każdej możliwej pary odbioru/dostawy stosuje się bardziej restrykcyjny limit. Od października 2017 r. objazdy są obsługiwane tylko wtedy, gdy czas podróży nie zależy od pojazdu. |
pickup_ |
Określa maksymalny czas od rozpoczęcia odbioru do rozpoczęcia dostawy przesyłki. Jeśli jest podany, musi być dodatni, a przesyłka musi zawierać co najmniej odbiór i dostawę. Nie zależy to od tego, które opcje odbioru i dostawy są wybrane ani od prędkości pojazdu. Można je określić razem z ograniczeniami maksymalnego objazdu: rozwiązanie będzie uwzględniać obie specyfikacje. |
shipment_ |
Niepusty ciąg znaków określający „typ” przesyłki. Za pomocą tej funkcji można definiować niezgodności lub wymagania dotyczące Różnica w porównaniu z |
label |
Określa etykietę dla tej przesyłki. Ta etykieta jest raportowana w odpowiedzi w |
ignore |
Jeśli wartość to prawda, pomiń tę dostawę, ale nie stosuj Ignorowanie dostawy powoduje błąd weryfikacji, jeśli w modelu występują jakiekolwiek Ignorowanie dostawy realizowanej w ramach |
penalty_ |
Jeśli przesyłka nie zostanie dostarczona, ta kara zostanie dodana do łącznego kosztu tras. Przesyłka jest uważana za ukończoną, jeśli wybrano jedną z dostępnych opcji odbioru lub dostawy. Koszt może być wyrażony w tych samych jednostkach co wszystkie inne pola związane z kosztami w modelu i musi być dodatni. WAŻNE: jeśli nie określisz tej kary, zostanie ona uznana za nieskończoną, co oznacza, że przesyłka musi zostać zrealizowana. |
pickup_ |
Określa maksymalny czas objazdu w porównaniu z najkrótszą ścieżką od odbioru do dostawy. Jeśli jest podany, musi być dodatni, a przesyłka musi zawierać co najmniej odbiór i dostawę. Niech na przykład t będzie najkrótszym czasem potrzebnym na dotarcie z wybranego miejsca odbioru bezpośrednio do wybranego miejsca dostawy. Ustawienie
Jeśli w przypadku jednej przesyłki są określone zarówno względne, jak i bezwzględne limity, w przypadku każdej możliwej pary odbioru/dostawy stosuje się bardziej restrykcyjny limit. Od października 2017 r. objazdy są obsługiwane tylko wtedy, gdy czas podróży nie zależy od pojazdów. |
Wczytaj
Podczas wizyty w przypadku odbioru ładunku do pojazdu może zostać dodana zdefiniowana kwota, a w przypadku dostawy – odjęta. Ta wiadomość określa tę kwotę. Zobacz load_demands
.
Pola | |
---|---|
amount |
Wartość, o którą będzie się zmieniać ładunek pojazdu podczas danej wizyty. Ponieważ jest to liczba całkowita, zalecamy wybranie odpowiedniej jednostki, aby uniknąć utraty dokładności. Wartość musi być większa lub równa 0. |
VisitRequest
Prośba o wizytę, którą można wykonać pojazdem: zawiera ona lokalizację geograficzną (lub dwie, patrz poniżej), godziny otwarcia i zamknięcia reprezentowane przez okna czasowe oraz czas trwania usługi (czas spędzony przez pojazd po przybyciu do miejsca odbioru lub dostarczenia towarów).
Pola | |
---|---|
arrival_ |
Geolokalizacja miejsca, do którego dociera pojazd podczas wykonywania tej |
arrival_ |
Punkt orientacyjny, w którym pojazd dociera podczas wykonywania tego |
departure_ |
Miejsce docelowe, do którego pojazd ma dojechać po zakończeniu tego |
departure_ |
Punkt orientacyjny, w którym pojazd wyrusza po zakończeniu tego |
tags[] |
Określa tagi dołączone do żądania wizyty. Pustych lub powtarzających się ciągów znaków nie można stosować. |
time_ |
Okna czasowe, które ograniczają czas przybycia podczas wizyty. Pamiętaj, że pojazd może wyjechać poza oknem czasowym przyjazdu, czyli czas przyjazdu + czas trwania nie musi mieścić się w oknie czasowym. Może to spowodować oczekiwanie, jeśli pojazd dotrze przed Brak Okna czasowe muszą być odseparowane, co oznacza, że żadne z nich nie może się pokrywać z innym ani być sąsiadować z innym. Okna czasowe muszą być uporządkowane według rosnącej kolejności. Wartości |
duration |
Czas trwania wizyty, czyli czas spędzony przez pojazd między przybyciem a odejściem (dodawany do możliwego czasu oczekiwania; patrz |
cost |
Koszt realizacji tego żądania wizyty na trasie pojazdu. Można go używać do płacenia różnych kosztów za odbiór lub dostawę przesyłki. Koszt musi być wyrażony w tych samych jednostkach co |
load_ |
Wczytaj wymagania dotyczące tego żądania wizyty. To pole jest podobne do pola |
visit_ |
Określa typy wizyt. Może ona służyć do przydzielenia dodatkowego czasu potrzebnego pojazdowi na wykonanie tej wizyty (patrz Typ może wystąpić tylko raz. |
label |
Określa etykietę dla tego |
ShipmentModel
Model dostawy zawiera zestaw dostaw, które muszą być realizowane przez zestaw pojazdów, przy jednoczesnym minimalizowaniu łącznego kosztu, który jest sumą:
- kosztu wyznaczania trasy pojazdów (suma kosztu na godzinę, kosztu na czas przejazdu i kosztów stałych wszystkich pojazdów);
- kary za niewywiązanie się z obowiązku dostawy.
- koszt globalnego czasu trwania przesyłek;
Pola | |
---|---|
shipments[] |
Zestaw dostaw, które muszą być wykonane w ramach modelu. |
vehicles[] |
Zestaw pojazdów, których można używać do wykonywania wizyt. |
global_ |
Globalny czas rozpoczęcia i zakończenia modelu: nie można uznać za prawidłowego żadnego czasu spoza tego zakresu. Zakres czasowy modelu musi być krótszy niż rok, czyli Jeśli używasz pól |
global_ |
Jeśli nie zostanie ustawiona, domyślnie używana jest data 1 stycznia 1971 r., godzina 00:00:00 UTC (czyli 31536000 sekund, 0 nanosekund). |
global_ |
„Całkowity czas trwania” ogólnego planu to różnica między najwcześniejszym skutecznym czasem rozpoczęcia a najpóźniejszym skutecznym czasem zakończenia wszystkich pojazdów. Użytkownicy mogą przypisać do tej ilości koszt za godzinę, aby na przykład zoptymalizować zadanie pod kątem jak najszybszego ukończenia. Te koszty muszą być wyrażone w tych samych jednostkach co |
duration_ |
Określa macierze czasu trwania i odległości używane w modelu. Jeśli to pole jest puste, zamiast niego używane są odległości na mapach Google lub geodezyjne, w zależności od wartości pola Przykłady użycia:
|
duration_ |
Tagi określające źródła macierzy czasu trwania i odległości; Tagi odpowiadają elementom |
duration_ |
Tagi określające miejsca docelowe macierzy czasu i odległości; Tagi odpowiadają |
transition_ |
Dodano do modelu atrybuty przejścia. |
shipment_ |
Zestawy niezgodnych typów dostawy (patrz |
shipment_ |
zestawy wymagań |
precedence_ |
Zestaw reguł pierwszeństwa, które muszą być egzekwowane w modelu. |
max_ |
Ogranicza maksymalną liczbę aktywnych pojazdów. Pojazd jest aktywny, jeśli jego trasa obejmuje co najmniej jedną dostawę. Można go użyć do ograniczenia liczby tras w przypadku, gdy kierowców jest mniej niż pojazdów, a flota pojazdów jest zróżnicowana. Następnie optymalizacja wybierze najlepszy podzbiór pojazdów do użycia. Musi być dodatni. |
DurationDistanceMatrix
Określa czas trwania i macierz odległości od miejsc początkowych wizyt i pojazdu do miejsc końcowych wizyt i pojazdu.
Pola | |
---|---|
rows[] |
Określa wiersze macierzy czasu trwania i odległości. Musi zawierać taką samą liczbę elementów jak |
vehicle_ |
Tag określający, do których pojazdów ma zastosowanie ta tablica czasu trwania i odległości. Jeśli jest pusty, ma zastosowanie do wszystkich pojazdów i może być tylko jedna matryca. Każdy początek pojazdu musi odpowiadać dokładnie jednej macierzy, czyli dokładnie jedno z pol Wszystkie macierze muszą mieć inną wartość |
Wiersz
Określa wiersz macierzy czasu trwania i odległości.
Pola | |
---|---|
durations[] |
Wartości czasu trwania w danym wierszu. Musi zawierać taką samą liczbę elementów jak |
meters[] |
Wartości odległości w danym wierszu. Jeśli w modelu nie ma żadnych kosztów ani ograniczeń odnoszących się do odległości, można pozostawić to pole puste. W przeciwnym razie musi ono zawierać tyle elementów, co |
PrecedenceRule
Reguła pierwszeństwa między 2 zdarzeniami (każde zdarzenie to odbiór lub dostawa przesyłki): „drugie” zdarzenie musi rozpocząć się co najmniej offset_duration
s po rozpoczęciu „pierwszego”.
Kilka priorytetów może dotyczyć tych samych (lub powiązanych) zdarzeń, np. „Odbiór B następuje po dostawie A” i „Odbiór C następuje po odbiorze B”.
Ponadto priorytety mają zastosowanie tylko wtedy, gdy obie przesyłki są realizowane, a w przeciwnym razie są ignorowane.
Pola | |
---|---|
first_ |
Wskazuje, czy „pierwsze” zdarzenie to dostawa. |
second_ |
Wskazuje, czy „drugie” zdarzenie to dostawa. |
offset_ |
Odstęp między zdarzeniami „first” i „second”. Może być ujemna. |
first_ |
Indeks dostawy „pierwszego” zdarzenia. To pole musi być określone. |
second_ |
Indeks dostawy „drugiego” zdarzenia. To pole musi być określone. |
ShipmentRoute
Trasę pojazdu można rozłożyć na osi czasu w ten sposób (zakładamy, że jest n wizyt):
| | | | | T[2], | | |
| Transition | Visit #0 | | | V[2], | | |
| #0 | aka | T[1] | V[1] | ... | V[n-1] | T[n] |
| aka T[0] | V[0] | | | V[n-2],| | |
| | | | | T[n-1] | | |
^ ^ ^ ^ ^ ^ ^ ^
vehicle V[0].start V[0].end V[1]. V[1]. V[n]. V[n]. vehicle
start (arrival) (departure) start end start end end
Pamiętaj, że:
- „dokładne zdarzenia”, takie jak początek i koniec jazdy oraz początek i koniec każdej wizyty (czyli przyjazd i wyjazd). Mają miejsce w danej sekundzie.
- „przedziały czasowe”, np. same wizyty i przejście między wizytami. Chociaż czasami interwały czasowe mogą mieć zerową długość, czyli zaczynają się i kończą w tej samej sekundzie, często mają dodatnią długość.
Niezmienniki:
- Jeśli jest n wizyt, to jest n + 1 przejście.
- Wizyta jest zawsze otoczona przez przejście poprzedzające ją (ten sam indeks) i przejście następujące po niej (indeks + 1).
- Po uruchomieniu pojazdu zawsze następuje przejście #0.
- Koniec pojazdu jest zawsze poprzedzony przez przejście #n.
Oto, co się dzieje podczas Transition
i Visit
:
---+-------------------------------------+-----------------------------+-->
| TRANSITION[i] | VISIT[i] |
| | |
| * TRAVEL: the vehicle moves from | PERFORM the visit: |
| VISIT[i-1].departure_location to | |
| VISIT[i].arrival_location, which | * Spend some time: |
| takes a given travel duration | the "visit duration". |
| and distance | |
| | * Load or unload |
| * BREAKS: the driver may have | some quantities from the |
| breaks (e.g. lunch break). | vehicle: the "demand". |
| | |
| * WAIT: the driver/vehicle does | |
| nothing. This can happen for | |
| many reasons, for example when | |
| the vehicle reaches the next | |
| event's destination before the | |
| start of its time window | |
| | |
| * DELAY: *right before* the next | |
| arrival. E.g. the vehicle and/or | |
| driver spends time unloading. | |
| | |
---+-------------------------------------+-----------------------------+-->
^ ^ ^
V[i-1].end V[i].start V[i].end
Na koniec opisujemy, jak można ustawić elementy TRAVEL, BREAKS, DELAY i WAIT podczas przejścia.
- Nie nakładają się.
- OPÓŹNIENIE jest unikalne i musi być ciągłym okresem czasu bezpośrednio przed następną wizytą (lub końcem okresu użytkowania pojazdu). Wystarczy więc znać czas opóźnienia, aby określić czas jego rozpoczęcia i zakończenia.
- PRZERWY to ciągłe, niepokrywające się okresy czasu. Odpowiedź zawiera czas rozpoczęcia i czas trwania każdej przerwy.
- TRAVEL i WAIT są „wymienne”: mogą być przerywane kilka razy podczas tego przejścia. Klienci mogą założyć, że podróż odbywa się „jak najszybciej”, a pozostały czas wypełnia „czekanie”.
Przykład (skomplikowany):
TRANSITION[i]
--++-----+-----------------------------------------------------------++-->
|| | | | | | | ||
|| T | B | T | | B | | D ||
|| r | r | r | W | r | W | e ||
|| a | e | a | a | e | a | l ||
|| v | a | v | i | a | i | a ||
|| e | k | e | t | k | t | y ||
|| l | | l | | | | ||
|| | | | | | | ||
--++-----------------------------------------------------------------++-->
Pola | |
---|---|
vehicle_ |
Pojazd wykonujący trasę, zidentyfikowany przez swój indeks w źródle |
vehicle_ |
Etykieta pojazdu wykonującego tę trasę, równa |
vehicle_ |
Czas rozpoczęcia przez pojazd trasy. |
vehicle_ |
Czas, w którym pojazd kończy trasę. |
visits[] |
Uporządkowana sekwencja wizyt reprezentująca trasę. visits[i] to i-ta wizyta na trasie. Jeśli to pole jest puste, pojazd jest uważany za nieużywany. |
transitions[] |
Uporządkowana lista przejść na trasie. |
has_ |
Gdy
Przybycie do next_visit nastąpi prawdopodobnie później niż w obecnym oknie czasowym z powodu wydłużenia szacowanego czasu podróży |
route_ |
Zakodowana linia łamana reprezentująca trasę. To pole jest wypełniane tylko wtedy, gdy zasada |
breaks[] |
Przerwy zaplanowane dla pojazdu wykonującego tę trasę. Sekwencja |
metrics |
Dane dotyczące czasu trwania, odległości i obciążenia na tej trasie. Pola |
route_ |
Koszt trasy z podziałem na pola żądania związane 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 na całej trasie. Innymi słowy, costs["model.shipments.pickups.cost"] to suma wszystkich kosztów odbioru na trasie. 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 postaci zagregowanej. |
route_ |
Łączny koszt trasy. Suma wszystkich kosztów na mapie kosztów. |
Przerwa
Dane przedstawiające wykonanie przerwy.
Pola | |
---|---|
start_ |
Czas rozpoczęcia przerwy. |
duration |
Czas trwania przerwy. |
EncodedPolyline
Zakodowana reprezentacja linii złożonej. Więcej informacji o kodowaniu łańcucha znaków znajdziesz tutaj: https://developers.google.com/maps/documentation/utilities/polylinealgorithm https://developers.google.com/maps/documentation/javascript/reference/geometry#encoding.
Pola | |
---|---|
points |
Ciąg znaków reprezentujący zakodowane punkty linii łamanej. |
Przejście
Przejście między 2 zdarzeniami na trasie. Zobacz opis ShipmentRoute
.
Jeśli pojazd nie ma wartości start_location
ani end_location
, odpowiednie dane dotyczące podróży mają wartość 0.
Pola | |
---|---|
travel_ |
Czas trwania podróży podczas tej zmiany. |
travel_ |
Odległość przebyta podczas przejścia. |
traffic_ |
Gdy żądanie ruchu jest wysyłane za pomocą |
delay_ |
Suma czasów opóźnienia zastosowanych do tego przejścia. Opóźnienie rozpoczyna się dokładnie |
break_ |
Suma czasu trwania przerw, które wystąpiły podczas tego przejścia (jeśli wystąpiły). Szczegóły dotyczące czasu rozpoczęcia i długości przerwy są przechowywane w pliku |
wait_ |
Czas oczekiwania podczas tego przejścia. Czas oczekiwania odpowiada czasowi bezczynności i nie obejmuje przerwy. Pamiętaj też, że czas oczekiwania może być podzielony na kilka nieciągłych przedziałów. |
total_ |
Łączny czas trwania przejścia, podany dla wygody. Jest równe:
|
start_ |
Czas rozpoczęcia tego przejścia. |
route_ |
Zakodowana linia łamana reprezentująca trasę przebytą podczas przemieszczania. To pole jest wypełniane tylko wtedy, gdy zasada |
route_ |
Tylko dane wyjściowe. Nieprzezroczysty token, który można przekazać do Navigation SDK w celu odtworzenia trasy podczas nawigacji. W przypadku zmiany trasy token ten zachowuje pierwotny zamiar podczas tworzenia trasy. Traktuj ten token jako nieprzejrzysty blok danych. Nie porównuj wartości w różnych żądaniach, ponieważ może się ona zmieniać, nawet jeśli usługa zwróci dokładnie tę samą trasę. To pole jest wypełniane tylko wtedy, gdy zasada |
vehicle_ |
Ładunki pojazdu w trakcie tego przejścia dla każdego typu, który pojawia się w Obciążenia podczas pierwszego przejścia to obciążenia początkowe trasy pojazdu. Następnie po każdej wizycie wartości |
VehicleLoad
Raport o rzeczywistym obciążeniu pojazdu w określonym punkcie trasy dla danego typu (patrz Transition.vehicle_loads
).
Pola | |
---|---|
amount |
Ilość ładunku w danym pojeździe. Jednostka ładunku jest zwykle określana przez typ. Zobacz |
Odwiedź
Wizyta wykonana podczas tworzenia trasy. Ta wizyta odpowiada odbiorowi lub dostawie Shipment
.
Pola | |
---|---|
shipment_ |
Indeks pola |
is_ |
Jeśli wartość to prawda, wizyta odpowiada odbiorowi |
visit_ |
Indeks |
start_ |
Czas rozpoczęcia wizyty. Pamiętaj, że pojazd może dotrzeć do miejsca wizyty wcześniej. Czasy są zgodne z |
load_ |
Łączna liczba wizyt, która jest sumą żądania dostawy i żądania wizyty |
detour |
Dodatkowy czas objazdu spowodowany wizytami w miejscach na trasie przed wizytą oraz potencjalny czas oczekiwania spowodowany oknami czasowymi. Jeśli wizyta to dostawa, objazd jest obliczany na podstawie odpowiedniej wizyty odbioru i jest równy:
W przeciwnym razie jest obliczana na podstawie pojazdu
|
shipment_ |
Kopia odpowiedniej wartości |
visit_ |
Kopia odpowiedniej wartości |
ShipmentTypeIncompatibility
Określa niezgodności między dostawami w zależności od ich typu shipment_type. Występowanie niezgodnych przesyłek na tej samej trasie jest ograniczone na podstawie trybu niezgodności.
Pola | |
---|---|
types[] |
Lista niezgodnych typów. 2 dostawy z różnymi wartościami |
incompatibility_ |
Tryb zastosowany do niezgodności. |
IncompatibilityMode
Tryby określające, jak ograniczać pojawianie się niezgodnych przesyłek na tej samej trasie.
Wartości w polu enum | |
---|---|
INCOMPATIBILITY_MODE_UNSPECIFIED |
Nieokreślony tryb niezgodności. Ta wartość nigdy nie powinna być używana. |
NOT_PERFORMED_BY_SAME_VEHICLE |
W tym trybie 2 przesyłki z niekompatybilnymi typami nigdy nie mogą korzystać z tego samego pojazdu. |
NOT_IN_SAME_VEHICLE_SIMULTANEOUSLY |
W przypadku dwóch przesyłek z niezgodnymi typami w trybie niezgodności
|
ShipmentTypeRequirement
Określa wymagania dotyczące przesyłek na podstawie ich typu przesyłki. Szczegóły wymagań są definiowane przez tryb wymagań.
Pola | |
---|---|
required_ |
Lista alternatywnych typów dostawy wymaganych przez |
dependent_ |
Wszystkie przesyłki z typem w polu UWAGA: łańcuchy wymagań, w których |
requirement_ |
Tryb zastosowany do wymagań. |
RequirementMode
Tryby definiujące sposób wyświetlania przesyłek zależnych na trasie.
Wartości w polu enum | |
---|---|
REQUIREMENT_MODE_UNSPECIFIED |
Nieokreślony tryb wymagań. Ta wartość nigdy nie powinna być używana. |
PERFORMED_BY_SAME_VEHICLE |
W tym trybie wszystkie przesyłki „zależne” muszą być przewożone tym samym pojazdem co co najmniej jedna przesyłka „wymagana”. |
IN_SAME_VEHICLE_AT_PICKUP_TIME |
W trybie Odbiór „zależnej” przesyłki musi więc mieć:
|
IN_SAME_VEHICLE_AT_DELIVERY_TIME |
To samo co wcześniej, z tą różnicą, że w momencie dostawy przesyłki „zależne” muszą mieć w pojeździe przesyłkę „wymaganą”. |
SkippedShipment
Określa szczegóły niewykonanych dostaw w rozwiązaniu. W przypadku błahych przypadków lub jeśli możemy zidentyfikować przyczynę pominięcia, podajemy ją tutaj.
Pola | |
---|---|
index |
Indeks odpowiada indeksowi przesyłki w źródle |
label |
Kopia odpowiedniej wartości |
reasons[] |
Lista powodów, dla których przesyłka została pominięta. Zobacz komentarz powyżej |
Przyczyna
Jeśli możemy wyjaśnić, dlaczego przesyłka została pominięta, podamy tutaj powody. Jeśli przyczyna nie jest taka sama w przypadku wszystkich pojazdów, element reason
będzie zawierał więcej niż 1 element. Przesyłka pominięta nie może mieć zduplikowanych przyczyn, czyli wszystkich pól, z wyjątkiem pola example_vehicle_index
. Przykład:
reasons {
code: DEMAND_EXCEEDS_VEHICLE_CAPACITY
example_vehicle_index: 1
example_exceeded_capacity_type: "Apples"
}
reasons {
code: DEMAND_EXCEEDS_VEHICLE_CAPACITY
example_vehicle_index: 3
example_exceeded_capacity_type: "Pears"
}
reasons {
code: CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DISTANCE_LIMIT
example_vehicle_index: 1
}
Przesyłka, która została pominięta, jest niezgodna ze wszystkimi pojazdami. Powody mogą być różne w przypadku poszczególnych pojazdów, ale w przynajmniej jednym z nich przekroczona byłaby pojemność „jabłek” (w tym w samochodzie 1), w przynajmniej jednym przekroczona byłaby pojemność „jabłek” (w tym w samochodzie 3), a w przynajmniej jednym przekroczony byłby limit odległości (w tym w samochodzie 1).
Pola | |
---|---|
code |
Zapoznaj się z komentarzami w kodzie. |
example_ |
Jeśli kod powodu to |
example_ |
Jeśli przyczyna dotyczy niezgodności przesyłki z pojazdem, to pole zawiera indeks odpowiedniego pojazdu. |
Kod
Kod identyfikujący typ przyczyny. Kolejność nie ma znaczenia. W szczególności nie wskazuje, czy dana przyczyna pojawi się przed inną w rozwiązaniu, jeśli obie są stosowane.
Wartości w polu enum | |
---|---|
CODE_UNSPECIFIED |
Nigdy nie należy ich używać. |
NO_VEHICLE |
W modelu nie ma żadnego pojazdu, przez co wszystkie dostawy są niemożliwe. |
DEMAND_EXCEEDS_VEHICLE_CAPACITY |
Popyt na przesyłkę przekracza pojemność pojazdu w przypadku niektórych typów pojemności, w tym example_exceeded_capacity_type . |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DISTANCE_LIMIT |
Minimalna odległość niezbędna do wykonania tej dostawy, czyli od Pamiętaj, że do tego obliczenia używamy odległości geodezyjnych. |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT |
Minimalny czas potrzebny do wykonania tej dostawy, w tym czas podróży, oczekiwania i obsługi, przekracza Uwaga: czas podróży jest obliczany w najlepszym możliwym scenariuszu, czyli jako odległość geodezyjna × 36 m/s (około 130 km/h). |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TRAVEL_DURATION_LIMIT |
To samo co powyżej, ale porównujemy tylko minimalny czas podróży i travel_duration_limit pojazdu. |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TIME_WINDOWS |
Pojazd nie może wykonać tej dostawy w najlepszym scenariuszu (patrz CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT w celu obliczenia czasu), jeśli rozpoczyna się w najwcześniejszym możliwym czasie: łączny czas pracy pojazdu spowoduje, że zakończy on pracę po upływie najpóźniejszego czasu zakończenia. |
VEHICLE_NOT_ALLOWED |
Pole allowed_vehicle_indices w przesyłce nie jest puste, a pojazd do niej nie należy. |
TimeWindow
Okna czasowe ograniczają czas trwania zdarzenia, np. czas przybycia w ramach wizyty lub czas rozpoczęcia i zakończenia korzystania z pojazdu.
Sztywne granice przedziału czasowego, start_time
i end_time
, narzucają najwcześniejszy i najpóźniejszy czas zdarzenia, tak aby start_time <= event_time <=
end_time
. Dolna granica okna czasowego (soft_start_time), soft_start_time
, wyraża preferencję, aby zdarzenie miało miejsce w czasie lub po soft_start_time
, przy czym koszt jest proporcjonalny do czasu, jaki upływa od soft_start_time do wystąpienia zdarzenia. Górna granica okna czasowego, soft_end_time
, wyraża preferencję, aby zdarzenie miało miejsce w czasie lub przed czasem soft_end_time
, przynosząc koszt proporcjonalny do czasu, jaki upłynie od tego momentu.soft_end_time
Wartości start_time
, end_time
, soft_start_time
i soft_end_time
powinny mieścić się w globalnych limitach czasowych (patrz ShipmentModel.global_start_time
i ShipmentModel.global_end_time
) oraz spełniać te wymagania:
0 <= `start_time` <= `end_time` and
0 <= `start_time` <= `soft_start_time` and
0 <= `soft_end_time` <= `end_time`.
Pola | |
---|---|
start_ |
Czas rozpoczęcia okna czasowego. Jeśli nie podasz żadnej wartości, zostanie użyta wartość |
end_ |
Czas zakończenia sztywnego przedziału czasu. Jeśli nie podasz żadnej wartości, zostanie użyta wartość |
soft_ |
Czas rozpoczęcia przedziału czasu (miękki). |
soft_ |
Czas zakończenia przedziału czasu (miękki). |
cost_ |
Koszt na godzinę dodany do innych kosztów w modelu, jeśli zdarzenie występuje przed wartością soft_start_time, obliczany jako:
Koszt musi być dodatni, a pole może być ustawione tylko wtedy, gdy ustawiono pole soft_start_time. |
cost_ |
Koszt na godzinę dodany do innych kosztów w modelu, jeśli zdarzenie wystąpiło po
Koszt musi być dodatni, a pole można ustawić tylko wtedy, gdy ustawiono |
TransitionAttributes
Określa atrybuty przejść między 2 kolejnymi wizytami na trasie. Do tego samego przejścia może mieć zastosowanie kilka TransitionAttributes
: w takim przypadku wszystkie dodatkowe koszty są sumowane, a następnie stosowany jest najbardziej restrykcyjny warunek lub limit (zgodnie z naturalną semantyką „AND”).
Pola | |
---|---|
src_ |
Tagi definiujące zestaw przejść (src->dst), do których mają zastosowanie te atrybuty. Odpowiednia wizyta w źródle lub uruchomienie pojazdu jest zgodne, jeśli pole |
excluded_ |
Zobacz |
dst_ |
Odpowiednio wizyta w miejscu docelowym lub koniec podróży pasażera jest zgodny, jeśli pole |
excluded_ |
Zobacz |
cost |
Określa koszt wykonania tego przejścia. Jest on podawany w tych samych jednostkach co wszystkie inne koszty w modelu i nie może być ujemny. Jest ona naliczana dodatkowo do wszystkich innych kosztów. |
cost_ |
Określa koszt na kilometr zastosowany do przebytej odległości podczas wykonywania tego przejścia. Dodaje się do wszystkich |
distance_ |
Określa limit pokonywanej odległości podczas wykonywania tego przejścia. Od czerwca 2021 r. obsługiwane są tylko limity miękkie. |
delay |
Określa opóźnienie powstałe podczas wykonywania tego przejścia. To opóźnienie występuje zawsze po zakończeniu wizyty źródłowej i przed rozpoczęciem wizyty docelowej. |
Pojazd
Model pojazdu w przypadku problemu z dostawą. Rozwiązanie problemu z dostawą spowoduje utworzenie trasy dla tego pojazdu, która rozpoczyna się w miejscu start_location
, a kończy w miejscu end_location
. Trasa to sekwencja wizyt (patrz ShipmentRoute
).
Pola | |
---|---|
display_ |
Zdefiniowana przez użytkownika nazwa wyświetlana pojazdu. Może on zawierać maksymalnie 63 znaki i może zawierać znaki UTF-8. |
travel_ |
Tryb podróży, który wpływa na drogi dostępne dla pojazdu i jego prędkość. Zobacz też |
route_ |
Zbiór warunków, które należy spełnić, a które wpływają na sposób obliczania tras dla danego pojazdu. |
start_ |
Geograficzna lokalizacja, w której pojazd rozpoczyna przejazd przed odbiorem przesyłek. Jeśli nie określisz inaczej, pojazd rozpoczyna kurs od pierwszego odbioru. Jeśli model dostawy zawiera macierze czasu i odległości, nie należy podawać parametru |
start_ |
Punkt drogi przedstawiający lokalizację geograficzną, w której pojazd rozpoczyna przejazd przed odbiorem przesyłek. Jeśli nie określono ani właściwości |
end_ |
Miejsce geograficzne, w którym pojazd kończy ostatnią |
end_ |
Punkt drogi reprezentujący lokalizację geograficzną, w której pojazd kończy ostatnią |
start_ |
Określa tagi dołączone do początku trasy pojazdu. Pustych lub powtarzających się ciągów znaków nie można używać. |
end_ |
Określa tagi dołączone na końcu trasy pojazdu. Pustych lub powtarzających się ciągów znaków nie można stosować. |
start_ |
Okna czasowe, w których pojazd może opuścić miejsce początkowe. Muszą mieścić się w globalnych limitach czasowych (patrz pola Przedziały czasu należące do tego samego powtarzającego się pola muszą być rozłączne, czyli żaden z nich nie może się pokrywać z innym ani być sąsiadować z innym. Muszą być uporządkowane chronologicznie. Wartości |
end_ |
Okna czasowe, w których pojazd może dotrzeć do miejsca docelowego. Muszą mieścić się w globalnych limitach czasowych (patrz pola Przedziały czasu należące do tego samego powtarzającego się pola muszą być rozłączne, czyli żaden z nich nie może się pokrywać z innym ani być sąsiadować z innym. Muszą być uporządkowane chronologicznie. Wartości |
unloading_ |
Zasady rozładunku stosowane w pojazdach. |
load_ |
Pojemność pojazdu (np. waga, objętość, liczba palet). Klucze na mapie to identyfikatory typu wczytania zgodne z kluczami pola |
cost_ |
Koszty pojazdu: wszystkie koszty są sumowane i muszą być wyrażone w tej samej jednostce co Koszt godziny przejazdu pojazdu. Koszt ten jest naliczany za cały czas trwania trasy, w tym czas podróży, oczekiwania i wizyty. Używanie operatora |
cost_ |
Koszt godziny przejazdu pojazdu. Ten koszt jest stosowany tylko do czasu przejazdu po trasie (czyli podanego w |
cost_ |
Koszt przejechania 1 km trasy przez pojazd. Ten koszt jest stosowany do odległości podanej w |
fixed_ |
Stałe koszty stosowane, jeśli pojazd jest używany do obsługi przesyłki. |
used_ |
To pole ma zastosowanie tylko do pojazdów, których trasa nie obsługuje żadnych przesyłek. Wskazuje, czy w tym przypadku pojazd powinien być uznany za używany. Jeśli to ustawienie ma wartość true, pojazd jedzie z miejsca początkowego do miejsca docelowego, nawet jeśli nie obsługuje żadnych przesyłek. Uwzględniane są koszty czasu i odległości wynikające z przejazdu od początku do końca. W przeciwnym razie pojazd nie przemieszcza się z punktu początkowego do końcowego i nie ma dla niego zaplanowanego |
route_ |
Limit zastosowany do łącznego czasu trwania trasy pojazdu. W danym |
travel_ |
Ograniczenie czasu trwania przejazdu na trasie pojazdu. W danym |
route_ |
Ograniczenie stosowane do całkowitej odległości przebytej przez pojazd. W danym |
extra_ |
Określa mapę od ciągów znaków visit_types do czasów trwania. Czas trwania to czas dodatkowy do Jeśli prośba o wizytę ma kilka typów, na mapie zostanie dodany czas trwania dla każdego z nich. |
break_ |
Opisuje harmonogram przerw, który ma być stosowany w tym pojeździe. Jeśli pole jest puste, dla tego pojazdu nie będą planowane żadne przerwy. |
label |
Określa etykietę tego pojazdu. Ta etykieta jest raportowana w odpowiedzi jako |
ignore |
Jeśli wartość Jeśli przesyłka jest realizowana przez pojazd ignorowany w sekcji Jeśli dostawa jest realizowana przez pojazd ignorowany w |
travel_ |
Określa współczynnik mnożenia, który może być używany do zwiększania lub zmniejszania czasu przejazdu tego pojazdu. Ustawienie tej wartości na 2,0 oznacza, że pojazd jest wolniejszy i czas podróży jest dwukrotnie dłuższy niż w przypadku standardowych pojazdów. Ten współczynnik nie wpływa na długość wizyty. Wpływa na koszt, jeśli określono OSTRZEŻENIE: czasy przejazdu zostaną zaokrąglone do najbliższej sekundy po zastosowaniu tego wielokrotnego, ale przed wykonaniem jakichkolwiek operacji numerycznych, dlatego małe wielokrotne może spowodować utratę dokładności. Zobacz też |
DurationLimit
Limit określający maksymalny czas trwania trasy pojazdu. Może być twardy lub miękki.
Gdy zdefiniujesz pole z miękkim limitem, musisz zdefiniować zarówno miękki maksymalny próg, jak i powiązany z nim koszt.
Pola | |
---|---|
max_ |
Stały limit ograniczający czas trwania do max_duration. |
soft_ |
miękki limit, który nie narzuca maksymalnego czasu trwania, ale w przypadku jego naruszenia powoduje powstanie kosztu trasy; Ten koszt jest sumowany z innymi kosztami zdefiniowanymi w modelu, przy użyciu tej samej jednostki. Jeśli jest zdefiniowana, wartość |
quadratic_ |
Miękki limit, który nie narzuca maksymalnego czasu trwania, ale w przypadku jego przekroczenia powoduje, że trasa powoduje koszt proporcjonalny do kwadratu czasu. Ten koszt jest sumowany z innymi kosztami zdefiniowanymi w modelu, przy użyciu tej samej jednostki. Jeśli jest zdefiniowana, wartość
|
cost_ |
Koszt na godzinę, jeśli zostanie przekroczony próg
Koszt musi być nieujemny. |
cost_ |
Koszt za godzinę kwadratową, który jest naliczany, gdy przekroczony zostanie próg Jeśli czas trwania jest poniżej progu, dodatkowy koszt wynosi 0. W innych przypadkach koszt zależy od czasu trwania w następujący sposób:
Koszt musi być nieujemny. |
LoadLimit
Określa limit ładunku dla pojazdu, np. „ten samochód może przewozić maksymalnie 3500 kg”. Zobacz load_limits
.
Pola | |
---|---|
soft_ |
Miękki limit obciążenia. Zobacz |
cost_ |
Jeśli ładunek przekroczy wartość |
start_ |
Dopuszczalny przedział ładowania pojazdu na początku trasy. |
end_ |
Dopuszczalny przedział ładowania pojazdu na końcu trasy. |
max_ |
Maksymalny dopuszczalny ładunek. |
Interwał
Przedział dopuszczalnych wartości obciążenia.
Pola | |
---|---|
min |
minimalny dopuszczalny ładunek; Wartość musi być większa lub równa 0. Jeśli oba parametry są określone, wartość |
max |
Maksymalny dopuszczalny ładunek. Wartość musi być większa lub równa 0. Jeśli nie podasz maksymalnego obciążenia, wiadomość nie będzie nakładać żadnych ograniczeń. Jeśli oba parametry są określone, wartość |
TravelMode
Tryby podróży, z których mogą korzystać pojazdy.
Powinny to być podzbiór preferowanych trybów podróży interfejsu API Routes na platformie Google Maps. Szczegóły: https://developers.google.com/maps/documentation/routes_preferred/reference/rest/Shared.Types/RouteTravelMode.
Wartości w polu enum | |
---|---|
TRAVEL_MODE_UNSPECIFIED |
Nieokreślony środek transportu, równoważny z DRIVING . |
DRIVING |
Tryb podróży odpowiadający wskazówkom dojazdu (samochód, ...). |
WALKING |
Tryb podróży odpowiadający wskazówkom dojazdu pieszo. |
UnloadingPolicy
Zasady dotyczące rozładunku pojazdu. Dotyczy tylko przesyłek, które obejmują zarówno odbiór, jak i dostawę.
Inne przesyłki mogą być dostarczane w dowolnym miejscu na trasie niezależnie od unloading_policy
.
Wartości w polu enum | |
---|---|
UNLOADING_POLICY_UNSPECIFIED |
Nieokreślona polityka rozładunku; dostawy muszą odbywać się po odpowiednich odbiorach. |
LAST_IN_FIRST_OUT |
Dostawy muszą odbywać się w odwrotnej kolejności odbioru |
FIRST_IN_FIRST_OUT |
Dostawy muszą odbywać się w tej samej kolejności co odbiory |
Punkt pośredni
Zawiera punkt na trasie. Punkty kontrolne oznaczają miejsca przyjazdu i odjazdu dotyczące żądań wizyty oraz miejsca początkowe i końcowe dotyczące pojazdów.
Pola | |
---|---|
side_ |
Opcjonalnie: Wskazuje, że lokalizacja tego punktu kontrolnego ma być preferowaną lokalizacją dla pojazdu, aby zatrzymał się on po konkretnej stronie drogi. Gdy ustawisz tę wartość, trasa będzie przebiegać przez lokalizację, aby pojazd mógł się zatrzymać po tej stronie drogi, po której znajduje się ta lokalizacja, z dala od środka jezdni. Ta opcja nie działa w przypadku trybu „Chodzenie”. |
Pole unii location_type . różne sposoby przedstawiania lokalizacji; location_type może być tylko jednym z tych elementów: |
|
location |
Punkt określony za pomocą współrzędnych geograficznych, w tym opcjonalnego nagłówka. |
place_ |
Identyfikator miejsca docelowego powiązany z punktem drogi. |