Package google.maps.routeoptimization.v1

Index

RouteOptimization

Ein Dienst zur Optimierung von Fahrzeugrouten.

Gültigkeit bestimmter Feldtypen:

  • google.protobuf.Timestamp
    • Die Zeiten sind in Unix-Zeit angegeben: Sekunden seit 1970-01-01T00:00:00+00:00.
    • „seconds“ muss im Bereich [0, 253402300799] liegen, d.h. im Bereich [1970-01-01T00:00:00+00:00, 9999-12-31T23:59:59+00:00].
    • „nanos“ muss nicht festgelegt oder auf 0 gesetzt sein.
  • google.protobuf.Duration
    • „seconds“ muss im Bereich [0, 253402300799] liegen, d.h. im Bereich [1970-01-01T00:00:00+00:00, 9999-12-31T23:59:59+00:00].
    • „nanos“ muss nicht festgelegt oder auf 0 gesetzt sein.
  • google.type.LatLng
    • Der Breitengrad muss im Bereich [-90,0, 90,0] liegen.
    • Der Längengrad muss im Bereich [-180,0, 180,0] liegen.
    • Mindestens einer der Werte für Breiten- und Längengrad muss ungleich null sein.
BatchOptimizeTours

rpc BatchOptimizeTours(BatchOptimizeToursRequest) returns (Operation)

Optimiert Fahrzeugrouten für eine oder mehrere OptimizeToursRequest-Nachrichten als Batch.

Diese Methode ist ein Vorgang mit langer Ausführungszeit. Die Eingaben für die Optimierung (OptimizeToursRequest-Nachrichten) und Ausgaben (OptimizeToursResponse-Nachrichten) werden in einem vom Nutzer angegebenen Format aus Cloud Storage gelesen und in Cloud Storage geschrieben. Wie bei der Methode OptimizeTours enthält jede OptimizeToursRequest eine ShipmentModel und gibt eine OptimizeToursResponse mit ShipmentRoute-Feldern zurück. Dabei handelt es sich um eine Reihe von Routen, die von Fahrzeugen gefahren werden sollen, um die Gesamtkosten zu minimieren.

Der Nutzer kann operations.get abfragen, um den Status des LRO zu prüfen:

Wenn das Feld done des LRO „false“ ist, wird mindestens eine Anfrage noch verarbeitet. Andere Anfragen wurden möglicherweise erfolgreich abgeschlossen und ihre Ergebnisse sind in Cloud Storage verfügbar.

Wenn das Feld done des LRO den Wert „true“ hat, wurden alle Anfragen verarbeitet. Die Ergebnisse aller erfolgreich verarbeiteten Anfragen sind in Cloud Storage verfügbar. Für fehlgeschlagene Anfragen sind keine Ergebnisse in Cloud Storage verfügbar. Wenn das Feld error des LRO festgelegt ist, enthält es den Fehler einer der fehlgeschlagenen Anfragen.

Autorisierungsbereiche

Erfordert den folgenden OAuth-Bereich:

  • https://www.googleapis.com/auth/cloud-platform
IAM-Berechtigungen

Erfordert die folgende IAM-Berechtigung für die Ressource parent:

  • routeoptimization.operations.create

Weitere Informationen finden Sie in der IAM-Dokumentation.

OptimizeTours

rpc OptimizeTours(OptimizeToursRequest) returns (OptimizeToursResponse)

Sendet eine OptimizeToursRequest mit einer ShipmentModel und gibt eine OptimizeToursResponse mit ShipmentRoute zurück. Das sind eine Reihe von Routen, die von Fahrzeugen gefahren werden sollen, um die Gesamtkosten zu minimieren.

Ein ShipmentModel-Modell besteht hauptsächlich aus Shipments, die ausgeführt werden müssen, und Vehicles, mit denen die Shipments transportiert werden können. Die ShipmentRoutes weisen Shipments Vehicles zu. Genauer gesagt wird jedem Fahrzeug eine Reihe von Visits zugewiesen, wobei ein Visit einem VisitRequest entspricht, also einer Abholung oder Lieferung für ein Shipment.

Ziel ist es, ShipmentRoutes Vehicles zuzuweisen, um die Gesamtkosten zu minimieren. Die Kosten haben viele Komponenten, die in der ShipmentModel definiert sind.

Autorisierungsbereiche

Erfordert den folgenden OAuth-Bereich:

  • https://www.googleapis.com/auth/cloud-platform
IAM-Berechtigungen

Erfordert die folgende IAM-Berechtigung für die Ressource parent:

  • routeoptimization.locations.use

Weitere Informationen finden Sie in der IAM-Dokumentation.

OptimizeToursLongRunning

rpc OptimizeToursLongRunning(OptimizeToursRequest) returns (Operation)

Dies ist eine Variante der OptimizeTours-Methode, die für Optimierungen mit großen Zeitüberschreitungswerten entwickelt wurde. Sie sollte für Optimierungen, die länger als ein paar Minuten dauern, der OptimizeTours-Methode vorgezogen werden.

Die zurückgegebene LRO (long-running operation) hat einen Namen im Format <parent>/operations/<operation_id> und kann verwendet werden, um den Fortschritt der Berechnung zu verfolgen. Der Feldtyp metadata ist OptimizeToursLongRunningMetadata. Der Feldtyp response ist OptimizeToursResponse, falls die Berechnung erfolgreich ist.

Experimentell: Weitere Informationen finden Sie unter https://developers.google.com/maps/tt/route-optimization/experimental/otlr/make-request.

Autorisierungsbereiche

Erfordert den folgenden OAuth-Bereich:

  • https://www.googleapis.com/auth/cloud-platform
IAM-Berechtigungen

Erfordert die folgende IAM-Berechtigung für die Ressource parent:

  • routeoptimization.operations.create

Weitere Informationen finden Sie in der IAM-Dokumentation.

OptimizeToursUri

rpc OptimizeToursUri(OptimizeToursUriRequest) returns (Operation)

Dies ist eine Variante der OptimizeToursLongRunning-Methode, die für Optimierungen mit großen Zeitüberschreitungswerten und großen Ein-/Ausgabegrößen entwickelt wurde.

Der Client gibt den URI des in Google Cloud Storage gespeicherten OptimizeToursRequest an und der Server schreibt das OptimizeToursResponse in einen vom Client angegebenen Google Cloud Storage-URI.

Diese Methode sollte für Optimierungen, die länger als einige Minuten dauern, und für Ein-/Ausgabegrößen, die größer als 8 MB sind, der OptimizeTours-Methode vorgezogen werden. Sie kann aber auch für kürzere und kleinere Optimierungen verwendet werden.

Die zurückgegebene LRO (long-running operation) hat einen Namen im Format <parent>/operations/<operation_id> und kann verwendet werden, um den Fortschritt der Berechnung zu verfolgen. Der Feldtyp metadata ist OptimizeToursLongRunningMetadata. Der Feldtyp response ist OptimizeToursUriResponse, falls die Berechnung erfolgreich ist.

Experimentell: Weitere Informationen finden Sie unter https://developers.google.com/maps/tt/route-optimization/experimental/otlr/make-request.

Autorisierungsbereiche

Erfordert den folgenden OAuth-Bereich:

  • https://www.googleapis.com/auth/cloud-platform
IAM-Berechtigungen

Erfordert die folgende IAM-Berechtigung für die Ressource parent:

  • routeoptimization.operations.create

Weitere Informationen finden Sie in der IAM-Dokumentation.

AggregatedMetrics

Zusammengefasste Messwerte für ShipmentRoute (bzw. für OptimizeToursResponse) für alle Transition- und/oder Visit-Elemente (bzw. für alle ShipmentRoute-Elemente).

Felder
performed_shipment_count

int32

Anzahl der durchgeführten Sendungen. Ein Abhol- und Lieferpaar wird nur einmal gezählt.

travel_duration

Duration

Die gesamte Reisedauer für eine Route oder Lösung.

wait_duration

Duration

Die gesamte Wartezeit für eine Route oder eine Lösung.

delay_duration

Duration

Die Gesamtdauer der Verzögerung für eine Route oder Lösung.

break_duration

Duration

Die Gesamtpausendauer für eine Route oder Lösung.

visit_duration

Duration

Die Gesamtdauer eines Besuchs für eine Route oder eine Lösung.

total_duration

Duration

Die Gesamtdauer sollte der Summe aller oben genannten Zeiträume entsprechen. Bei Routen entspricht es außerdem:

[ShipmentRoute.vehicle_end_time][google.maps.routeoptimization.v1.ShipmentRoute.vehicle_end_time] - [ShipmentRoute.vehicle_start_time][google.maps.routeoptimization.v1.ShipmentRoute.vehicle_start_time]
travel_distance_meters

double

Die insgesamt zurückgelegte Strecke für eine Route oder Lösung.

max_loads

map<string, VehicleLoad>

Die maximale Belastung, die auf der gesamten Route (bzw. Lösung) erreicht wird, für jede der Mengen auf dieser Route (bzw. Lösung), berechnet als das Maximum über alle Transition.vehicle_loads (bzw. ShipmentRoute.metrics.max_loads.

performed_mandatory_shipment_count

int32

Anzahl der durchgeführten Pflichtsendungen.

Testphase: Das Verhalten oder die Existenz dieses Felds kann sich in Zukunft ändern.

performed_shipment_penalty_cost_sum

double

Die Summe der Shipment.penalty_cost der durchgeführten Sendungen.

Testphase: Das Verhalten oder die Existenz dieses Felds kann sich in Zukunft ändern.

BatchOptimizeToursMetadata

Dieser Typ hat keine Felder.

Vorgangsmetadaten für BatchOptimizeToursRequest-Aufrufe.

BatchOptimizeToursRequest

Anfrage zum Batch-Optimieren von Touren als asynchronen Vorgang. Jede Eingabedatei sollte ein OptimizeToursRequest enthalten und jede Ausgabedatei ein OptimizeToursResponse. Die Anfrage enthält Informationen zum Lesen/Schreiben und Parsen der Dateien. Alle Ein- und Ausgabedateien sollten sich im selben Projekt befinden.

Felder
parent

string

Erforderlich. Zielprojekt und Standort zum Anrufen festlegen.

Format:

  • projects/{project-id}
  • projects/{project-id}/locations/{location-id}

Wenn kein Ort angegeben ist, wird automatisch eine Region ausgewählt.

model_configs[]

AsyncModelConfig

Erforderlich. Informationen zu Ein- und Ausgabe für jedes Kaufmodell, z. B. Dateipfade und Datenformate.

AsyncModelConfig

Informationen zum asynchronen Lösen eines Optimierungsmodells.

Felder
display_name

string

Optional. Benutzerdefinierter Modellname, der von Nutzern als Alias verwendet werden kann, um Modelle im Blick zu behalten.

input_config

InputConfig

Erforderlich. Informationen zum Eingabemodell.

output_config

OutputConfig

Erforderlich. Die gewünschten Standortinformationen für die Ausgabe.

BatchOptimizeToursResponse

Dieser Typ hat keine Felder.

Antwort auf eine BatchOptimizeToursRequest. Dieser Wert wird im Vorgang mit langer Ausführungszeit zurückgegeben, nachdem der Vorgang abgeschlossen ist.

BreakRule

Regeln zum Generieren von Zeitunterbrechungen für ein Fahrzeug, z.B. Mittagspausen. Eine Pause ist ein zusammenhängender Zeitraum, in dem das Fahrzeug an seiner aktuellen Position inaktiv bleibt und keinen Besuch durchführen kann. Eine Unterbrechung kann folgende Ursachen haben:

  • während der Reise zwischen zwei Besuchen (einschließlich der Zeit unmittelbar vor oder nach einem Besuch, aber nicht in der Mitte eines Besuchs). In diesem Fall wird die entsprechende Transitzeit zwischen den Besuchen verlängert.
  • oder vor dem Start des Fahrzeugs (das Fahrzeug darf nicht mitten in einer Pause starten). In diesem Fall hat dies keine Auswirkungen auf die Startzeit des Fahrzeugs.
  • oder nach dem Ende der Fahrt (siehe oben, mit der Endzeit der Fahrt).
Felder
break_requests[]

BreakRequest

Reihenfolge der Pausen. Sehen Sie sich die Meldung BreakRequest an.

frequency_constraints[]

FrequencyConstraint

Es können mehrere FrequencyConstraint gelten. Sie müssen alle durch die BreakRequest dieses BreakRule erfüllt werden. Siehe FrequencyConstraint.

BreakRequest

Die Reihenfolge der Pausen (d.h. ihre Anzahl und Reihenfolge), die für jedes Fahrzeug gelten, muss im Voraus bekannt sein. Die wiederholten BreakRequests definieren diese Sequenz in der Reihenfolge, in der sie auftreten müssen. Die Zeiträume (earliest_start_time / latest_start_time) können sich überschneiden, müssen aber mit der Reihenfolge kompatibel sein (das wird geprüft).

Felder
earliest_start_time

Timestamp

Erforderlich. Inklusive Untergrenze für den Beginn der Pause.

latest_start_time

Timestamp

Erforderlich. Obergrenze (einschließlich) für den Beginn der Pause.

min_duration

Duration

Erforderlich. Mindestdauer der Pause. Muss positiv sein.

FrequencyConstraint

Die oben angegebene Häufigkeit und Dauer der Pausen kann weiter eingeschränkt werden, indem eine Mindestpausenhäufigkeit festgelegt wird, z. B. „Alle 12 Stunden muss eine Pause von mindestens einer Stunde eingelegt werden“. Wenn wir davon ausgehen, dass dies als „In einem beliebigen gleitenden Zeitfenster von 12 Stunden muss es mindestens eine Pause von mindestens einer Stunde geben“ interpretiert werden kann, würde das Beispiel in die folgende FrequencyConstraint übersetzt:

{
   min_break_duration { seconds: 3600 }         # 1 hour.
   max_inter_break_duration { seconds: 39600 }  # 11 hours (12 - 1 = 11).
}

Das Timing und die Dauer der Pausen in der Lösung berücksichtigen alle diese Einschränkungen sowie die bereits in der BreakRequest angegebenen Zeitfenster und Mindestdauern.

Eine FrequencyConstraint kann in der Praxis auch für nicht aufeinanderfolgende Pausen gelten. Im folgenden Zeitplan wird beispielsweise die Regel „1 Stunde alle 12 Stunden“ eingehalten:

  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
Felder
min_break_duration

Duration

Erforderlich. Mindestdauer der Pause für diese Einschränkung. Nicht negativ. Siehe Beschreibung von FrequencyConstraint.

max_inter_break_duration

Duration

Erforderlich. Die maximal zulässige Dauer eines beliebigen Zeitintervalls auf der Route, das nicht mindestens teilweise eine Pause von duration >= min_break_duration umfasst. Muss positiv sein.

DataFormat

Datenformate für Ein- und Ausgabedateien.

Enums
DATA_FORMAT_UNSPECIFIED Ungültiger Wert. Das Format darf nicht UNSPECIFIED sein.
JSON JavaScript Object Notation.
PROTO_TEXT Textformat für Protokollpuffer. Weitere Informationen finden Sie unter https://protobuf.dev/reference/protobuf/textformat-spec/.

DistanceLimit

Ein Limit, das eine maximale Entfernung definiert, die zurückgelegt werden kann. Es kann entweder hart oder weich sein.

Wenn ein Soft Limit definiert ist, müssen sowohl soft_max_meters als auch cost_per_kilometer_above_soft_max definiert und nicht negativ sein.

Felder
max_meters

int64

Eine harte Beschränkung, die die Entfernung auf höchstens „max_meters“ begrenzt. Das Limit muss nicht negativ sein.

soft_max_meters

int64

Ein weiches Limit erzwingt kein maximales Distanzlimit, führt aber bei Überschreitung zu Kosten, die sich mit anderen im Modell definierten Kosten mit derselben Einheit summieren.

Wenn „soft_max_meters“ definiert ist, muss der Wert kleiner als „max_meters“ und nicht negativ sein.

cost_per_kilometer_below_soft_max

double

Anfallende Kosten pro Kilometer, die bis zu soft_max_meters steigen, mit folgender Formel:

  min(distance_meters, soft_max_meters) / 1000.0 *
  cost_per_kilometer_below_soft_max.

Diese Kosten werden in route_distance_limit nicht unterstützt.

cost_per_kilometer_above_soft_max

double

Kosten pro Kilometer, die anfallen, wenn die Entfernung das Limit von soft_max_meters überschreitet. Die zusätzlichen Kosten betragen 0, wenn die Entfernung unter dem Limit liegt. Andernfalls wird die folgende Formel zur Berechnung der Kosten verwendet:

  (distance_meters - soft_max_meters) / 1000.0 *
  cost_per_kilometer_above_soft_max.

Die Kosten dürfen nicht negativ sein.

GcsDestination

Der Google Cloud Storage-Speicherort, in den die Ausgabedatei(en) geschrieben werden.

Felder
uri

string

Erforderlich. Google Cloud Storage-URI.

GcsSource

Der Google Cloud Storage-Speicherort, aus dem die Eingabedatei gelesen wird.

Felder
uri

string

Erforderlich. URI eines Google Cloud Storage-Objekts im Format gs://bucket/path/to/object.

InjectedSolutionConstraint

Die Lösung wird in die Anfrage eingefügt. Sie enthält Informationen dazu, welche Besuche eingeschränkt werden müssen und wie.

Felder
routes[]

ShipmentRoute

Routen der einzuschleusenden Lösung. Einige Routen werden möglicherweise aus der ursprünglichen Lösung ausgelassen. Die Routen und übersprungenen Sendungen müssen die für injected_first_solution_routes aufgeführten grundlegenden Gültigkeitsannahmen erfüllen.

skipped_shipments[]

SkippedShipment

Übersprungene Sendungen der einzufügenden Lösung. Einige werden möglicherweise aus der ursprünglichen Lösung ausgelassen. Weitere Informationen finden Sie im Feld routes.

constraint_relaxations[]

ConstraintRelaxation

Gibt für null oder mehr Fahrzeuggruppen an, wann und wie stark Einschränkungen gelockert werden sollen. Wenn dieses Feld leer ist, unterliegen alle nicht leeren Fahrzeugrouten vollständigen Einschränkungen.

ConstraintRelaxation

Gibt für eine Gruppe von Fahrzeugen an, bei welchem Schwellenwert bzw. welchen Schwellenwerten die Einschränkungen für Besuche gelockert werden und auf welches Niveau. Lieferungen, die im Feld skipped_shipment aufgeführt sind, müssen übersprungen werden, d.h., sie können nicht ausgeführt werden.

Felder
relaxations[]

Relaxation

Alle Lockerungen der Besuchseinschränkungen, die für Besuche auf Routen mit Fahrzeugen in vehicle_indices gelten.

vehicle_indices[]

int32

Gibt die Fahrzeugindexe an, für die die Besuchsrestriktion relaxations gilt. Wenn leer, gilt dies als Standard und die relaxations gelten für alle Fahrzeuge, die nicht in anderen constraint_relaxations angegeben sind. Es darf maximal einen Standardwert geben, d.h., maximal ein Feld für die Lockerung von Einschränkungen darf leer sein vehicle_indices. Ein Fahrzeugindex kann nur einmal aufgeführt werden, auch wenn er in mehreren constraint_relaxations enthalten ist.

Ein Fahrzeugindex wird genauso wie ShipmentRoute.vehicle_index zugeordnet, wenn interpret_injected_solutions_using_labels „true“ ist (siehe Kommentar zu fields).

Entspannung

Wenn relaxations leer ist, sind die Startzeit und die Reihenfolge aller Besuche in routes vollständig eingeschränkt. Es dürfen keine neuen Besuche in diese Routen eingefügt oder hinzugefügt werden. Außerdem sind die Start- und Endzeit eines Fahrzeugs in routes vollständig eingeschränkt, es sei denn, das Fahrzeug ist leer (d. h., es hat keine Besuche und used_if_route_is_empty ist im Modell auf „false“ gesetzt).

relaxations(i).level gibt das Niveau der Einschränkungslockerung an, das auf einen Besuch #j angewendet wird, der die folgenden Bedingungen erfüllt:

  • route.visits(j).start_time >= relaxations(i).threshold_time UND
  • j + 1 >= relaxations(i).threshold_visit_count

Analog dazu wird der Fahrzeugstart auf relaxations(i).level verschoben, wenn Folgendes gilt:

  • vehicle_start_time >= relaxations(i).threshold_time UND
  • relaxations(i).threshold_visit_count == 0 und das Fahrzeugende wird auf relaxations(i).level gelockert, wenn Folgendes zutrifft:
  • vehicle_end_time >= relaxations(i).threshold_time UND
  • route.visits_size() + 1 >= relaxations(i).threshold_visit_count

Wenn Sie eine Lockerungsstufe anwenden möchten, wenn ein Besuch die threshold_visit_count ODER die threshold_time erfüllt, fügen Sie zwei relaxations mit derselben level hinzu: eine mit nur threshold_visit_count und die andere mit nur threshold_time. Wenn ein Besuch die Bedingungen mehrerer relaxations erfüllt, wird die am wenigsten restriktive Ebene angewendet. Daher wird das Entspannungsniveau vom Fahrzeugstart über die Routenbesuche bis zum Fahrzeugende immer entspannter, d.h., es nimmt im Laufe der Route nicht ab.

Die Zeitplanung und Reihenfolge der Routenbesuche, die die Schwellenwertbedingungen von relaxations nicht erfüllen, sind vollständig eingeschränkt und es dürfen keine Besuche in diese Sequenzen eingefügt werden. Wenn der Start oder das Ende eines Fahrzeugs nicht den Bedingungen einer Lockerung entspricht, wird die Zeit festgelegt, sofern das Fahrzeug nicht leer ist.

Felder
level

Level

Die Stufe der Einschränkungsaufhebung, die angewendet wird, wenn die Bedingungen bei oder nach threshold_time UND mindestens threshold_visit_count erfüllt sind.

threshold_time

Timestamp

Die Zeit, zu der oder nach der die Lockerung level angewendet werden kann.

threshold_visit_count

int32

Die Anzahl der Besuche, nach denen die Lockerung level angewendet werden kann. Wenn threshold_visit_count = 0 (oder nicht festgelegt) ist, kann level direkt beim Start des Fahrzeugs angewendet werden.

Wenn es route.visits_size() + 1 ist, darf die level nur auf das Fahrzeugende angewendet werden. Wenn sie mehr als route.visits_size() + 1 beträgt, wird level für diese Route überhaupt nicht angewendet.

Level

Gibt die verschiedenen Stufen der Einschränkungslockerung an, die für einen Besuch und die nachfolgenden Besuche angewendet werden, wenn die Schwellenwertbedingungen erfüllt sind.

Die Aufzählung unten erfolgt in der Reihenfolge der zunehmenden Lockerung.

Enums
LEVEL_UNSPECIFIED

Implizites Standard-Relaxierungsniveau: Es werden keine Einschränkungen gelockert, d.h. alle Besuche sind vollständig eingeschränkt.

Dieser Wert darf in level nicht explizit verwendet werden.

RELAX_VISIT_TIMES_AFTER_THRESHOLD Die Startzeiten für Besuche und Fahrzeuge werden flexibler, aber jeder Besuch ist weiterhin an dasselbe Fahrzeug gebunden und die Reihenfolge der Besuche muss eingehalten werden. Es darf kein Besuch dazwischen oder davor eingefügt werden.
RELAX_VISIT_TIMES_AND_SEQUENCE_AFTER_THRESHOLD Wie RELAX_VISIT_TIMES_AFTER_THRESHOLD, aber die Besuchsreihenfolge ist ebenfalls gelockert: Besuche können nur von diesem Fahrzeug durchgeführt werden, können aber möglicherweise nicht durchgeführt werden.
RELAX_ALL_AFTER_THRESHOLD Wie RELAX_VISIT_TIMES_AND_SEQUENCE_AFTER_THRESHOLD, aber das Fahrzeug ist auch entspannt: Besuche sind ab der Schwelle kostenlos und können möglicherweise nicht durchgeführt werden.

InputConfig

Geben Sie eine Eingabe für [BatchOptimizeTours][google.maps.routeoptimization.v1.RouteOptimizationService.BatchOptimizeTours] an.

Felder
data_format

DataFormat

Erforderlich. Das Datenformat der Eingabe.

Union-Feld source. Erforderlich. Für source ist nur einer der folgenden Werte zulässig:
gcs_source

GcsSource

Ein Google Cloud Storage-Speicherort. Es muss sich um ein einzelnes Objekt (eine Datei) handeln.

Standort

Kapselt einen Standort (einen geografischen Punkt und eine optionale Ausrichtung).

Felder
lat_lng

LatLng

Die geografischen Koordinaten des Wegpunkts.

heading

int32

Die Kompassrichtung, die der Richtung des Verkehrsflusses entspricht. Dieser Wert wird verwendet, um die Straßenseite für die Abholung und den Rückgabeort anzugeben. Die Werte für die Richtung können zwischen 0 und 360 liegen, wobei 0 für Norden, 90 für Osten usw. steht.

OptimizeToursLongRunningMetadata

Dieser Typ hat keine Felder.

Vorgangsmetadaten für OptimizeToursLongRunning-Aufrufe.

OptimizeToursRequest

Anfrage, die an einen Solver für die Tourenoptimierung gesendet wird und das zu lösende Versandmodell sowie Optimierungsparameter definiert.

Felder
parent

string

Erforderlich. Zielprojekt oder Standort zum Anrufen festlegen.

Format:

  • projects/{project-id}
  • projects/{project-id}/locations/{location-id}

Wenn kein Ort angegeben ist, wird automatisch eine Region ausgewählt.

timeout

Duration

Wenn dieses Zeitlimit festgelegt ist, gibt der Server eine Antwort zurück, bevor das Zeitlimit abgelaufen ist oder die Serverfrist für synchrone Anfragen erreicht ist, je nachdem, was zuerst eintritt.

Bei asynchronen Anfragen generiert der Server (falls möglich) eine Lösung, bevor das Zeitlimit abläuft.

model

ShipmentModel

Das zu lösende Versandmodell.

solving_mode

SolvingMode

Standardmäßig ist der Lösungsmodus DEFAULT_SOLVE (0).

search_mode

SearchMode

Der Suchmodus, der zum Beantworten der Anfrage verwendet wurde.

injected_first_solution_routes[]

ShipmentRoute

Den Optimierungsalgorithmus dabei unterstützen, eine erste Lösung zu finden, die einer früheren Lösung ähnelt.

Das Modell wird eingeschränkt, wenn die erste Lösung erstellt wird. Alle Sendungen, die nicht auf einer Route ausgeführt werden, werden in der ersten Lösung implizit übersprungen, können aber in nachfolgenden Lösungen ausgeführt werden.

Die Lösung muss einige grundlegende Gültigkeitsannahmen erfüllen:

  • Bei allen Routen muss vehicle_index im Bereich liegen und darf nicht dupliziert werden.
  • Bei allen Besuchen müssen shipment_index und visit_request_index im Bereich liegen.
  • Auf eine Sendung darf nur in einer Route verwiesen werden.
  • Die Abholung einer Sendung mit Abholung und Zustellung muss vor der Zustellung erfolgen.
  • Es darf nur eine Abhol- oder Lieferalternative für eine Sendung durchgeführt werden.
  • Bei allen Routen verlängern sich die Zeiten (z.B. vehicle_start_time <= visits[0].start_time <= visits[1].start_time ... <= vehicle_end_time).
  • Eine Lieferung darf nur mit einem zulässigen Fahrzeug erfolgen. Ein Fahrzeug ist zulässig, wenn Shipment.allowed_vehicle_indices leer ist oder seine vehicle_index in Shipment.allowed_vehicle_indices enthalten ist.

Wenn die eingefügte Lösung nicht praktikabel ist, wird nicht unbedingt ein Validierungsfehler zurückgegeben. Stattdessen kann ein Fehler zurückgegeben werden, der auf die Unmöglichkeit hinweist.

injected_solution_constraint

InjectedSolutionConstraint

Den Optimierungsalgorithmus so einschränken, dass er eine Endlösung findet, die einer vorherigen Lösung ähnelt. Dies kann beispielsweise verwendet werden, um Abschnitte von Routen einzufrieren, die bereits abgeschlossen wurden oder abgeschlossen werden sollen, aber nicht geändert werden dürfen.

Wenn die eingefügte Lösung nicht praktikabel ist, wird nicht unbedingt ein Validierungsfehler zurückgegeben. Stattdessen kann ein Fehler zurückgegeben werden, der auf die Unmöglichkeit hinweist.

refresh_details_routes[]

ShipmentRoute

Wenn nicht leer, werden die angegebenen Routen aktualisiert, ohne dass die zugrunde liegende Reihenfolge der Besuche oder Reisezeiten geändert wird. Es werden nur andere Details aktualisiert. Das Modell wird dadurch nicht gelöst.

Seit November 2020 werden damit nur die Polylinien von nicht leeren Routen ausgefüllt. Außerdem muss populate_polylines auf „true“ gesetzt sein.

Die route_polyline-Felder der übergebenen Routen stimmen möglicherweise nicht mit der Route transitions überein.

Dieses Feld darf nicht zusammen mit injected_first_solution_routes oder injected_solution_constraint verwendet werden.

Shipment.ignore und Vehicle.ignore haben keine Auswirkungen auf das Verhalten. Polylinien werden weiterhin zwischen allen Besuchen auf allen nicht leeren Routen eingefügt, unabhängig davon, ob die zugehörigen Sendungen oder Fahrzeuge ignoriert werden.

interpret_injected_solutions_using_labels

bool

Falls zutreffend:

Diese Interpretation gilt für die Felder injected_first_solution_routes, injected_solution_constraint und refresh_details_routes. Sie kann verwendet werden, wenn sich die Versand- oder Fahrzeugindexe in der Anfrage seit der Erstellung der Lösung geändert haben, z. B. weil Sendungen oder Fahrzeuge aus der Anfrage entfernt oder ihr hinzugefügt wurden.

Bei „true“ dürfen Labels in den folgenden Kategorien höchstens einmal in ihrer Kategorie vorkommen:

Wenn ein vehicle_label in der eingefügten Lösung nicht einem angeforderten Fahrzeug entspricht, wird die entsprechende Route zusammen mit den zugehörigen Besuchen aus der Lösung entfernt. Wenn ein shipment_label in der eingefügten Lösung nicht mit einer Anfrage für den Versand übereinstimmt, wird der entsprechende Besuch aus der Lösung entfernt. Wenn ein SkippedShipment.label in der eingefügten Lösung nicht mit einer angeforderten Sendung übereinstimmt, wird das SkippedShipment aus der Lösung entfernt.

Wenn Sie Routenbesuche oder ganze Routen aus einer eingefügten Lösung entfernen, kann sich das auf die impliziten Einschränkungen auswirken. Das kann zu einer Änderung der Lösung, zu Validierungsfehlern oder zu einer Unmöglichkeit führen.

HINWEIS: Der Aufrufer muss dafür sorgen, dass jede Vehicle.label (bzw. Shipment.label) eine Fahrzeug- (bzw. Sendungs-)Entität eindeutig identifiziert, die in den beiden relevanten Anfragen verwendet wird: der vorherigen Anfrage, die die in die eingefügte Lösung verwendete OptimizeToursResponse generiert hat, und der aktuellen Anfrage, die die eingefügte Lösung enthält. Die oben beschriebenen Eindeutigkeitsprüfungen reichen nicht aus, um diese Anforderung zu erfüllen.

consider_road_traffic

bool

Berücksichtigen Sie die Traffic-Schätzung bei der Berechnung der Felder ShipmentRoute Transition.travel_duration, Visit.start_time und vehicle_end_time, beim Festlegen des Felds ShipmentRoute.has_traffic_infeasibilities und bei der Berechnung des Felds OptimizeToursResponse.total_cost.

populate_polylines

bool

Wenn „true“, werden Polylinien in Antworten vom Typ ShipmentRoute eingefügt.

populate_transition_polylines

bool

Wenn „true“, werden Polylinien und Routen-Tokens in der Antwort ShipmentRoute.transitions ausgegeben.

allow_large_deadline_despite_interruption_risk

bool

Wenn dieser Wert festgelegt ist, kann die Anfrage eine Frist (siehe https://grpc.io/blog/deadlines) von bis zu 60 Minuten haben. Andernfalls beträgt die maximale Frist nur 30 Minuten. Beachten Sie, dass bei Anfragen mit langer Laufzeit ein deutlich höheres (aber immer noch geringes) Risiko besteht, dass sie unterbrochen werden.

use_geodesic_distances

bool

Wenn „true“, werden Reiseentfernungen mit geodätischen Entfernungen anstelle von Google Maps-Entfernungen berechnet und Reisezeiten mit geodätischen Entfernungen mit einer von geodesic_meters_per_second definierten Geschwindigkeit.

label

string

Label, das zur Identifizierung dieser Anfrage verwendet werden kann und in OptimizeToursResponse.request_label zurückgegeben wird.

geodesic_meters_per_second

double

Wenn use_geodesic_distances „true“ ist, muss dieses Feld festgelegt werden. Es definiert die Geschwindigkeit, die zum Berechnen von Fahrzeiten verwendet wird.Der Wert muss mindestens 1,0 Meter/Sekunde betragen.

max_validation_errors

int32

Kürzt die Anzahl der zurückgegebenen Validierungsfehler. Diese Fehler sind in der Regel an eine INVALID_ARGUMENT-Fehlernutzlast als BadRequest-Fehlerdetail angehängt (https://cloud.google.com/apis/design/errors#error_details), sofern solving_mode=VALIDATE_ONLY ist. Weitere Informationen finden Sie im Feld OptimizeToursResponse.validation_errors. Der Standardwert ist 100 und der Höchstwert 10.000.

SearchMode

Modus, der das Verhalten der Suche definiert und einen Kompromiss zwischen Latenz und Lösungsqualität darstellt. In allen Modi wird die globale Frist für Anfragen eingehalten.

Enums
SEARCH_MODE_UNSPECIFIED Nicht angegebener Suchmodus, entspricht RETURN_FAST.
RETURN_FAST Beenden Sie die Suche, nachdem Sie die erste gute Lösung gefunden haben.
CONSUME_ALL_AVAILABLE_TIME Nutzen Sie die gesamte verfügbare Zeit, um nach besseren Lösungen zu suchen.

SolvingMode

Gibt an, wie der Solver die Anfrage verarbeiten soll. In allen Modi außer VALIDATE_ONLY erhalten Sie bei einer ungültigen Anfrage einen INVALID_REQUEST-Fehler. Mit max_validation_errors können Sie die Anzahl der zurückgegebenen Fehler begrenzen.

Enums
DEFAULT_SOLVE Lösen Sie das Modell. Warnungen können in [OptimizeToursResponse.validation_errors][google.cloud.optimization.v1.OptimizeToursResponse.validation_errors] ausgegeben werden.
VALIDATE_ONLY Das Modell wird nur validiert, ohne es zu lösen. Es werden so viele OptimizeToursResponse.validation_errors wie möglich ausgefüllt.
DETECT_SOME_INFEASIBLE_SHIPMENTS

Es wird nur OptimizeToursResponse.validation_errors oder OptimizeToursResponse.skipped_shipments ausgefüllt und der Rest der Anfrage wird nicht beantwortet (status und routes sind in der Antwort nicht festgelegt). Wenn in injected_solution_constraint-Routen Unregelmäßigkeiten erkannt werden, werden sie im Feld OptimizeToursResponse.validation_errors eingetragen und OptimizeToursResponse.skipped_shipments bleibt leer.

WICHTIG: Hier werden nicht alle nicht durchführbaren Sendungen zurückgegeben, sondern nur diejenigen, die während der Vorverarbeitung als nicht durchführbar erkannt werden.

TRANSFORM_AND_RETURN_REQUEST

Dieser Modus funktioniert nur, wenn ShipmentModel.objectives nicht leer ist. Die Anfrage wurde nicht gelöst. Sie wird nur validiert und mit Kosten entsprechend den angegebenen Zielvorhaben gefüllt. Weitere Informationen finden Sie in der Dokumentation zu ShipmentModel.objectives. Die resultierende Anfrage wird als OptimizeToursResponse.processed_request zurückgegeben.

Experimentell: Weitere Informationen finden Sie unter https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request.

OptimizeToursResponse

Antwort nach der Lösung eines Problems zur Tourenoptimierung mit den Routen der einzelnen Fahrzeuge, den übersprungenen Sendungen und den Gesamtkosten der Lösung.

Felder
routes[]

ShipmentRoute

Für jedes Fahrzeug berechnete Routen. Die i-te Route entspricht dem i-ten Fahrzeug im Modell.

request_label

string

Kopie von OptimizeToursRequest.label, wenn in der Anfrage ein Label angegeben wurde.

skipped_shipments[]

SkippedShipment

Die Liste aller übersprungenen Sendungen.

validation_errors[]

OptimizeToursValidationError

Liste aller Validierungsfehler, die wir unabhängig voneinander erkennen konnten. Weitere Informationen finden Sie in der Erklärung zu „MULTIPLE ERRORS“ für die Meldung OptimizeToursValidationError. Anstelle von Fehlern werden Warnungen angezeigt, wenn solving_mode gleich DEFAULT_SOLVE ist.

processed_request

OptimizeToursRequest

In einigen Fällen ändern wir die eingehende Anfrage, bevor wir sie bearbeiten, z.B. indem wir Kosten hinzufügen. Wenn „solving_mode“ == TRANSFORM_AND_RETURN_REQUEST, wird die geänderte Anfrage hier zurückgegeben.

Experimentell: Weitere Informationen finden Sie unter https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request.

metrics

Metrics

Messwerte für Dauer, Entfernung und Nutzung für diese Lösung.

Messwerte

Gesamtmesswerte, die über alle Routen hinweg aggregiert werden.

Felder
aggregated_route_metrics

AggregatedMetrics

Über die Routen aggregiert. Jeder Messwert ist die Summe (oder der Maximalwert für Lasten) aller ShipmentRoute.metrics-Felder mit demselben Namen.

skipped_mandatory_shipment_count

int32

Anzahl der übersprungenen Pflichtlieferungen.

used_vehicle_count

int32

Anzahl der verwendeten Fahrzeuge. Hinweis: Wenn eine Fahrzeugroute leer ist und Vehicle.used_if_route_is_empty „true“ ist, gilt das Fahrzeug als verwendet.

earliest_vehicle_start_time

Timestamp

Die früheste Startzeit für ein gebrauchtes Fahrzeug, berechnet als das Minimum aller gebrauchten Fahrzeuge von ShipmentRoute.vehicle_start_time.

latest_vehicle_end_time

Timestamp

Die späteste Endzeit für ein Gebrauchtfahrzeug, berechnet als Maximum aller Gebrauchtfahrzeuge von ShipmentRoute.vehicle_end_time.

costs

map<string, double>

Kosten der Lösung, aufgeschlüsselt nach kostenbezogenen Anfragefeldern. Die Schlüssel sind Protopfade relativ zum OptimizeToursRequest-Eingabe, z. B. „model.shipments.pickups.cost“. Die Werte sind die Gesamtkosten, die durch das entsprechende Kostenfeld generiert werden, aggregiert über die gesamte Lösung. Mit anderen Worten: costs["model.shipments.pickups.cost"] ist die Summe aller Abholkosten für die Lösung. Alle im Modell definierten Kosten werden hier detailliert aufgeführt. Ausgenommen sind Kosten im Zusammenhang mit TransitionAttributes, die ab Januar 2022 nur noch aggregiert ausgewiesen werden.

total_cost

double

Gesamtkosten der Lösung. Die Summe aller Werte in der Kostenübersicht.

OptimizeToursUriMetadata

Dieser Typ hat keine Felder.

Vorgangsmetadaten für OptimizeToursUri-Aufrufe.

OptimizeToursUriRequest

Eine Anfrage, die von der Methode OptimizeToursUri verwendet wird.

Felder
parent

string

Erforderlich. Zielprojekt oder Standort zum Anrufen festlegen.

Format:

  • projects/{project-id}
  • projects/{project-id}/locations/{location-id}

Wenn kein Ort angegeben ist, wird automatisch eine Region ausgewählt.

input

Uri

Erforderlich. Der URI des Cloud Storage-Objekts, das OptimizeToursRequest enthält.

output

Uri

Erforderlich. Der URI des Cloud Storage-Objekts, das OptimizeToursResponse enthält.

OptimizeToursUriResponse

Eine Antwort, die von der Methode OptimizeToursUri zurückgegeben wird.

Felder
output

Uri

Optional. Der URI des Cloud Storage-Objekts, das die OptimizeToursResponse enthält, die entweder als JSON oder als Textproto codiert ist. Wenn das Objekt als JSON codiert wurde, lautet die Erweiterung des Objektnamens .json. Wenn das Objekt als Textproto codiert wurde, lautet die Erweiterung des Objektnamens .txtpb.

Mit dem crc32_checksum der Ressource kann überprüft werden, ob die Inhalte der Ressource geändert wurden.

OptimizeToursValidationError

Beschreibt einen Fehler oder eine Warnung, die beim Validieren eines OptimizeToursRequest aufgetreten ist.

Felder
code

int32

Ein Validierungsfehler wird durch das Paar (code, display_name) definiert, das immer vorhanden ist.

Die Felder nach diesem Abschnitt enthalten weitere Informationen zum Fehler.

MULTIPLE ERRORS: Wenn mehrere Fehler vorliegen, werden bei der Validierung mehrere davon ausgegeben. Ähnlich wie bei einem Compiler ist dies ein unvollkommener Prozess. Einige Validierungsfehler sind schwerwiegend und führen dazu, dass der gesamte Validierungsprozess beendet wird. Dies ist u. a. bei display_name="UNSPECIFIED"-Fehlern der Fall. Bei einigen Fehlern werden möglicherweise andere Fehler im Validierungsprozess übersprungen.

STABILITÄT: code und display_name sollten sehr stabil sein. Im Laufe der Zeit können jedoch neue Codes und Anzeigenamen hinzukommen. Dadurch kann es passieren, dass eine bestimmte (ungültige) Anfrage ein anderes (code, display_name)-Paar zurückgibt, weil der neue Fehler den alten verdeckt hat. Beispiel: „MEHRERE FEHLER“.

display_name

string

Der Anzeigename des Fehlers.

fields[]

FieldReference

Ein Fehlerkontext kann 0, 1 (meistens) oder mehrere Felder umfassen. Beispiel: Die erste Abholung von Fahrzeug 4 und Sendung 2 kann so angegeben werden:

fields { name: "vehicles" index: 4}
fields { name: "shipments" index: 2 sub_field {name: "pickups" index: 0} }

Die Kardinalität von fields sollte sich für einen bestimmten Fehlercode jedoch nicht ändern.

error_message

string

Ein für Menschen lesbarer String, der den Fehler beschreibt. Es gibt eine 1:1-Zuordnung zwischen code und error_message (wenn code != „UNSPECIFIED“).

STABILITÄT: Nicht stabil: Die Fehlermeldung, die mit einem bestimmten code verknüpft ist, kann sich im Laufe der Zeit ändern (hoffentlich, um sie zu verdeutlichen). Verwenden Sie stattdessen display_name und code.

offending_values

string

Kann die Werte der Felder enthalten. Das ist nicht immer der Fall. Sie sollten sich nicht darauf verlassen und es nur für das manuelle Debugging von Modellen verwenden.

FieldReference

Gibt einen Kontext für den Validierungsfehler an. Ein FieldReference bezieht sich immer auf ein bestimmtes Feld in dieser Datei und folgt derselben hierarchischen Struktur. Beispiel: Wir geben Element 2 von start_time_windows von Fahrzeug 5 an:

name: "vehicles" index: 5 sub_field { name: "end_time_windows" index: 2 }

Wir lassen jedoch Top-Level-Entitäten wie OptimizeToursRequest oder ShipmentModel weg, um die Nachricht nicht zu überladen.

Felder
name

string

Name des Felds, z.B. „vehicles“.

sub_field

FieldReference

Bei Bedarf rekursiv verschachteltes Unterfeld.

Union-Feld index_or_key.

Für index_or_key ist nur einer der folgenden Werte zulässig:

index

int32

Index des Felds, wenn es wiederholt wird.

key

string

Schlüssel, wenn das Feld eine Karte ist.

OutputConfig

Geben Sie ein Ziel für die Ergebnisse von [BatchOptimizeTours][google.maps.routeoptimization.v1.RouteOptimizationService.BatchOptimizeTours] an.

Felder
data_format

DataFormat

Erforderlich. Das Ausgabedatenformat.

Union-Feld destination. Erforderlich. Für destination ist nur einer der folgenden Werte zulässig:
gcs_destination

GcsDestination

Der Google Cloud Storage-Speicherort, in den die Ausgabe geschrieben wird.

RouteModifiers

Kapselt eine Reihe optionaler Bedingungen, die beim Berechnen von Fahrzeugrouten erfüllt werden müssen. Dies ähnelt RouteModifiers in der Google Maps Platform Routes Preferred API. Weitere Informationen finden Sie unter https://developers.google.com/maps/documentation/routes/reference/rest/v2/RouteModifiers.

Felder
avoid_tolls

bool

Gibt an, ob Mautstraßen nach Möglichkeit vermieden werden sollen. Routen ohne Mautstraßen werden bevorzugt. Gilt nur für motorisierte Fortbewegungsmittel.

avoid_highways

bool

Gibt an, ob Autobahnen nach Möglichkeit vermieden werden sollen. Routen ohne Autobahnen werden bevorzugt. Gilt nur für motorisierte Fortbewegungsmittel.

avoid_ferries

bool

Gibt an, ob Fähren nach Möglichkeit vermieden werden sollen. Routen ohne Fährverbindungen werden bevorzugt. Gilt nur für motorisierte Fortbewegungsmittel.

avoid_indoor

bool

Optional. Gibt an, ob die Navigation in Innenräumen nach Möglichkeit vermieden werden soll. Routen ohne Indoor-Navigation werden bevorzugt. Gilt nur für den Fortbewegungsmodus WALKING.

Versand

Der Versand eines einzelnen Artikels von einem seiner Abholorte zu einem seiner Lieferorte. Damit eine Lieferung als ausgeführt gilt, muss ein einzelnes Fahrzeug einen der Abholorte anfahren (und seine freien Kapazitäten entsprechend verringern) und später einen der Lieferorte anfahren (und seine freien Kapazitäten entsprechend wieder erhöhen).

Felder
display_name

string

Der benutzerdefinierte Anzeigename der Sendung. Sie kann bis zu 63 Zeichen lang sein und UTF-8-Zeichen enthalten.

pickups[]

VisitRequest

Satz von Abholalternativen, die mit der Sendung verknüpft sind. Wenn nichts angegeben ist, muss das Fahrzeug nur einen Standort anfahren, der den Lieferungen entspricht.

deliveries[]

VisitRequest

Eine Reihe von Lieferalternativen, die mit der Sendung verknüpft sind. Wenn nichts angegeben ist, muss das Fahrzeug nur einen Ort anfahren, der den Abholorten entspricht.

load_demands

map<string, Load>

Ladeanforderungen der Sendung, z. B. Gewicht, Volumen, Anzahl der Paletten usw. Die Schlüssel in der Map sollten Kennungen sein, die den Typ der entsprechenden Ladung beschreiben, idealerweise auch mit den Einheiten. Beispiele: „weight_kg“, „volume_gallons“, „pallet_count“ usw. Wenn ein bestimmter Schlüssel nicht in der Map enthalten ist, wird die entsprechende Ladung als null betrachtet.

allowed_vehicle_indices[]

int32

Die Menge der Fahrzeuge, die diese Sendung ausführen können. Wenn leer, kann die Aktion von allen Fahrzeugen ausgeführt werden. Fahrzeuge werden anhand ihres Index in der vehicles-Liste von ShipmentModel angegeben.

costs_per_vehicle[]

double

Gibt die Kosten an, die anfallen, wenn diese Sendung mit dem jeweiligen Fahrzeug zugestellt wird. Falls angegeben, muss es ENTWEDER:

  • dieselbe Anzahl von Elementen wie costs_per_vehicle_indices. costs_per_vehicle[i] entspricht dem Fahrzeug costs_per_vehicle_indices[i] des Modells.
  • dieselbe Anzahl von Elementen wie Fahrzeuge im Modell. Das i-te Element entspricht Fahrzeug i des Modells.

Diese Kosten müssen in derselben Einheit wie penalty_cost angegeben werden und dürfen nicht negativ sein. Lassen Sie dieses Feld leer, wenn keine solchen Kosten anfallen.

costs_per_vehicle_indices[]

int32

Die Indexe der Fahrzeuge, auf die costs_per_vehicle angewendet wird. Wenn das Feld nicht leer ist, muss es dieselbe Anzahl an Elementen wie costs_per_vehicle enthalten. Ein Fahrzeugindex darf nicht mehr als einmal angegeben werden. Wenn ein Fahrzeug aus costs_per_vehicle_indices ausgeschlossen ist, sind seine Kosten null.

pickup_to_delivery_absolute_detour_limit

Duration

Gibt die maximale absolute Umwegzeit im Vergleich zum kürzesten Weg von der Abholung bis zur Zustellung an. Wenn angegeben, muss der Wert nicht negativ sein und die Sendung muss mindestens eine Abholung und eine Zustellung enthalten.

Sei t beispielsweise die kürzeste Zeit, die benötigt wird, um von der ausgewählten Abholalternative direkt zur ausgewählten Lieferalternative zu gelangen. Wenn Sie dann pickup_to_delivery_absolute_detour_limit festlegen, wird Folgendes erzwungen:

start_time(delivery) - start_time(pickup) <=
t + pickup_to_delivery_absolute_detour_limit

Wenn sowohl relative als auch absolute Limits für dieselbe Sendung angegeben werden, wird für jedes mögliche Abhol-/Lieferpaar das restriktivere Limit verwendet. Seit Oktober 2017 werden Umwege nur unterstützt, wenn die Reisezeiten nicht von Fahrzeugen abhängen.

pickup_to_delivery_time_limit

Duration

Gibt die maximale Dauer vom Beginn der Abholung bis zum Beginn der Zustellung einer Sendung an. Wenn angegeben, muss der Wert nicht negativ sein und die Sendung muss mindestens eine Abholung und eine Zustellung enthalten. Das hängt weder davon ab, welche Alternativen für die Abholung und Zustellung ausgewählt sind, noch von der Fahrzeuggeschwindigkeit. Diese können zusammen mit den maximalen Umwegbeschränkungen angegeben werden. Die Lösung berücksichtigt dann beide Spezifikationen.

shipment_type

string

Nicht leerer String, der einen „Typ“ für diese Sendung angibt. Mit dieser Funktion können Inkompatibilitäten oder Anforderungen zwischen shipment_types definiert werden (siehe shipment_type_incompatibilities und shipment_type_requirements in ShipmentModel).

Unterscheidet sich von visit_types, das für einen einzelnen Besuch angegeben wird: Alle Abholungen/Lieferungen, die zur selben Sendung gehören, haben dieselbe shipment_type.

label

string

Gibt ein Label für diese Sendung an. Dieses Label wird in der Antwort im shipment_label des entsprechenden ShipmentRoute.Visit gemeldet.

ignore

bool

Wenn „true“, überspringen Sie diese Sendung, wenden Sie aber keine penalty_cost an.

Wenn Sie eine Sendung ignorieren, führt das zu einem Validierungsfehler, wenn im Modell shipment_type_requirements vorhanden sind.

Eine Sendung, die in injected_first_solution_routes oder injected_solution_constraint ausgeführt wird, kann ignoriert werden. Der Solver entfernt die zugehörigen Abhol-/Lieferbesuche aus der auszuführenden Route. precedence_rules, die auf ignorierte Sendungen verweisen, werden ebenfalls ignoriert.

penalty_cost

double

Wenn die Lieferung nicht abgeschlossen wird, wird diese Strafe zu den Gesamtkosten der Routen hinzugerechnet. Eine Sendung gilt als abgeschlossen, wenn eine der Abhol- und Lieferalternativen besucht wurde. Die Kosten können in derselben Einheit wie alle anderen kostenbezogenen Felder im Modell angegeben werden und müssen positiv sein.

WICHTIG: Wenn diese Strafe nicht angegeben ist, wird sie als unendlich betrachtet, d.h. die Sendung muss abgeschlossen werden.

pickup_to_delivery_relative_detour_limit

double

Gibt die maximale relative Umwegzeit im Vergleich zum kürzesten Weg von der Abholung bis zur Zustellung an. Wenn angegeben, muss der Wert nicht negativ sein und die Sendung muss mindestens eine Abholung und eine Zustellung enthalten.

Sei t beispielsweise die kürzeste Zeit, die benötigt wird, um von der ausgewählten Abholalternative direkt zur ausgewählten Lieferalternative zu gelangen. Wenn Sie dann pickup_to_delivery_relative_detour_limit festlegen, wird Folgendes erzwungen:

start_time(delivery) - start_time(pickup) <=
std::ceil(t * (1.0 + pickup_to_delivery_relative_detour_limit))

Wenn sowohl relative als auch absolute Limits für dieselbe Sendung angegeben werden, wird für jedes mögliche Abhol-/Lieferpaar das restriktivere Limit verwendet. Seit Oktober 2017 werden Umwege nur unterstützt, wenn die Reisezeiten nicht von Fahrzeugen abhängen.

Laden

Bei einem Besuch kann der Fahrzeugladung eine vordefinierte Menge hinzugefügt werden, wenn es sich um eine Abholung handelt, oder abgezogen werden, wenn es sich um eine Lieferung handelt. In dieser Nachricht wird ein solcher Betrag definiert. load_demands ansehen.

Felder
amount

int64

Der Betrag, um den sich die Ladung des Fahrzeugs, das den entsprechenden Besuch durchführt, ändert. Da es sich um eine Ganzzahl handelt, sollten Nutzer eine geeignete Einheit auswählen, um einen Präzisionsverlust zu vermeiden. Muss ≥ 0 sein.

VisitRequest

Anfrage für einen Besuch, der mit einem Fahrzeug durchgeführt werden kann: Sie hat einen geografischen Standort (oder zwei, siehe unten), Öffnungs- und Schließzeiten, die durch Zeitfenster dargestellt werden, und eine Dienstleistungsdauer (Zeit, die das Fahrzeug benötigt, wenn es Waren abholt oder abliefert).

Felder
arrival_location

LatLng

Der geografische Standort, an dem das Fahrzeug bei der Ausführung von VisitRequest ankommt. Wenn das Versandmodell Distanzmatrizen für die Dauer enthält, darf arrival_location nicht angegeben werden.

arrival_waypoint

Waypoint

Der Wegpunkt, an dem das Fahrzeug bei der Ausführung dieses VisitRequest ankommt. Wenn das Versandmodell Distanzmatrizen für die Dauer enthält, darf arrival_waypoint nicht angegeben werden.

departure_location

LatLng

Der geografische Standort, an dem das Fahrzeug nach Abschluss dieses VisitRequest abfährt. Kann weggelassen werden, wenn sie mit arrival_location identisch ist. Wenn das Versandmodell Distanzmatrizen für die Dauer enthält, darf departure_location nicht angegeben werden.

departure_waypoint

Waypoint

Der Wegpunkt, an dem das Fahrzeug nach Abschluss dieses VisitRequest abfährt. Kann weggelassen werden, wenn sie mit arrival_waypoint identisch ist. Wenn das Versandmodell Distanzmatrizen für die Dauer enthält, darf departure_waypoint nicht angegeben werden.

tags[]

string

Gibt die Tags an, die an die Besuchs-Anfrage angehängt sind. Leere oder doppelte Strings sind nicht zulässig.

time_windows[]

TimeWindow

Zeitfenster, die die Ankunftszeit bei einem Besuch einschränken. Ein Fahrzeug kann auch außerhalb des Ankunftszeitfensters abfahren. Ankunftszeit und Dauer müssen also nicht innerhalb eines Zeitfensters liegen. Das kann zu Wartezeiten führen, wenn das Fahrzeug vor TimeWindow.start_time eintrifft.

Wenn TimeWindow fehlt, kann das Fahrzeug diesen Besuch jederzeit durchführen.

Die Zeitfenster müssen disjunkt sein, d.h., sie dürfen sich nicht überschneiden oder aneinandergrenzen und müssen in aufsteigender Reihenfolge angegeben werden.

cost_per_hour_after_soft_end_time und soft_end_time können nur festgelegt werden, wenn es ein einzelnes Zeitfenster gibt.

duration

Duration

Dauer des Besuchs, d.h. Zeit, die das Fahrzeug zwischen Ankunft und Abfahrt verbringt (muss zur möglichen Wartezeit addiert werden; siehe time_windows).

cost

double

Kosten für die Bearbeitung dieser Besuchsaufforderung auf einer Fahrzeugroute. Damit können Sie für jede alternative Abholung oder Lieferung einer Sendung unterschiedliche Kosten bezahlen. Die Kosten müssen in derselben Einheit wie Shipment.penalty_cost angegeben werden und dürfen nicht negativ sein.

load_demands

map<string, Load>

Laden Sie die Anforderungen dieser Besuchsaufforderung. Dies entspricht dem Feld Shipment.load_demands, gilt jedoch nur für diese VisitRequest anstelle der gesamten Shipment. Die hier aufgeführten Anforderungen werden den Anforderungen in Shipment.load_demands hinzugefügt.

visit_types[]

string

Gibt die Arten des Besuchs an. Damit kann zusätzliche Zeit zugewiesen werden, die ein Fahrzeug für diesen Besuch benötigt (siehe Vehicle.extra_visit_duration_for_visit_type).

Ein Typ kann nur einmal vorkommen.

label

string

Gibt ein Label für dieses VisitRequest an. Dieses Label wird in der Antwort als visit_label im entsprechenden ShipmentRoute.Visit gemeldet.

avoid_u_turns

bool

Gibt an, ob an diesem Ort Wendemanöver auf Fahrrouten vermieden werden sollen. U-Turns werden nach Möglichkeit vermieden, aber es kann nicht garantiert werden, dass sie vollständig vermieden werden. Dies ist eine experimentelle Funktion und das Verhalten kann sich ändern.

Experimentell: Weitere Informationen finden Sie unter https://developers.google.com/maps/tt/route-optimization/experimental/u-turn-avoidance/make-request.

ShipmentModel

Ein Versandmodell enthält eine Reihe von Sendungen, die von einer Reihe von Fahrzeugen ausgeführt werden müssen, wobei die Gesamtkosten minimiert werden. Die Gesamtkosten sind die Summe aus:

  • die Kosten für die Routenplanung der Fahrzeuge (Summe der Kosten pro Gesamtzeit, Kosten pro Reisezeit und Fixkosten für alle Fahrzeuge).
  • die Strafen für nicht durchgeführte Lieferungen.
  • die Kosten für die globale Dauer der Sendungen
Felder
shipments[]

Shipment

Eine Reihe von Sendungen, die im Modell ausgeführt werden müssen.

vehicles[]

Vehicle

Eine Reihe von Fahrzeugen, die für Besuche verwendet werden können.

objectives[]

Objective

Die Gruppe von Zielvorhaben für dieses Modell, die in Kosten umgewandelt werden. Wenn nicht leer, muss das Eingabemodell kostenlos sein. Verwenden Sie solving_mode = TRANSFORM_AND_RETURN_REQUEST, um die geänderte Anfrage zu erhalten. In diesem Fall wird die Anfrage nicht bearbeitet. Weitere Informationen finden Sie in der entsprechenden Dokumentation.

Experimentell: Weitere Informationen finden Sie unter https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request.

global_start_time

Timestamp

Globale Start- und Endzeit des Modells: Zeiten außerhalb dieses Bereichs können nicht als gültig betrachtet werden.

Der Zeitraum des Modells darf nicht länger als ein Jahr sein. Das heißt, zwischen global_end_time und global_start_time dürfen nicht mehr als 31.536.000 Sekunden liegen.

Wenn Sie cost_per_*hour-Felder verwenden, sollten Sie dieses Zeitfenster möglicherweise auf ein kleineres Intervall festlegen, um die Leistung zu steigern. Wenn Sie beispielsweise einen einzelnen Tag modellieren, sollten Sie die globalen Zeitlimits auf diesen Tag festlegen. Wenn der Wert nicht festgelegt ist, wird standardmäßig 00:00:00 UTC, 1. Januar 1970 (d. h. Sekunden: 0, Nanosekunden: 0) verwendet.

global_end_time

Timestamp

Wenn kein Wert angegeben ist, wird standardmäßig 00:00:00 UTC, 1. Januar 1971 (d. h. Sekunden: 31536000, Nanosekunden: 0) verwendet.

global_duration_cost_per_hour

double

Die „globale Dauer“ des Gesamtplans ist die Differenz zwischen der frühesten effektiven Startzeit und der spätesten effektiven Endzeit aller Fahrzeuge. Nutzer können dieser Menge einen Kostenbetrag pro Stunde zuweisen, um beispielsweise die frühestmögliche Fertigstellung des Jobs zu optimieren. Diese Kosten müssen in derselben Einheit wie Shipment.penalty_cost angegeben werden.

duration_distance_matrices[]

DurationDistanceMatrix

Gibt die im Modell verwendeten Dauer- und Distanzmatrizen an. Wenn dieses Feld leer ist, werden stattdessen Google Maps- oder geodätische Distanzen verwendet, je nach Wert des Felds use_geodesic_distances. Wenn es nicht leer ist, darf use_geodesic_distances nicht „true“ sein und weder duration_distance_matrix_src_tags noch duration_distance_matrix_dst_tags dürfen leer sein.

Typische Syntax:

  • Es gibt zwei Standorte: locA und locB.
  • Ein Fahrzeug beginnt seine Route an Ort A und endet an Ort A.
  • 1 Abholanfrage am Ort B.
model {
  vehicles { start_tags: "locA"  end_tags: "locA" }
  shipments { pickups { tags: "locB" } }
  duration_distance_matrix_src_tags: "locA"
  duration_distance_matrix_src_tags: "locB"
  duration_distance_matrix_dst_tags: "locA"
  duration_distance_matrix_dst_tags: "locB"
  duration_distance_matrices {
    rows {  # from: locA
      durations { seconds: 0 }   meters: 0    # to: locA
      durations { seconds: 100 } meters: 1000 # to: locB
    }
    rows {  # from: locB
      durations { seconds: 102 } meters: 990 # to: locA
      durations { seconds: 0 }   meters: 0   # to: locB
    }
  }
}
  • Es gibt drei Standorte: locA, locB und locC.
  • 1 Fahrzeug, das seine Route an locA beginnt und an locB beendet, wobei die Matrix „fast“ verwendet wird.
  • 1 Fahrzeug, das seine Route an locB beginnt und an locB beendet, wobei die Matrix „slow“ verwendet wird.
  • 1 Fahrzeug, das seine Route an locB beginnt und an locB beendet, wobei die Matrix „fast“ verwendet wird.
  • 1 Abholanfrage am Standort C.
model {
  vehicles { start_tags: "locA" end_tags: "locB" start_tags: "fast" }
  vehicles { start_tags: "locB" end_tags: "locB" start_tags: "slow" }
  vehicles { start_tags: "locB" end_tags: "locB" start_tags: "fast" }
  shipments { pickups { tags: "locC" } }
  duration_distance_matrix_src_tags: "locA"
  duration_distance_matrix_src_tags: "locB"
  duration_distance_matrix_src_tags: "locC"
  duration_distance_matrix_dst_tags: "locB"
  duration_distance_matrix_dst_tags: "locC"
  duration_distance_matrices {
    vehicle_start_tag: "fast"
    rows {  # from: locA
      durations { seconds: 1000 } meters: 2000 # to: locB
      durations { seconds: 600 }  meters: 1000 # to: locC
    }
    rows {  # from: locB
      durations { seconds: 0 }   meters: 0    # to: locB
      durations { seconds: 700 } meters: 1200 # to: locC
    }
    rows {  # from: locC
      durations { seconds: 702 } meters: 1190 # to: locB
      durations { seconds: 0 }   meters: 0    # to: locC
    }
  }
  duration_distance_matrices {
    vehicle_start_tag: "slow"
    rows {  # from: locA
      durations { seconds: 1800 } meters: 2001 # to: locB
      durations { seconds: 900 }  meters: 1002 # to: locC
    }
    rows {  # from: locB
      durations { seconds: 0 }    meters: 0    # to: locB
      durations { seconds: 1000 } meters: 1202 # to: locC
    }
    rows {  # from: locC
      durations { seconds: 1001 } meters: 1195 # to: locB
      durations { seconds: 0 }    meters: 0    # to: locC
    }
  }
}
duration_distance_matrix_src_tags[]

string

Tags, die die Quellen der Dauer- und Distanzmatrizen definieren; duration_distance_matrices(i).rows(j) definiert Dauer und Distanzen von Besuchen mit dem Tag duration_distance_matrix_src_tags(j) zu anderen Besuchen in Matrix i.

Tags entsprechen VisitRequest.tags oder Vehicle.start_tags. Ein bestimmtes VisitRequest oder Vehicle muss genau mit einem Tag in diesem Feld übereinstimmen. Beachten Sie, dass die Quell-, Ziel- und Matrix-Tags eines Vehicle identisch sein können. Ebenso können die Quell- und Ziel-Tags eines VisitRequest identisch sein. Alle Tags müssen sich unterscheiden und dürfen keine leeren Strings sein. Wenn dieses Feld nicht leer ist, darf duration_distance_matrices nicht leer sein.

duration_distance_matrix_dst_tags[]

string

Tags, die die Ziele der Dauer- und Distanzmatrizen definieren; duration_distance_matrices(i).rows(j).durations(k) (bzw. duration_distance_matrices(i).rows(j).meters(k)) definiert die Dauer (bzw. die Entfernung) der Reise von Besuchen mit dem Tag duration_distance_matrix_src_tags(j) zu Besuchen mit dem Tag duration_distance_matrix_dst_tags(k) in Matrix i.

Tags entsprechen VisitRequest.tags oder Vehicle.start_tags. Ein bestimmtes VisitRequest oder Vehicle muss genau mit einem Tag in diesem Feld übereinstimmen. Beachten Sie, dass die Quell-, Ziel- und Matrix-Tags eines Vehicle identisch sein können. Ebenso können die Quell- und Ziel-Tags eines VisitRequest identisch sein. Alle Tags müssen sich unterscheiden und dürfen keine leeren Strings sein. Wenn dieses Feld nicht leer ist, darf duration_distance_matrices nicht leer sein.

transition_attributes[]

TransitionAttributes

Dem Modell wurden Übergangsattribute hinzugefügt.

shipment_type_incompatibilities[]

ShipmentTypeIncompatibility

Sätze inkompatibler shipment_types (siehe ShipmentTypeIncompatibility).

shipment_type_requirements[]

ShipmentTypeRequirement

Sätze von shipment_type-Anforderungen (siehe ShipmentTypeRequirement).

precedence_rules[]

PrecedenceRule

Eine Reihe von Vorrangregeln, die im Modell durchgesetzt werden müssen.

WICHTIG: Durch die Verwendung von Vorrangregeln wird die Größe des Problems, das optimiert werden kann, eingeschränkt. Anfragen mit Vorrangregeln, die viele Sendungen enthalten, können abgelehnt werden.

max_active_vehicles

int32

Beschränkt die maximale Anzahl aktiver Fahrzeuge. Ein Fahrzeug ist aktiv, wenn auf seiner Route mindestens eine Sendung transportiert wird. So kann die Anzahl der Routen begrenzt werden, wenn es weniger Fahrer als Fahrzeuge gibt und der Fuhrpark heterogen ist. Bei der Optimierung wird dann die beste Teilmenge von Fahrzeugen ausgewählt. Muss strikt positiv sein.

DurationDistanceMatrix

Gibt eine Matrix mit Dauer und Entfernung von den Startorten der Besuche und Fahrzeuge zu den Endorten der Besuche und Fahrzeuge an.

Felder
rows[]

Row

Gibt die Zeilen der Distanzmatrix und der Dauermatrix an. Es muss so viele Elemente wie ShipmentModel.duration_distance_matrix_src_tags haben.

vehicle_start_tag

string

Tag, das definiert, für welche Fahrzeuge diese Dauer- und Distanzmatrix gilt. Wenn das Feld leer ist, gilt es für alle Fahrzeuge und es kann nur eine Matrix geben.

Jeder Fahrzeugstart muss genau einer Matrix entsprechen. Das bedeutet, dass genau eines der Felder start_tags mit dem vehicle_start_tag einer Matrix übereinstimmen muss (und nur mit diesem).

Alle Matrizen müssen einen anderen vehicle_start_tag haben.

Zeile

Gibt eine Zeile der Distanzmatrix für Dauer und Entfernung an.

Felder
durations[]

Duration

Dauerwerte für eine bestimmte Zeile. Es muss so viele Elemente wie ShipmentModel.duration_distance_matrix_dst_tags haben.

meters[]

double

Entfernungswerte für eine bestimmte Zeile. Wenn sich im Modell keine Kosten oder Einschränkungen auf Entfernungen beziehen, kann dieses Feld leer gelassen werden. Andernfalls muss es so viele Elemente wie durations enthalten.

Ziel

Zielvorhaben ersetzen das Kostenmodell vollständig und sind daher nicht mit vorhandenen Kosten kompatibel. Jedes Zielvorhaben wird einer Reihe vordefinierter Kosten für z.B. Fahrzeuge, Sendungen oder Übergangsattribute zugeordnet.

Experimentell: Weitere Informationen finden Sie unter https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request.

Felder
type

Type

Der Typ des Zielvorhabens.

weight

double

Wie viel dieses Ziel im Verhältnis zu den anderen zählen soll. Das kann eine beliebige nicht negative Zahl sein. Die Summe der Gewichte muss nicht 1 ergeben. Die Standardeinstellung für Gewichte ist 1,0.

Typ

Der Zielvorhabentyp, der einer Reihe von Kosten zugeordnet wird.

Enums
DEFAULT Es wird ein Standardsatz von Kosten verwendet, um eine angemessene Lösung zu gewährleisten. Hinweis: Dieses Ziel kann allein verwendet werden, wird aber auch immer mit dem Gewicht 1,0 als Baseline zu den vom Nutzer angegebenen Zielen hinzugefügt, sofern es nicht bereits vorhanden ist.
MIN_DISTANCE „MIN“-Zielvorhaben: Minimieren Sie die insgesamt zurückgelegte Strecke.
MIN_WORKING_TIME Minimieren Sie die gesamte Arbeitszeit, summiert über alle Fahrzeuge.
MIN_TRAVEL_TIME Wie oben, aber nur mit Fokus auf die Reisezeit.
MIN_NUM_VEHICLES Minimieren Sie die Anzahl der verwendeten Fahrzeuge.

PrecedenceRule

Eine Vorrangregel zwischen zwei Ereignissen (jedes Ereignis ist die Abholung oder die Zustellung einer Sendung): Das „zweite“ Ereignis muss mindestens offset_duration nach dem Start des „ersten“ Ereignisses beginnen.

Mehrere Vorbedingungen können sich auf dieselben oder ähnliche Ereignisse beziehen, z.B. „Abholung von B erfolgt nach der Zustellung von A“ und „Abholung von C erfolgt nach der Abholung von B“.

Außerdem gelten Vorrangregeln nur, wenn beide Sendungen ausgeführt werden. Andernfalls werden sie ignoriert.

Felder
first_is_delivery

bool

Gibt an, ob das „first“-Ereignis eine Zustellung ist.

second_is_delivery

bool

Gibt an, ob es sich beim „second“-Ereignis um eine Zustellung handelt.

offset_duration

Duration

Die Zeitverschiebung zwischen dem ersten und dem zweiten Ereignis. Sie kann negativ sein.

first_index

int32

Versandindex des „first“-Ereignisses. Dieses Feld muss angegeben werden.

second_index

int32

Versandindex des „zweiten“ Ereignisses. Dieses Feld muss angegeben werden.

ShipmentRoute

Die Route eines Fahrzeugs kann entlang der Zeitachse so zerlegt werden (wir gehen von n Besuchen aus):

  |            |            |          |       |  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

Wir unterscheiden zwischen:

  • „Pünktliche Ereignisse“ wie Start und Ende des Fahrzeugs sowie Start und Ende jedes Besuchs (Ankunft und Abfahrt). Sie treten zu einem bestimmten Zeitpunkt auf.
  • „Zeitintervalle“ wie die Besuche selbst und der Übergang zwischen Besuchen. Zeitintervalle können manchmal eine Dauer von null haben, d. h. sie beginnen und enden in derselben Sekunde. Oft haben sie jedoch eine positive Dauer.

Invarianten:

  • Bei n Besuchen gibt es n+1 Übergänge.
  • Ein Besuch ist immer von einem Übergang davor (derselbe Index) und einem Übergang danach (Index + 1) umgeben.
  • Auf den Fahrzeugstart folgt immer Übergang 0.
  • Dem Fahrzeugende geht immer der Übergang #n voran.

Wenn Sie näher heranzoomen, sehen Sie, was bei einem Transition und einem Visit passiert:

---+-------------------------------------+-----------------------------+-->
   |           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

So können TRAVEL, BREAKS, DELAY und WAIT während eines Übergangs angeordnet werden.

  • Sie überschneiden sich nicht.
  • Die VERZÖGERUNG ist eindeutig und muss ein zusammenhängender Zeitraum unmittelbar vor dem nächsten Besuch (oder dem Ende der Fahrzeugnutzung) sein. Daher reicht es aus, die Verzögerungsdauer zu kennen, um die Start- und Endzeit zu ermitteln.
  • Die PAUSEN sind zusammenhängende, sich nicht überschneidende Zeiträume. In der Antwort werden die Startzeit und die Dauer jeder Pause angegeben.
  • TRAVEL und WAIT sind „unterbrechbar“: Sie können während dieses Übergangs mehrmals unterbrochen werden. Clients können davon ausgehen, dass die Reise „so schnell wie möglich“ stattfindet und dass die verbleibende Zeit mit „Warten“ ausgefüllt wird.

Ein komplexes Beispiel:

                               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     |       |           |         |         ||
  ||     |       |           |       |           |         |         ||
--++-----------------------------------------------------------------++-->
Felder
vehicle_index

int32

Das Fahrzeug, das die Route fährt, identifiziert durch seinen Index in der Quelle ShipmentModel.

vehicle_label

string

Label des Fahrzeugs, das diese Route fährt. Entspricht ShipmentModel.vehicles(vehicle_index).label, falls angegeben.

vehicle_start_time

Timestamp

Uhrzeit, zu der das Fahrzeug seine Route beginnt.

vehicle_end_time

Timestamp

Uhrzeit, zu der das Fahrzeug seine Route beendet.

visits[]

Visit

Geordnete Reihenfolge von Besuchen, die eine Route darstellen. „visits[i]“ ist der i-te Besuch auf der Route. Wenn dieses Feld leer ist, gilt das Fahrzeug als ungenutzt.

transitions[]

Transition

Sortierte Liste der Übergänge für die Route.

has_traffic_infeasibilities

bool

Wenn OptimizeToursRequest.consider_road_traffic auf „true“ gesetzt ist, gibt dieses Feld an, dass Unstimmigkeiten bei den Routenzeiten anhand von verkehrsabhängigen Schätzungen der Fahrtdauer vorhergesagt werden. Möglicherweise ist nicht genügend Zeit, um die fahrplanmäßigen Fahrten, Verzögerungen und Pausen zwischen den Besuchen vor dem ersten oder nach dem letzten Besuch zu berücksichtigen und gleichzeitig die Zeitfenster für Besuche und Fahrzeuge einzuhalten. Beispiel:

  start_time(previous_visit) + duration(previous_visit) +
  travel_duration(previous_visit, next_visit) > start_time(next_visit)

Die Ankunft am nächsten Zielort erfolgt aufgrund der verkehrsbedingten Erhöhung der geschätzten Reisezeit travel_duration(previous_visit, next_visit) wahrscheinlich später als im aktuellen Zeitfenster. Außerdem kann es aufgrund von Einschränkungen des Zeitfensters für Besuche oder Pausen zu Überschneidungen kommen.

route_polyline

EncodedPolyline

Die codierte Polylinien-Darstellung der Route. Dieses Feld wird nur ausgefüllt, wenn OptimizeToursRequest.populate_polylines auf „true“ gesetzt ist.

breaks[]

Break

Pausen, die für das Fahrzeug geplant sind, das diese Route fährt. Die breaks-Sequenz stellt Zeitintervalle dar, die jeweils bei der entsprechenden start_time beginnen und duration Sekunden dauern.

metrics

AggregatedMetrics

Messwerte für Dauer, Entfernung und Belastung für diese Route. Die Felder von AggregatedMetrics werden je nach Kontext über alle ShipmentRoute.transitions oder ShipmentRoute.visits summiert.

vehicle_fullness

VehicleFullness

VehicleFullness-Feld zur Berechnung, wie nah die gedeckelten Messwerte an den jeweiligen Fahrzeuglimits liegen. Die Felder sind Verhältnisse zwischen einem Messwertfeld mit Obergrenze (z.B. AggregatedMetrics.travel_distance_meters) und dem zugehörigen Fahrzeuglimit (z.B. Vehicle.route_distance_limit).

Testphase: Das Verhalten oder die Existenz dieses Felds kann sich in Zukunft ändern.

route_costs

map<string, double>

Kosten der Route, aufgeschlüsselt nach kostenbezogenen Anfragefeldern. Die Schlüssel sind Protopfade relativ zum Eingabe-OptimizeToursRequest, z. B. „model.shipments.pickups.cost“. Die Werte sind die Gesamtkosten, die durch das entsprechende Kostenfeld generiert werden, aggregiert über die gesamte Route. Mit anderen Worten: costs["model.shipments.pickups.cost"] ist die Summe aller Abholkosten für die Route. Alle im Modell definierten Kosten werden hier detailliert aufgeführt. Ausgenommen sind Kosten im Zusammenhang mit TransitionAttributes, die ab Januar 2022 nur noch aggregiert ausgewiesen werden.

route_total_cost

double

Gesamtkosten der Route. Die Summe aller Kosten in der Kostenübersicht.

Pause

Daten, die die Ausführung einer Pause darstellen.

Felder
start_time

Timestamp

Startzeit einer Pause.

duration

Duration

Dauer einer Pause.

EncodedPolyline

Die codierte Darstellung einer Polylinie. Weitere Informationen zur Polyline-Codierung finden Sie hier: https://developers.google.com/maps/documentation/utilities/polylinealgorithm und https://developers.google.com/maps/documentation/javascript/reference/geometry#encoding.

Felder
points

string

String, der die codierten Punkte der Polylinie darstellt.

Übergang

Übergang zwischen zwei Ereignissen auf der Route. Siehe Beschreibung von ShipmentRoute.

Wenn das Fahrzeug keine start_location und/oder end_location hat, sind die entsprechenden Fahrtenmesswerte 0.

Felder
travel_duration

Duration

Reisedauer während dieser Übergangszeit.

travel_distance_meters

double

Zurückgelegte Strecke während des Übergangs.

traffic_info_unavailable

bool

Wenn der Traffic über OptimizeToursRequest.consider_road_traffic angefordert wird und die Traffic-Informationen für ein Transition nicht abgerufen werden konnten, wird dieser boolesche Wert auf „true“ gesetzt. Das kann vorübergehend (seltene Störung auf den Echtzeit-Verkehrsservern) oder dauerhaft (keine Daten für diesen Ort) sein.

delay_duration

Duration

Summe der Verzögerungsdauern, die auf diesen Übergang angewendet werden. Falls vorhanden, beginnt die Verzögerung genau delay_duration Sekunden vor dem nächsten Ereignis (Besuch oder Ende der Fahrt). TransitionAttributes.delay ansehen.

break_duration

Duration

Summe der Dauer der Pausen, die während dieses Übergangs aufgetreten sind (falls vorhanden). Details zur Startzeit und Dauer der einzelnen Pausen werden in ShipmentRoute.breaks gespeichert.

wait_duration

Duration

Wartezeit während dieser Übergangsphase. Die Wartezeit entspricht der Leerlaufzeit und umfasst keine Pausenzeit. Außerdem kann diese Wartezeit in mehrere nicht zusammenhängende Intervalle unterteilt sein.

total_duration

Duration

Gesamtdauer des Übergangs (zur Übersicht). Das entspricht:

  • nächster Besuch start_time (oder vehicle_end_time, wenn dies die letzte Umstellung ist) – start_time dieser Umstellung;
  • Wenn ShipmentRoute.has_traffic_infeasibilities „false“ ist, gilt außerdem: „total_duration = travel_duration + delay_duration“
  • break_duration + wait_duration“.
start_time

Timestamp

Startzeit dieses Übergangs.

route_polyline

EncodedPolyline

Die codierte Polylinien-Darstellung der Route, die während des Übergangs gefahren wurde. Dieses Feld wird nur ausgefüllt, wenn populate_transition_polylines auf „true“ gesetzt ist.

route_token

string

Nur Ausgabe. Ein undurchsichtiges Token, das an das Navigation SDK übergeben werden kann, um die Route während der Navigation zu rekonstruieren und bei einer Umleitung die ursprüngliche Absicht beim Erstellen der Route zu berücksichtigen. Behandeln Sie dieses Token als intransparenten Blob. Vergleichen Sie den Wert nicht über Anfragen hinweg, da er sich ändern kann, auch wenn der Dienst genau dieselbe Route zurückgibt. Dieses Feld wird nur ausgefüllt, wenn populate_transition_polylines auf „true“ gesetzt ist.

vehicle_loads

map<string, VehicleLoad>

Fahrzeugladungen während dieser Umstellung für jeden Typ, der entweder in der Vehicle.load_limits dieses Fahrzeugs enthalten ist oder für den bei einer Sendung auf dieser Route ein Shipment.load_demands-Wert ungleich null vorhanden ist.

Die Ladungen während des ersten Übergangs sind die Startladungen der Fahrzeugroute. Nach jedem Besuch werden die load_demands des Besuchs entweder addiert oder subtrahiert, um die Ladungen für den nächsten Übergang zu erhalten. Das hängt davon ab, ob es sich beim Besuch um eine Abholung oder eine Lieferung handelte.

VehicleLoad

Gibt die tatsächliche Beladung des Fahrzeugs an einem bestimmten Punkt auf der Route für einen bestimmten Typ (siehe Transition.vehicle_loads) zurück.

Felder
amount

int64

Die Belastung des Fahrzeugs für den angegebenen Typ. Die Einheit der Last wird in der Regel durch den Typ angegeben. Transition.vehicle_loads ansehen.

Aufrufen

Ein Besuch, der während einer Route durchgeführt wird. Dieser Besuch entspricht einer Abholung oder Lieferung eines Shipment.

Felder
shipment_index

int32

Index des Felds shipments in der Quelle ShipmentModel.

is_pickup

bool

Wenn „true“, entspricht der Besuch einer Abholung von Shipment. Andernfalls entspricht er einer Lieferung.

visit_request_index

int32

Index von VisitRequest im Feld „Abholung“ oder „Lieferung“ von Shipment (siehe is_pickup).

start_time

Timestamp

Uhrzeit, zu der der Besuch beginnt. Beachten Sie, dass das Fahrzeug möglicherweise früher als zu diesem Zeitpunkt am Besuchsort eintrifft. Die Zeiten stimmen mit der ShipmentModel überein.

load_demands

map<string, Load>

Die Gesamtnachfrage nach Besuchen als Summe der Versand- und der Besuchsanträge load_demands. Die Werte sind negativ, wenn es sich beim Besuch um eine Lieferung handelt. Die Nachfrage wird für dieselben Typen wie Transition.loads gemeldet (siehe dieses Feld).

detour

Duration

Zusätzliche Umwegzeit aufgrund der Sendungen, die auf der Route vor dem Besuch angefahren werden, und der potenziellen Wartezeit, die durch Zeitfenster entsteht. Wenn es sich bei dem Besuch um eine Lieferung handelt, wird der Umweg vom entsprechenden Abholbesuch aus berechnet und entspricht:

start_time(delivery) - start_time(pickup)
- (duration(pickup) + travel duration from the pickup location
to the delivery location).

Andernfalls wird sie aus dem Fahrzeug start_location berechnet und entspricht:

start_time - vehicle_start_time - travel duration from
the vehicle's `start_location` to the visit.
shipment_label

string

Kopie der entsprechenden Shipment.label, falls in der Shipment angegeben.

visit_label

string

Kopie der entsprechenden VisitRequest.label, falls in der VisitRequest angegeben.

visit_type

VisitType

Optional. Gibt den Typ des Besuchs an. Überschreibt das Feld Visit.is_pickup.

injected_solution_location_token

int32

Ein intransparentes Token, das Informationen zu einem besuchten Ort enthält.

Dieses Feld kann bei Besuchen der Ergebnisrouten ausgefüllt werden, wenn VisitRequest.avoid_u_turns für diesen Besuch auf „true“ gesetzt wurde oder wenn ShipmentModel.avoid_u_turns in der Anfrage OptimizeToursRequest auf „true“ gesetzt wurde.

Experimentell: Weitere Informationen finden Sie unter https://developers.google.com/maps/tt/route-optimization/experimental/u-turn-avoidance/make-request.

VisitType

Gibt an, ob es sich um eine Abholung, eine Lieferung oder einen Besuch bei einem Stop handelt. Besuche bei einem Stop werden nur verwendet, wenn die multimodale Optimierung aktiviert ist.

Enums
VISIT_TYPE_UNSPECIFIED Nicht angegebener Besuchstyp.
PICKUP_SHIPMENT Ein Besuch entspricht einer Abholung.
DELIVER_SHIPMENT Ein Besuch entspricht einer Lieferung.

ShipmentTypeIncompatibility

Gibt Inkompatibilitäten zwischen Sendungen in Abhängigkeit von ihrem shipment_type an. Das Erscheinen inkompatibler Sendungen auf derselben Route wird basierend auf dem Inkompatibilitätsmodus eingeschränkt.

Felder
types[]

string

Liste der inkompatiblen Typen. Zwei Sendungen mit unterschiedlichen shipment_types unter den aufgeführten sind „inkompatibel“.

incompatibility_mode

IncompatibilityMode

Auf die Inkompatibilität angewendeter Modus.

IncompatibilityMode

Modi, die definieren, wie das Erscheinen inkompatibler Sendungen auf derselben Route eingeschränkt wird.

Enums
INCOMPATIBILITY_MODE_UNSPECIFIED Nicht angegebener Inkompatibilitätsmodus. Dieser Wert sollte niemals verwendet werden.
NOT_PERFORMED_BY_SAME_VEHICLE In diesem Modus können zwei Sendungen mit inkompatiblen Typen niemals dasselbe Fahrzeug nutzen.
NOT_IN_SAME_VEHICLE_SIMULTANEOUSLY

In diesem Modus können zwei Sendungen mit inkompatiblen Typen niemals gleichzeitig auf demselben Fahrzeug transportiert werden:

  • Sie können dasselbe Fahrzeug nur dann nutzen, wenn das erste geliefert wurde, bevor das zweite abgeholt wird.
  • Wenn beide Sendungen nur abgeholt oder nur zugestellt werden, können sie nicht im selben Fahrzeug transportiert werden.

ShipmentTypeRequirement

Gibt Anforderungen zwischen Sendungen basierend auf ihrem shipment_type an. Die Details der Anforderung werden durch den Anforderungsmodus definiert.

Felder
required_shipment_type_alternatives[]

string

Liste der alternativen Versandarten, die von dependent_shipment_types benötigt werden.

dependent_shipment_types[]

string

Für alle Sendungen mit einem Typ im Feld dependent_shipment_types muss auf derselben Route mindestens eine Sendung vom Typ required_shipment_type_alternatives besucht werden.

HINWEIS: Ketten von Anforderungen, bei denen eine shipment_type von sich selbst abhängt, sind nicht zulässig.

requirement_mode

RequirementMode

Auf die Anforderung angewendeter Modus.

RequirementMode

Modi, die das Erscheinungsbild von abhängigen Sendungen auf einer Route definieren.

Enums
REQUIREMENT_MODE_UNSPECIFIED Nicht angegebener Anforderungsmodus. Dieser Wert sollte niemals verwendet werden.
PERFORMED_BY_SAME_VEHICLE In diesem Modus müssen alle „abhängigen“ Sendungen dasselbe Fahrzeug wie mindestens eine ihrer „erforderlichen“ Sendungen nutzen.
IN_SAME_VEHICLE_AT_PICKUP_TIME

Im IN_SAME_VEHICLE_AT_PICKUP_TIME-Modus muss für alle „abhängigen“ Sendungen zum Zeitpunkt der Abholung mindestens eine „erforderliche“ Sendung im Fahrzeug vorhanden sein.

Für die Abholung einer „abhängigen“ Sendung muss daher Folgendes gelten:

  • Eine „erforderliche“ Sendung, die nur geliefert werden muss, wird nach der Route geliefert oder
  • Eine „erforderliche“ Sendung wird auf der Route vor der „abhängigen“ Sendung abgeholt. Wenn die „erforderliche“ Sendung eine Lieferung enthält, muss diese nach der Abholung der „abhängigen“ Sendung erfolgen.
IN_SAME_VEHICLE_AT_DELIVERY_TIME Wie zuvor, nur dass für die „abhängigen“ Sendungen zum Zeitpunkt der Lieferung eine „erforderliche“ Sendung im Fahrzeug vorhanden sein muss.

SkippedShipment

Gibt Details zu nicht ausgeführten Sendungen in einer Lösung an. Bei trivialen Fällen und/oder wenn wir die Ursache für das Überspringen ermitteln können, geben wir den Grund hier an.

Felder
index

int32

Der Index entspricht dem Index der Sendung in der Quelle ShipmentModel.

label

string

Kopie der entsprechenden Shipment.label, falls in der Shipment angegeben.

reasons[]

Reason

Eine Liste mit Gründen, warum die Sendung übersprungen wurde. Siehe Kommentar oben Reason. Wenn wir nicht nachvollziehen können, warum eine Sendung übersprungen wurde, werden keine Gründe angegeben.

penalty_cost

double

Dies ist eine Kopie des Shipment.penalty_cost, die hier enthalten ist, um die Schwere einer übersprungenen Sendung besser nachvollziehen zu können.

Testphase: Das Verhalten oder die Existenz dieses Felds kann sich in Zukunft ändern.

estimated_incompatible_vehicle_ratio

double

Geschätztes Verhältnis der Fahrzeuge, die diese Sendung aus mindestens einem der folgenden Gründe nicht transportieren können. Hinweis: Dieses Feld wird nur ausgefüllt, wenn die Gründe ein Fahrzeug betreffen.

Testphase: Das Verhalten oder die Existenz dieses Felds kann sich in Zukunft ändern.

Grund

Wenn wir erklären können, warum die Sendung übersprungen wurde, werden die Gründe hier aufgeführt. Wenn der Grund nicht für alle Fahrzeuge derselbe ist, enthält reason mehr als ein Element. Für eine übersprungene Sendung dürfen keine doppelten Gründe angegeben werden, d.h. alle Felder müssen gleich sein, mit Ausnahme von example_vehicle_index. Beispiel:

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
}

Die übersprungene Sendung ist mit keinem Fahrzeug kompatibel. Die Gründe können für alle Fahrzeuge unterschiedlich sein, aber die Kapazität von „Äpfel“ würde bei mindestens einem Fahrzeug überschritten (einschließlich Fahrzeug 1), die Kapazität von „Birnen“ würde bei mindestens einem Fahrzeug überschritten (einschließlich Fahrzeug 3) und das Entfernungslimit würde bei mindestens einem Fahrzeug überschritten (einschließlich Fahrzeug 1).

Felder
code

Code

Weitere Informationen finden Sie in den Kommentaren des Codes.

example_vehicle_indices[]

int32

Wie example_vehicle_index, nur dass wir die Liste der mehreren identifizierten Fahrzeuge angeben. Diese Liste ist nicht unbedingt vollständig. Sie wird nur ausgefüllt, wenn [fill_example_vehicle_indices_in_skipped_reasons][] „true“ ist.

Testphase: Das Verhalten oder die Existenz dieses Felds kann sich in Zukunft ändern.

example_exceeded_capacity_type

string

Wenn der Grundcode DEMAND_EXCEEDS_VEHICLE_CAPACITY ist, werden Dokumente für einen Kapazitätstyp erstellt, der überschritten wird.

example_vehicle_index

int32

Wenn der Grund mit einer Inkompatibilität zwischen Sendung und Fahrzeug zusammenhängt, enthält dieses Feld den Index eines relevanten Fahrzeugs.

Code

Code zur Identifizierung des Grundtyps. Die Reihenfolge spielt hier keine Rolle. Insbesondere wird nicht angegeben, ob ein bestimmter Grund vor einem anderen in der Lösung angezeigt wird, wenn beide zutreffen.

Enums
CODE_UNSPECIFIED Sollte nicht verwendet werden.
NO_VEHICLE Im Modell ist kein Fahrzeug vorhanden, sodass alle Sendungen nicht durchführbar sind.
DEMAND_EXCEEDS_VEHICLE_CAPACITY Die Nachfrage nach der Sendung übersteigt die Kapazität eines Fahrzeugs für einige Kapazitätstypen, darunter example_exceeded_capacity_type.
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DISTANCE_LIMIT

Die für diese Sendung erforderliche Mindeststrecke, d.h. vom start_location des Fahrzeugs zu den Abhol- und/oder Lieferorten der Sendung und zum Endstandort des Fahrzeugs, überschreitet die route_distance_limit des Fahrzeugs.

Beachten Sie, dass wir für diese Berechnung die geodätischen Distanzen verwenden.

CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT

Die für diese Sendung erforderliche Mindestzeit, einschließlich Reisezeit, Wartezeit und Servicezeit, überschreitet die route_duration_limit des Fahrzeugs.

Hinweis: Die Reisezeit wird im Best-Case-Szenario berechnet, nämlich als geodätische Entfernung × 36 m/s (ungefähr 130 km/h).

CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TRAVEL_DURATION_LIMIT Wie oben, aber wir vergleichen nur die minimale Reisezeit und die travel_duration_limit des Fahrzeugs.
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TIME_WINDOWS Das Fahrzeug kann diese Lieferung im besten Fall (siehe CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT für die Zeitberechnung) nicht ausführen, wenn es zum frühestmöglichen Startzeitpunkt startet: Die Gesamtzeit würde dazu führen, dass das Fahrzeug nach dem spätestmöglichen Endzeitpunkt endet.
VEHICLE_NOT_ALLOWED Das Feld allowed_vehicle_indices der Sendung ist nicht leer und dieses Fahrzeug gehört nicht dazu.
VEHICLE_IGNORED

Das Feld ignore des Fahrzeugs ist „true“.

Testphase: Das Verhalten oder die Existenz dieses Felds kann sich in Zukunft ändern.

SHIPMENT_IGNORED

Das Feld ignore der Sendung ist „true“.

Testphase: Das Verhalten oder die Existenz dieses Felds kann sich in Zukunft ändern.

SKIPPED_IN_INJECTED_SOLUTION_CONSTRAINT

Die Lieferung wird in injected_solution_constraint ausgesetzt.

Testphase: Das Verhalten oder die Existenz dieses Felds kann sich in Zukunft ändern.

VEHICLE_ROUTE_IS_FULLY_SEQUENCE_CONSTRAINED

Die in injected_solution_constraint angegebene Lockerung der Fahrzeugroute lässt keine Einfügung eines Besuchs zu.

Testphase: Das Verhalten oder die Existenz dieses Felds kann sich in Zukunft ändern.

ZERO_PENALTY_COST

Für die Sendung fallen keine Strafkosten an. Das kann als erweiterte Modellierungsoption nützlich sein, erklärt aber möglicherweise auch, warum eine Sendung übersprungen wurde.

Testphase: Das Verhalten oder die Existenz dieses Felds kann sich in Zukunft ändern.

TimeWindow

Zeitfenster schränken die Zeit eines Ereignisses ein, z. B. die Ankunftszeit bei einem Besuch oder die Start- und Endzeit eines Fahrzeugs.

Mit den harten Zeitfenstergrenzen start_time und end_time wird die früheste und späteste Zeit des Ereignisses festgelegt, sodass start_time <= event_time <= end_time. Mit der unteren Grenze des weichen Zeitfensters, soft_start_time, wird eine Präferenz dafür ausgedrückt, dass das Ereignis um oder nach soft_start_time stattfindet. Dabei fallen Kosten an, die proportional dazu sind, wie lange vor soft_start_time das Ereignis stattfindet. Mit der oberen Grenze des weichen Zeitfensters, soft_end_time, wird eine Präferenz dafür ausgedrückt, dass das Ereignis um oder vor soft_end_time stattfindet. Dabei fallen Kosten an, die proportional dazu sind, wie lange nach soft_end_time das Ereignis stattfindet. start_time, end_time, soft_start_time und soft_end_time sollten innerhalb der globalen Zeitlimits liegen (siehe ShipmentModel.global_start_time und ShipmentModel.global_end_time) und Folgendes berücksichtigen:

  0 <= `start_time` <= `end_time` and
  0 <= `start_time` <= `soft_start_time` and
  0 <= `soft_end_time` <= `end_time`.
Felder
start_time

Timestamp

Die Startzeit des harten Zeitfensters. Wenn nicht angegeben, wird ShipmentModel.global_start_time verwendet.

end_time

Timestamp

Die Endzeit des harten Zeitfensters. Wenn sie nicht angegeben ist, wird sie auf ShipmentModel.global_end_time gesetzt.

soft_start_time

Timestamp

Die Soft-Startzeit des Zeitfensters.

soft_end_time

Timestamp

Das weiche Ende des Zeitfensters.

cost_per_hour_before_soft_start_time

double

Kosten pro Stunde, die anderen Kosten im Modell hinzugefügt werden, wenn das Ereignis vor „soft_start_time“ eintritt. Sie werden so berechnet:

   max(0, soft_start_time - t.seconds)
                          * cost_per_hour_before_soft_start_time / 3600,
t being the time of the event.

Diese Kosten müssen positiv sein und das Feld kann nur festgelegt werden, wenn „soft_start_time“ festgelegt wurde.

cost_per_hour_after_soft_end_time

double

Kosten pro Stunde, die anderen Kosten im Modell hinzugefügt werden, wenn das Ereignis nach soft_end_time eintritt. Sie werden so berechnet:

   max(0, t.seconds - soft_end_time.seconds)
                    * cost_per_hour_after_soft_end_time / 3600,
t being the time of the event.

Diese Kosten müssen positiv sein und das Feld kann nur festgelegt werden, wenn soft_end_time festgelegt wurde.

TransitionAttributes

Gibt Attribute von Übergängen zwischen zwei aufeinanderfolgenden Besuchen auf einer Route an. Für denselben Übergang können mehrere TransitionAttributes gelten. In diesem Fall werden alle zusätzlichen Kosten addiert und die strengste Einschränkung oder das strengste Limit wird angewendet (gemäß der natürlichen UND-Semantik).

Felder
src_tag

string

Tags, die die Menge der (src->dst)-Übergänge definieren, auf die sich diese Attribute beziehen.

Ein Quellbesuch oder Fahrzeugstart stimmt überein, wenn sein VisitRequest.tags oder Vehicle.start_tags entweder src_tag enthält oder excluded_src_tag nicht enthält (je nachdem, welches dieser beiden Felder nicht leer ist).

excluded_src_tag

string

src_tag ansehen. Genau eines von src_tag und excluded_src_tag darf nicht leer sein.

dst_tag

string

Ein Zielbesuch oder ein Fahrzeugende entspricht, wenn sein VisitRequest.tags oder Vehicle.end_tags entweder dst_tag enthält oder excluded_dst_tag nicht enthält (je nachdem, welches dieser beiden Felder nicht leer ist).

excluded_dst_tag

string

dst_tag ansehen. Genau eines von dst_tag und excluded_dst_tag darf nicht leer sein.

cost

double

Gibt die Kosten für die Durchführung dieser Übergangsphase an. Die Einheit ist dieselbe wie bei allen anderen Kosten im Modell und darf nicht negativ sein. Sie wird zusätzlich zu allen anderen vorhandenen Kosten angewendet.

cost_per_kilometer

double

Gibt die Kosten pro Kilometer an, die für die während dieses Übergangs zurückgelegte Strecke anfallen. Sie werden zu allen Vehicle.cost_per_kilometer addiert, die für Fahrzeuge angegeben sind.

distance_limit

DistanceLimit

Gibt ein Limit für die zurückgelegte Strecke während dieses Übergangs an.

Seit Juni 2021 werden nur noch Softlimits unterstützt.

delay

Duration

Gibt eine Verzögerung an, die bei der Ausführung dieses Übergangs auftritt.

Diese Verzögerung tritt immer nach dem Abschluss des Quellbesuchs und vor dem Beginn des Zielbesuchs auf.

Uri

Ein Universal Resource Identifier, der auf eine Ressource verweist, die von der Route Optimization API gelesen und geschrieben werden kann.

Felder
uri

string

Der URI der Ressource. Die Ressource ist möglicherweise noch nicht vorhanden.

Der Inhalt der Ressource wird entweder als JSON oder als Textproto codiert. Es werden nur Google Cloud Storage-Ressourcen unterstützt. Wenn die Ressource als JSON codiert ist, muss der Ressourcenname mit .json enden. Wenn die Ressource als Textproto codiert ist, muss der Ressourcenname mit .txtpb enden. Ein Google Cloud Storage-URI für eine JSON-codierte Datei könnte beispielsweise so aussehen: gs://bucket/path/input/object.json.

Fahrzeug

Modelliert ein Fahrzeug in einem Versandproblem. Wenn ein Versandproblem gelöst wird, wird für dieses Fahrzeug eine Route erstellt, die bei start_location beginnt und bei end_location endet. Eine Route ist eine Folge von Besuchen (siehe ShipmentRoute).

Felder
display_name

string

Der benutzerdefinierte Anzeigename des Fahrzeugs. Sie kann bis zu 63 Zeichen lang sein und UTF-8-Zeichen enthalten.

travel_mode

TravelMode

Die Fortbewegungsart, die sich auf die für das Fahrzeug nutzbaren Straßen und seine Geschwindigkeit auswirkt. Siehe auch travel_duration_multiple.

route_modifiers

RouteModifiers

Eine Reihe von Bedingungen, die erfüllt sein müssen und die sich auf die Berechnung von Routen für das jeweilige Fahrzeug auswirken.

start_location

LatLng

Geografischer Standort, an dem das Fahrzeug vor der Abholung von Sendungen startet. Wenn nicht angegeben, beginnt die Fahrt am ersten Abholort des Fahrzeugs. Wenn das Versandmodell Dauer- und Distanzmatrizen enthält, darf start_location nicht angegeben werden.

start_waypoint

Waypoint

Wegpunkt, der einen geografischen Standort darstellt, an dem das Fahrzeug vor der Abholung von Sendungen startet. Wenn weder start_waypoint noch start_location angegeben ist, beginnt die Fahrt des Fahrzeugs am ersten Abholort. Wenn das Versandmodell Dauer- und Distanzmatrizen enthält, darf start_waypoint nicht angegeben werden.

end_location

LatLng

Geografischer Standort, an dem das Fahrzeug nach Abschluss der letzten VisitRequest steht. Wenn nicht angegeben, endet die ShipmentRoute des Fahrzeugs sofort nach Abschluss der letzten VisitRequest. Wenn das Versandmodell Dauer- und Distanzmatrizen enthält, darf end_location nicht angegeben werden.

end_waypoint

Waypoint

Wegpunkt, der einen geografischen Standort darstellt, an dem das Fahrzeug nach Abschluss der letzten VisitRequest endet. Wenn weder end_waypoint noch end_location angegeben ist, endet die ShipmentRoute des Fahrzeugs sofort, wenn die letzte VisitRequest abgeschlossen ist. Wenn das Versandmodell Dauer- und Distanzmatrizen enthält, darf end_waypoint nicht angegeben werden.

start_tags[]

string

Gibt Tags an, die dem Start der Route des Fahrzeugs zugeordnet sind.

Leere oder doppelte Strings sind nicht zulässig.

end_tags[]

string

Gibt Tags an, die am Ende der Route des Fahrzeugs angehängt werden.

Leere oder doppelte Strings sind nicht zulässig.

start_time_windows[]

TimeWindow

Zeitfenster, in denen das Fahrzeug vom Startort abfahren darf. Sie müssen innerhalb der globalen Zeitlimits liegen (siehe ShipmentModel.global_*-Felder). Wenn keine Angabe erfolgt, gibt es keine Einschränkungen, die über die globalen Zeitlimits hinausgehen.

Zeiträume, die zum selben wiederholten Feld gehören, dürfen sich nicht überschneiden oder aneinandergrenzen und müssen in chronologischer Reihenfolge angegeben werden.

cost_per_hour_after_soft_end_time und soft_end_time können nur festgelegt werden, wenn es ein einzelnes Zeitfenster gibt.

end_time_windows[]

TimeWindow

Zeitfenster, in denen das Fahrzeug am Zielort eintreffen kann. Sie müssen innerhalb der globalen Zeitlimits liegen (siehe ShipmentModel.global_*-Felder). Wenn keine Angabe erfolgt, gibt es keine Einschränkungen, die über die globalen Zeitlimits hinausgehen.

Zeiträume, die zum selben wiederholten Feld gehören, dürfen sich nicht überschneiden oder aneinandergrenzen und müssen in chronologischer Reihenfolge angegeben werden.

cost_per_hour_after_soft_end_time und soft_end_time können nur festgelegt werden, wenn es ein einzelnes Zeitfenster gibt.

unloading_policy

UnloadingPolicy

Die Richtlinie zum Entladen wird auf das Fahrzeug angewendet.

load_limits

map<string, LoadLimit>

Kapazitäten des Fahrzeugs (z. B. Gewicht, Volumen, Anzahl der Paletten). Die Schlüssel in der Karte sind die Kennungen des Lasttyps, die mit den Schlüsseln des Felds Shipment.load_demands übereinstimmen. Wenn ein bestimmter Schlüssel in dieser Zuordnung fehlt, wird die entsprechende Kapazität als unbegrenzt betrachtet.

cost_per_hour

double

Fahrzeugkosten: Alle Kosten werden addiert und müssen in derselben Einheit wie Shipment.penalty_cost angegeben werden.

Kosten pro Stunde der Fahrzeugroute. Diese Kosten werden auf die Gesamtzeit der Route angewendet und umfassen Fahrzeit, Wartezeit und Besuchszeit. Die Verwendung von cost_per_hour anstelle von cost_per_traveled_hour kann zu zusätzlicher Latenz führen.

cost_per_traveled_hour

double

Kosten pro gefahrener Stunde der Fahrzeugroute. Diese Kosten werden nur auf die Reisezeit der Route angewendet (d. h. auf die in ShipmentRoute.transitions angegebene Zeit). Wartezeit und Besuchszeit sind nicht enthalten.

cost_per_kilometer

double

Kosten pro Kilometer der Fahrzeugroute. Diese Kosten werden auf die in ShipmentRoute.transitions angegebene Entfernung angewendet und gelten nicht für Entfernungen, die implizit vom arrival_location zum departure_location eines einzelnen VisitRequest zurückgelegt werden.

fixed_cost

double

Feste Kosten, die anfallen, wenn dieses Fahrzeug für den Transport einer Sendung verwendet wird.

used_if_route_is_empty

bool

Dieses Feld gilt nur für Fahrzeuge, deren Route keine Sendungen umfasst. Es gibt an, ob das Fahrzeug in diesem Fall als verwendet betrachtet werden soll oder nicht.

Wenn „true“ festgelegt ist, fährt das Fahrzeug von seinem Start- zum Zielort, auch wenn es keine Sendungen transportiert. Zeit- und Entfernungskosten, die sich aus der Fahrt vom Start- zum Zielort ergeben, werden berücksichtigt.

Andernfalls fährt es nicht von seinem Start- zum Zielort und es sind keine break_rule oder Verspätungen (ab TransitionAttributes) für dieses Fahrzeug geplant. In diesem Fall enthält ShipmentRoute des Fahrzeugs keine Informationen außer dem Fahrzeugindex und dem Label.

route_duration_limit

DurationLimit

Limit für die Gesamtdauer der Route des Fahrzeugs. In einem bestimmten OptimizeToursResponse ist die Routendauer eines Fahrzeugs die Differenz zwischen vehicle_end_time und vehicle_start_time.

travel_duration_limit

DurationLimit

Grenzwert für die Reisedauer der Route des Fahrzeugs. In einem bestimmten OptimizeToursResponse ist die Reisedauer der Route die Summe aller transitions.travel_duration.

route_distance_limit

DistanceLimit

Das Limit wird auf die Gesamtstrecke der Fahrzeugroute angewendet. In einem bestimmten OptimizeToursResponse ist die Routenentfernung die Summe aller seiner transitions.travel_distance_meters.

extra_visit_duration_for_visit_type

map<string, Duration>

Gibt eine Zuordnung von visit_types-Strings zu Zeiträumen an. Die Dauer ist die Zeit zusätzlich zu VisitRequest.duration, die bei Besuchen mit der angegebenen visit_types eingeplant werden soll. Diese zusätzliche Besuchszeit führt zu zusätzlichen Kosten, wenn cost_per_hour angegeben ist. Schlüssel (d.h. visit_types) dürfen keine leeren Strings sein.

Wenn eine Besichtigung mehrere Typen hat, wird für jeden Typ eine Dauer auf der Karte hinzugefügt.

break_rule

BreakRule

Beschreibt den Pausenplan, der für dieses Fahrzeug gelten soll. Wenn leer, werden für dieses Fahrzeug keine Pausen eingeplant.

label

string

Gibt ein Label für dieses Fahrzeug an. Dieses Label wird in der Antwort als vehicle_label des entsprechenden ShipmentRoute gemeldet.

ignore

bool

Wenn „true“ angegeben ist, muss used_if_route_is_empty „false“ sein und dieses Fahrzeug wird nicht verwendet.

Wenn eine Lieferung von einem ignorierten Fahrzeug in injected_first_solution_routes ausgeführt wird, wird sie in der ersten Lösung übersprungen, kann aber in der Antwort ausgeführt werden.

Wenn eine Sendung von einem ignorierten Fahrzeug in injected_solution_constraint durchgeführt wird und alle zugehörigen Abholungen/Lieferungen auf das Fahrzeug beschränkt sind (d.h. nicht auf Stufe RELAX_ALL_AFTER_THRESHOLD gelockert werden), wird sie in der Antwort übersprungen. Wenn eine Sendung ein nicht leeres Feld allowed_vehicle_indices hat und alle zulässigen Fahrzeuge ignoriert werden, wird sie in der Antwort übersprungen.

travel_duration_multiple

double

Gibt einen multiplikativen Faktor an, mit dem die Fahrzeiten dieses Fahrzeugs verlängert oder verkürzt werden können. Wenn Sie diesen Wert beispielsweise auf 2,0 festlegen, ist das Fahrzeug langsamer und die Fahrzeiten sind doppelt so lang wie bei Standardfahrzeugen. Dieser Faktor hat keine Auswirkungen auf die Besuchszeiten. Es wirkt sich auf die Kosten aus, wenn cost_per_hour oder cost_per_traveled_hour angegeben sind. Dieser Wert muss im Bereich [0,001, 1.000,0] liegen. Wenn nicht festgelegt, ist das Fahrzeug standardmäßig und dieser Faktor wird als 1, 0 betrachtet.

ACHTUNG: Reisezeiten werden nach Anwendung dieses Vielfachen, aber vor allen numerischen Operationen auf die nächste Sekunde gerundet. Ein kleines Vielfaches kann daher zu einem Genauigkeitsverlust führen.

Siehe auch extra_visit_duration_for_visit_type unten.

DurationLimit

Ein Grenzwert, der die maximale Dauer der Route eines Fahrzeugs definiert. Sie kann entweder hart oder weich sein.

Wenn ein Feld für ein weiches Limit definiert ist, müssen sowohl der Grenzwert für das weiche Maximum als auch die zugehörigen Kosten zusammen definiert werden.

Felder
max_duration

Duration

Ein hartes Limit, das die Dauer auf maximal max_duration begrenzt.

soft_max_duration

Duration

Ein weiches Limit, das keine maximale Dauer erzwingt, aber bei Überschreitung Kosten für die Route verursacht. Diese Kosten werden zu anderen im Modell definierten Kosten mit derselben Einheit addiert.

Wenn definiert, muss soft_max_duration nicht negativ sein. Wenn auch „max_duration“ definiert ist, muss soft_max_duration kleiner als „max_duration“ sein.

quadratic_soft_max_duration

Duration

Ein weiches Limit, das kein Limit für die maximale Dauer erzwingt. Bei Überschreitung fallen jedoch Kosten an, die quadratisch mit der Dauer steigen. Diese Kosten werden zu anderen im Modell definierten Kosten mit derselben Einheit addiert.

Wenn quadratic_soft_max_duration festgelegt ist, müssen die folgenden Bedingungen erfüllt sein:

  • Er darf nicht negativ sein.
  • max_duration muss definiert werden.
  • quadratic_soft_max_duration muss kleiner als max_duration sein.
  • Der Unterschied darf höchstens einen Tag betragen: max_duration - quadratic_soft_max_duration <= 86400 seconds
cost_per_hour_after_soft_max

double

Kosten pro Stunde, die anfallen, wenn der soft_max_duration-Schwellenwert überschritten wird. Die zusätzlichen Kosten sind 0, wenn die Dauer unter dem Schwellenwert liegt. Andernfalls hängen die Kosten wie folgt von der Dauer ab:

  cost_per_hour_after_soft_max * (duration - soft_max_duration)

Die Kosten dürfen nicht negativ sein.

cost_per_square_hour_after_quadratic_soft_max

double

Kosten pro Quadratstunde, die anfallen, wenn der quadratic_soft_max_duration-Grenzwert überschritten wird.

Die zusätzlichen Kosten betragen 0, wenn die Dauer unter dem Schwellenwert liegt. Andernfalls hängen die Kosten wie folgt von der Dauer ab:

  cost_per_square_hour_after_quadratic_soft_max *
  (duration - quadratic_soft_max_duration)^2

Die Kosten dürfen nicht negativ sein.

LoadLimit

Definiert ein Ladungsgewichtslimit für ein Fahrzeug, z. B. „Dieser Lkw darf nur bis zu 3.500 kg transportieren“. load_limits ansehen.

Felder
soft_max_load

int64

Ein weiches Limit für die Last. cost_per_unit_above_soft_max ansehen.

cost_per_unit_above_soft_max

double

Wenn die Last auf der Route dieses Fahrzeugs jemals soft_max_load überschreitet, wird die folgende Kostenstrafe angewendet (nur einmal pro Fahrzeug): (Last – soft_max_load) * cost_per_unit_above_soft_max. Alle Kosten werden addiert und müssen in derselben Einheit wie Shipment.penalty_cost angegeben werden. Weiche Limits dürfen nur für Typen definiert werden, die im gesamten Modell entweder nur für Abholungen oder nur für Lieferungen gelten.

start_load_interval

Interval

Das zulässige Ladeintervall des Fahrzeugs zu Beginn der Route.

end_load_interval

Interval

Das zulässige Ladeintervall des Fahrzeugs am Ende der Route.

max_load

int64

Die maximal zulässige Belastung.

cost_per_kilometer

LoadCost

Kosten für den Transport einer Ladeeinheit über einen Kilometer mit diesem Fahrzeug. Dies kann als Proxy für den Kraftstoffverbrauch verwendet werden: Wenn die Last ein Gewicht (in Newton) ist, hat „Last × Kilometer“ die Dimension einer Energie.

Experimentell: Weitere Informationen finden Sie unter https://developers.google.com/maps/tt/route-optimization/experimental/load-cost/make-request.

cost_per_traveled_hour

LoadCost

Kosten für die Fahrt mit einer Ladeeinheit für eine Stunde mit diesem Fahrzeug.

Experimentell: Weitere Informationen finden Sie unter https://developers.google.com/maps/tt/route-optimization/experimental/load-cost/make-request.

Intervall

Intervall akzeptabler Ladebeträge.

Felder
min

int64

Eine minimal akzeptable Last. Muss ≥ 0 sein. Wenn beide angegeben sind, muss min ≤ max sein.

max

int64

Eine maximal zulässige Last. Muss ≥ 0 sein. Wenn nicht angegeben, ist die maximale Last durch diese Nachricht nicht eingeschränkt. Wenn beide angegeben sind, muss min ≤ max sein.

LoadCost

Kosten für die Übertragung einer Lasteinheit während eines Transition. Die Kosten für eine bestimmte Last setzen sich aus zwei Teilen zusammen:

  • min(load, load_threshold) * cost_per_unit_below_threshold
  • max(0, load – load_threshold) * cost_per_unit_above_threshold

Bei diesen Kosten werden Lösungen bevorzugt, die zuerst hohe Anforderungen erfüllen oder hohe Anforderungen zuletzt abholen. Wenn ein Fahrzeug beispielsweise

load_limit {
  key: "weight"
  value {
    cost_per_kilometer {
      load_threshold: 15
      cost_per_unit_below_threshold: 2.0
      cost_per_unit_above_threshold: 10.0
    }
  }
}

Die Route ist: Start,Abholung,Abholung,Lieferung,Lieferung,Ende mit Übergängen:

transition { vehicle_load['weight'] { amount: 0 }
             travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
             travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 20 }
             travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
             travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 0 }
             travel_distance_meters: 1000.0 }

dann sind die Kosten für diese LoadCost (cost_below * load_below * kilometers + cost_above * load_above * kms).

  • Übergang 0: 0,0
  • Übergang 1: 2,0 × 10 × 1,0 + 10,0 × 0 × 1,0 = 20,0
  • Übergang 2: 2,0 × 15 × 1,0 + 10,0 × (20 – 15) × 1,0 = 80,0
  • Übergang 3: 2,0 × 10 × 1,0 + 10,0 × 0 × 1,0 = 20,0
  • Übergang 4: 0,0

Der LoadCost für die Route beträgt also 120,0.

Wenn die Route jedoch mit Übergängen beginnt und endet, z. B. „Start,Abholung,Zustellung,Abholung,Zustellung,Ende“:

transition { vehicle_load['weight'] { amount: 0 }
             travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
             travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 0 }
             travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
             travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 0 }
             travel_distance_meters: 1000.0 }

Die Kosten für diese LoadCost sind

  • Übergang 0: 0,0
  • Übergang 1: 2,0 × 10 × 1,0 + 10,0 × 0 × 1,0 = 20,0
  • Übergang 2: 0,0
  • Übergang 3: 2,0 × 10 × 1,0 + 10,0 × 0 × 1,0 = 20,0
  • Übergang 4: 0,0

Hier beträgt der LoadCost für die Route 40,0.

LoadCost macht Lösungen mit stark ausgelasteten Übergängen teurer.

Experimentell: Weitere Informationen finden Sie unter https://developers.google.com/maps/tt/route-optimization/experimental/load-cost/make-request.

Felder
load_threshold

int64

Die Menge der Last, ab der sich die Kosten für die Verlagerung einer Lasteinheit von „cost_per_unit_below_threshold“ zu „cost_per_unit_above_threshold“ ändern. Muss >= 0 sein.

cost_per_unit_below_threshold

double

Kosten für die Verlagerung einer Lasteinheit für jede Einheit zwischen 0 und dem Schwellenwert. Muss ein endlicher Wert und >= 0 sein.

cost_per_unit_above_threshold

double

Kosten für die Verlagerung einer Lasteinheit für jede Einheit über dem Schwellenwert. Im Sonderfall „Grenzwert = 0“ handelt es sich um einen Fixkostenbetrag pro Einheit. Muss ein endlicher Wert und >= 0 sein.

TravelMode

Mobilitätsformen, die von Fahrzeugen genutzt werden können.

Dies sollte eine Teilmenge der Google Maps Platform Routes API-Fortbewegungsmittel sein. Weitere Informationen finden Sie unter https://developers.google.com/maps/documentation/routes/reference/rest/v2/RouteTravelMode.

Hinweis: WALKING-Routen befinden sich in der Betaphase und enthalten möglicherweise nicht immer ausgewiesene Gehwege oder Fußgängerwege. Sie müssen diese Warnung für alle Fußgängerrouten, die Sie in Ihrer App anzeigen, für den Nutzer einblenden.

Enums
TRAVEL_MODE_UNSPECIFIED Nicht angegebene Mobilitätsform, entspricht DRIVING.
DRIVING Mobilitätsform, die der Wegbeschreibung entspricht (Auto usw.).
WALKING Mobilitätsform für die Wegbeschreibung für Fußgänger.

UnloadingPolicy

Richtlinie zum Entladen eines Fahrzeugs. Gilt nur für Sendungen mit Abholung und Zustellung.

Andere Sendungen können unabhängig von unloading_policy überall auf der Route erfolgen.

Enums
UNLOADING_POLICY_UNSPECIFIED Keine Angaben zur Entladung; Lieferungen müssen nur nach den entsprechenden Abholungen erfolgen.
LAST_IN_FIRST_OUT Lieferungen müssen in umgekehrter Reihenfolge der Abholungen erfolgen
FIRST_IN_FIRST_OUT Lieferungen müssen in derselben Reihenfolge wie Abholungen erfolgen

VehicleFullness

VehicleFullness ist ein Messwert, der angibt, wie voll ein Fahrzeug ist. Jedes VehicleFullness-Feld liegt zwischen 0 und 1 und wird als Verhältnis zwischen einem gedeckelten Messwertfeld (z. B. AggregatedMetrics.travel_distance_meters) und dem zugehörigen Fahrzeuglimit (z. B. Vehicle.route_distance_limit) berechnet, sofern es vorhanden ist. Andernfalls bleibt das Füllstandsverhältnis nicht festgelegt. Wenn das Limit 0 ist, wird das Feld auf 1 gesetzt. Hinweis: Wenn eine Route aufgrund von Verkehrsbeeinträchtigungen nicht durchführbar ist, können einige Rohfüllstandsverhältnisse 1,0 überschreiten, z. B. wenn das Fahrzeug sein Distanzlimit überschreitet. In diesen Fällen deckeln wir die Füllstandswerte auf 1,0.

Felder
max_fullness

double

Maximum aller anderen Felder in dieser Nachricht.

distance

double

Das Verhältnis zwischen AggregatedMetrics.travel_distance_meters und Vehicle.route_distance_limit. Wenn Vehicle.route_distance_limit nicht festgelegt ist, ist auch dieses Feld nicht festgelegt.

travel_duration

double

Das Verhältnis zwischen [AggregatedMetrics.travel_duration_seconds][] und Vehicle.travel_duration_limit. Wenn Vehicle.travel_duration_limit nicht festgelegt ist, ist auch dieses Feld nicht festgelegt.

active_duration

double

Das Verhältnis zwischen [AggregatedMetrics.total_duration_seconds][] und Vehicle.route_duration_limit. Wenn Vehicle.route_duration_limit nicht festgelegt ist, ist auch dieses Feld nicht festgelegt.

max_load

double

Das maximale Verhältnis zwischen allen Arten von [AggregatedMetrics.max_load][] und den entsprechenden Vehicle.load_limits. Wenn alle Vehicle.load_limits-Felder nicht festgelegt sind, ist dieses Feld nicht festgelegt.

active_span

double

Das Verhältnis (vehicle_end_time – vehicle_start_time) / (latest_vehicle_end_time – earliest_vehicle_start_time) für ein bestimmtes Fahrzeug. Wenn der Nenner nicht vorhanden ist, wird stattdessen (ShipmentModel.global_end_time – ShipmentModel.global_start_time) verwendet.

Zwischenstopp

Kapselt einen Wegpunkt. Wegpunkte markieren Ankunfts- und Abfahrtsorte von VisitRequests sowie Start- und Endorte von Fahrzeugen.

Felder
side_of_road

bool

Optional. Gibt an, dass das Fahrzeug an einer bestimmten Straßenseite anhalten soll. Wenn Sie diesen Wert festlegen, verläuft die Route durch den Ort, sodass das Fahrzeug am Straßenrand anhalten kann, der vom Straßenmittelpunkt aus in Richtung des Ortes liegt. Diese Option funktioniert nicht für die Mobilitätsform „WALKING“.

vehicle_stopover

bool

Gibt an, dass der Wegpunkt für Fahrzeuge vorgesehen ist, an denen sie anhalten, um Personen ein- oder aussteigen zu lassen. Diese Option funktioniert nur für den Fortbewegungsmittelmodus „DRIVING“ und wenn „location_type“ auf „location“ festgelegt ist.

Testphase: Das Verhalten oder die Existenz dieses Felds kann sich in Zukunft ändern.

Union-Feld location_type. Verschiedene Möglichkeiten, einen Ort darzustellen. Für location_type ist nur einer der folgenden Werte zulässig:
location

Location

Ein Punkt, der mit geografischen Koordinaten angegeben wird, einschließlich einer optionalen Richtung.

place_id

string

Die POI-Orts-ID, die dem Wegpunkt zugeordnet ist.

Wenn Sie eine Orts-ID verwenden, um den Ankunfts- oder Abfahrtsort einer VisitRequest anzugeben, muss diese Orts-ID spezifisch genug sein, um einen LatLng-Standort für die Navigation zum Ort zu bestimmen. Eine Orts-ID, die ein Gebäude repräsentiert, ist beispielsweise geeignet, eine Orts-ID, die eine Straße repräsentiert, jedoch nicht.