Package google.maps.routeoptimization.v1

Index

• RouteOptimization (Benutzeroberfläche)
• AggregatedMetrics (Meldung)
• BatchOptimizeToursMetadata (Meldung)
• BatchOptimizeToursRequest (Meldung)
• BatchOptimizeToursRequest.AsyncModelConfig (Meldung)
• BatchOptimizeToursResponse (Meldung)
• BreakRule (Meldung)
• BreakRule.BreakRequest (Meldung)
• BreakRule.FrequencyConstraint (Meldung)
• DataFormat (Aufzählung)
• DistanceLimit (Meldung)
• GcsDestination (Meldung)
• GcsSource (Meldung)
• InjectedSolutionConstraint (Meldung)
• InjectedSolutionConstraint.ConstraintRelaxation (Meldung)
• InjectedSolutionConstraint.ConstraintRelaxation.Relaxation (Meldung)
• InjectedSolutionConstraint.ConstraintRelaxation.Relaxation.Level (Aufzählung)
• InputConfig (Meldung)
• Location (Meldung)
• OptimizeToursLongRunningMetadata (Meldung)
• OptimizeToursRequest (Meldung)
• OptimizeToursRequest.SearchMode (Option)
• OptimizeToursRequest.SolvingMode (Option)
• OptimizeToursResponse (Meldung)
• OptimizeToursResponse.Metrics (Meldung)
• OptimizeToursUriMetadata (Meldung)
• OptimizeToursUriRequest (Meldung)
• OptimizeToursUriResponse (Meldung)
• OptimizeToursValidationError (Meldung)
• OptimizeToursValidationError.FieldReference (Meldung)
• OutputConfig (Meldung)
• RouteModifiers (Meldung)
• Shipment (Meldung)
• Shipment.Load (Meldung)
• Shipment.VisitRequest (Meldung)
• ShipmentModel (Meldung)
• ShipmentModel.DurationDistanceMatrix (Meldung)
• ShipmentModel.DurationDistanceMatrix.Row (Meldung)
• ShipmentModel.Objective (Meldung)
• ShipmentModel.Objective.Type (Aufzählung)
• ShipmentModel.PrecedenceRule (Meldung)
• ShipmentRoute (Meldung)
• ShipmentRoute.Break (Meldung)
• ShipmentRoute.EncodedPolyline (Meldung)
• ShipmentRoute.Transition (Meldung)
• ShipmentRoute.VehicleLoad (Meldung)
• ShipmentRoute.Visit (Meldung)
• ShipmentRoute.Visit.VisitType (Aufzählung)
• ShipmentTypeIncompatibility (Meldung)
• ShipmentTypeIncompatibility.IncompatibilityMode (Aufzählung)
• ShipmentTypeRequirement (Meldung)
• ShipmentTypeRequirement.RequirementMode (Aufzählung)
• SkippedShipment (Meldung)
• SkippedShipment.Reason (Meldung)
• SkippedShipment.Reason.Code (Aufzählung)
• TimeWindow (Meldung)
• TransitionAttributes (Meldung)
• Uri (Meldung)
• Vehicle (Meldung)
• Vehicle.DurationLimit (Meldung)
• Vehicle.LoadLimit (Meldung)
• Vehicle.LoadLimit.Interval (Meldung)
• Vehicle.LoadLimit.LoadCost (Meldung)
• Vehicle.TravelMode (Option)
• Vehicle.UnloadingPolicy (Option)
• VehicleFullness (Meldung)
• Waypoint (Meldung)

RouteOptimization

Ein Dienst zur Optimierung von Fahrzeugtouren.

Gültigkeit bestimmter Feldtypen:

• google.protobuf.Timestamp
  • Die Zeiten sind in Unixzeit angegeben: Sekunden seit dem 01.01.1970, 00: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 zwischen -90,0 und 90,0 liegen.
  • Der Längengrad muss zwischen -180,0 und 180,0 liegen.
  • Mindestens einer der Werte für den Breiten- und Längengrad darf nicht null sein.

BatchOptimizeTours

rpc BatchOptimizeTours(BatchOptimizeToursRequest) returns (Operation) Optimiert Fahrzeugtouren für eine oder mehrere OptimizeToursRequest-Nachrichten als Batch. Diese Methode ist ein Vorgang mit langer Ausführungszeit (Long-Running Operation, LRO). Die Eingaben für die Optimierung (OptimizeToursRequest-Nachrichten) und die Ausgaben (OptimizeToursResponse-Nachrichten) werden im vom Nutzer angegebenen Format aus Cloud Storage gelesen und in Cloud Storage geschrieben. Wie die OptimizeTours-Methode enthält jede OptimizeToursRequest eine ShipmentModel und gibt eine OptimizeToursResponse mit ShipmentRoute-Feldern zurück. Diese Felder enthalten 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 LRO-Feld done „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 „true“ ist, wurden alle Anfragen verarbeitet. Die Ergebnisse aller erfolgreich verarbeiteten Anfragen sind in Cloud Storage verfügbar. Für fehlgeschlagene Anfragen sind die Ergebnisse nicht in Cloud Storage verfügbar. Wenn das Feld error des LRO festgelegt ist, enthält es den Fehler aus 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 ShipmentRoutes zurück. Das sind 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, die zum Transport der Shipments verwendet werden können. Die ShipmentRoutes weisen Shipments zu 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 einen Shipment. Das Ziel ist es, ShipmentRoutes zu 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 Zeitlimitwerten entwickelt wurde. Sie sollte für Optimierungen, die länger als ein paar Minuten dauern, der Methode OptimizeTours vorgezogen werden. Der zurückgegebene long-running operation (LRO) 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, wenn der Vorgang erfolgreich war. 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 Methode OptimizeToursLongRunning, die für Optimierungen mit großen Zeitlimitwerten und großen Eingabe-/Ausgabegrößen entwickelt wurde. Der Client gibt den URI des in Google Cloud Storage gespeicherten OptimizeToursRequest an und der Server schreibt den OptimizeToursResponse in einen vom Client angegebenen Google Cloud Storage-URI. Diese Methode sollte der Methode OptimizeTours für Optimierungen vorgezogen werden, die länger als ein paar Minuten dauern, und für Eingabe-/Ausgabegrößen, die größer als 8 MB sind. Sie kann jedoch auch für kürzere und kleinere Optimierungen verwendet werden. Der zurückgegebene long-running operation (LRO) hat einen Namen im Format <parent>/operations/<operation_id> und kann verwendet werden, um den Fortschritt der Berechnung zu verfolgen. Der Feldtyp metadata ist OptimizeToursUriMetadata. Der Feldtyp response ist OptimizeToursUriResponse, wenn der Vorgang erfolgreich war. 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) über alle Transition- und/oder Visit-Elemente (bzw. über alle ShipmentRoute-Elemente).

Felder
performed_shipment_count	int32 Anzahl der ausgeführten Sendungen. Ein Abhol- und Lieferpaar wird nur einmal gezählt.
travel_duration	Duration Gesamte Reisedauer für eine Route oder eine Lösung.
wait_duration	Duration Gesamte Wartezeit für eine Route oder Lösung.
delay_duration	Duration Gesamtverzögerungsdauer für eine Route oder eine Lösung.
break_duration	Duration Gesamtdauer der Pausen für eine Route oder Lösung.
visit_duration	Duration Gesamtdauer des Besuchs für eine Route oder eine Lösung.
total_duration	Duration Die Gesamtdauer sollte der Summe aller oben genannten Dauern entsprechen. Bei Routen entspricht es außerdem Folgendem: [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 Gesamte Reisedistanz für eine Route oder Lösung.
max_loads	map<string, VehicleLoad> Maximale Last, die auf der gesamten Route (bzw. Lösung) für jede der Mengen auf dieser Route (bzw. Lösung) erreicht wurde, berechnet als Maximum über alle Transition.vehicle_loads (bzw. ShipmentRoute.metrics.max_loads.
performed_mandatory_shipment_count	int32 Anzahl der ausgeführten obligatorischen Sendungen. Experimentell: 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 ausgeführten Sendungen. Experimentell: 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 zur Batchoptimierung von Touren als asynchroner Vorgang. Jede Eingabedatei sollte eine OptimizeToursRequest enthalten und jede Ausgabedatei eine OptimizeToursResponse. Die Anfrage enthält Informationen zum Lesen/Schreiben und Parsen der Dateien. Alle Eingabe- und Ausgabedateien müssen sich im selben Projekt befinden.

Felder
parent	string Erforderlich. Zielprojekt und Standort zum Anrufen festlegen. Format: projects/{project-id} projects/{project-id}/locations/- Regionale {location-id}-Werte werden nicht unterstützt.
model_configs[]	AsyncModelConfig Erforderlich. Eingabe-/Ausgabeinformationen 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 Benutzern als Alias verwendet werden kann, um den Überblick über Modelle 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 wird nach Abschluss des Vorgangs mit langer Ausführungszeit zurückgegeben.

BreakRule

Regeln zum Generieren von Pausen 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 keine Besuche ausführen kann. Eine Unterbrechung kann in folgenden Fällen auftreten:

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

Felder
break_requests[]	BreakRequest Reihenfolge der Pausen. Siehe die Nachricht BreakRequest.
frequency_constraints[]	FrequencyConstraint Es können mehrere FrequencyConstraint gelten. Sie müssen alle von den BreakRequests dieses BreakRule erfüllt werden. Siehe FrequencyConstraint.

BreakRequest

Die Abfolge 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. Ihre Zeitfenster (earliest_start_time / latest_start_time) können sich überschneiden, müssen aber mit der Bestellung kompatibel sein (dies wird geprüft).

Felder
earliest_start_time	Timestamp Erforderlich. Untergrenze (einschließlich) 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 Unterbrechung. Muss positiv sein.

FrequencyConstraint

Sie können die Häufigkeit und Dauer der oben angegebenen Pausen weiter einschränken, indem Sie eine Mindesthäufigkeit für Pausen erzwingen, z. B. „Alle 12 Stunden muss eine Pause von mindestens 1 Stunde eingelegt werden“. Angenommen, dies kann als „Innerhalb eines beliebigen gleitenden Zeitfensters von 12 Stunden muss es mindestens eine Pause von mindestens einer Stunde geben“ interpretiert werden. Dann würde dieses Beispiel in die folgende FrequencyConstraint übersetzt werden:

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

Der Zeitpunkt 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 für nicht aufeinanderfolgende Pausen gelten. Der folgende Zeitplan entspricht beispielsweise dem Beispiel „1 Stunde alle 12 Stunden“:

  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 Unterbrechung für diese Einschränkung. Nicht negativ. Siehe Beschreibung von FrequencyConstraint.
max_inter_break_duration	Duration Erforderlich. Maximal zulässige Dauer eines Zeitintervalls auf der Route, das nicht mindestens teilweise eine Pause von duration >= min_break_duration enthält. Muss positiv sein.

DataFormat

Datenformate für Eingabe- und Ausgabedateien.

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

DistanceLimit

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

Wenn ein weiches 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 Ein festes Limit, das die Entfernung auf maximal „max_meters“ beschränkt. Das Limit darf nicht negativ sein.
soft_max_meters	int64 Ein weiches Limit, das keine maximale Entfernung erzwingt, aber bei Überschreitung zu Kosten führt, die zu anderen im Modell definierten Kosten mit derselben Einheit addiert werden. 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, bis zu soft_max_meters, mit der 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 über dem Limit von soft_max_meters liegt. Die zusätzlichen Kosten betragen 0, wenn die Entfernung unter dem Limit liegt. Andernfalls werden die Kosten mit der folgenden Formel berechnet: (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 Ausgabedateien 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

In die Anfrage eingefügte Lösung, einschließlich Informationen darüber, welche Besuche eingeschränkt werden müssen und wie sie eingeschränkt werden müssen.

Felder
routes[]	ShipmentRoute Routen der einzufügenden Lösung. Einige Routen werden möglicherweise aus der ursprünglichen Lösung weggelassen. Die Routen und übersprungenen Sendungen müssen die grundlegenden Gültigkeitsannahmen erfüllen, die für injected_first_solution_routes aufgeführt sind.
skipped_shipments[]	SkippedShipment Übersprungene Sendungen der Lösung, die eingefügt werden sollen. Einige werden möglicherweise in der ursprünglichen Lösung weggelassen. Siehe 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, sind alle nicht leeren Fahrzeugrouten vollständig eingeschränkt.

ConstraintRelaxation

Gibt für eine Gruppe von Fahrzeugen an, bei welchen Schwellenwerten Einschränkungen für Besuche gelockert werden und auf welcher Ebene. Die im Feld skipped_shipment aufgeführten Sendungen müssen übersprungen werden, d.h. sie können nicht ausgeführt werden.

Felder
relaxations[]	Relaxation Alle Lockerungen der Besuchsbeschränkungen, die für Besuche auf Routen mit Fahrzeugen in vehicle_indices gelten.
vehicle_indices[]	int32 Gibt die Fahrzeugindizes an, für die die Besuchseinschränkung relaxations gilt. Wenn das Feld leer ist, wird es als Standardwert betrachtet und die relaxations gelten für alle Fahrzeuge, die nicht in anderen constraint_relaxations angegeben sind. Es kann höchstens einen Standardwert geben, d.h., höchstens ein Feld für die Lockerung von Einschränkungen darf leer sein (vehicle_indices). Ein Fahrzeugindex kann nur einmal aufgeführt werden, auch innerhalb mehrerer constraint_relaxations. Ein Fahrzeugindex wird genauso zugeordnet wie ShipmentRoute.vehicle_index, 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 am routes vollständig eingeschränkt und es können 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 die Lockerungsstufe für Einschränkungen an, die auf einen Besuch #j angewendet wird, für den Folgendes gilt:

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

Ebenso wird der Fahrzeugstart auf relaxations(i).level gelockert, wenn Folgendes erfüllt ist:

• 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 erfüllt ist:
• 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, bei der nur threshold_visit_count festgelegt ist, und eine, bei der nur threshold_time festgelegt ist. Wenn ein Besuch die Bedingungen mehrerer relaxations erfüllt, gilt die am wenigsten restriktive Ebene. Daher wird die Lockerungsstufe vom Fahrzeugstart über die Routenbesuche in der Reihenfolge bis zum Fahrzeugende immer lockerer, d.h., die Lockerungsstufe nimmt im Verlauf der Route nicht ab.

Der Zeitpunkt und die Reihenfolge der Besuche auf der Route, die die Grenzwerte von relaxations nicht erfüllen, sind vollständig eingeschränkt. In diese Reihenfolgen dürfen keine Besuche eingefügt werden. Wenn der Start oder das Ende eines Fahrzeugs nicht die Bedingungen einer Lockerung erfüllt, ist die Zeit festgelegt, es sei denn, das Fahrzeug ist leer.

Felder
level	Level Die Lockerungsstufe für Einschränkungen, die gilt, wenn die Bedingungen am oder nach dem threshold_time UND mindestens threshold_visit_count erfüllt sind.
threshold_time	Timestamp Der Zeitpunkt, ab dem die Lockerung level angewendet werden kann.
threshold_visit_count	int32 Die Anzahl der Besuche, ab der die Lockerung level angewendet werden kann. Wenn threshold_visit_count 0 (oder nicht festgelegt) ist, kann die level direkt beim Start des Fahrzeugs angewendet werden. Wenn der Wert route.visits_size() + 1 ist, darf die level nur auf das Fahrzeugende angewendet werden. Wenn der Wert größer als route.visits_size() + 1 ist, wird level für diese Route überhaupt nicht angewendet.

Level

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

Die folgende Aufzählung ist in der Reihenfolge zunehmender Lockerung aufgeführt.

Enums
LEVEL_UNSPECIFIED	Implizite Standard-Lockerungsstufe: Es werden keine Einschränkungen gelockert, d.h. alle Besuche sind vollständig eingeschränkt. Dieser Wert darf nicht explizit in level verwendet werden.
RELAX_VISIT_TIMES_AFTER_THRESHOLD	Die Startzeiten der Besuche und die Start-/Endzeiten der Fahrzeuge werden gelockert, aber jeder Besuch bleibt an dasselbe Fahrzeug gebunden und die Besuchsreihenfolge muss eingehalten werden: Es kann kein Besuch zwischen oder vor ihnen eingefügt werden.
RELAX_VISIT_TIMES_AND_SEQUENCE_AFTER_THRESHOLD	Wie RELAX_VISIT_TIMES_AFTER_THRESHOLD, aber die Besuchsreihenfolge wird ebenfalls gelockert: Besuche können nur von diesem Fahrzeug ausgeführt werden, aber möglicherweise nicht ausgeführt werden.
RELAX_ALL_AFTER_THRESHOLD	Wie RELAX_VISIT_TIMES_AND_SEQUENCE_AFTER_THRESHOLD, aber das Fahrzeug ist auch entspannt: Besuche sind zum oder nach dem Schwellenwertzeitpunkt völlig kostenlos und können möglicherweise nicht ausgeführt werden.

InputConfig

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

Felder
data_format	DataFormat Erforderlich. Das Eingabedatenformat.
Union-Feld source. Erforderlich. Für source ist nur einer der folgenden Werte zulässig:
gcs_source	GcsSource Ein Google Cloud Storage-Speicherort. Dies muss ein einzelnes Objekt (eine einzelne Datei) sein.

Standort

Kapselt einen Standort (einen geografischen Punkt und eine optionale Überschrift).

Felder
lat_lng	LatLng Die geografischen Koordinaten des Wegpunkts.
heading	int32 Der Kompasskurs, der der Richtung des Verkehrsflusses zugeordnet ist. Mit diesem Wert wird die Straßenseite für die Abholung und den Ausstieg angegeben. Die Werte für die Fahrtrichtung 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 Tourenoptimierungs-Solver gesendet werden soll, der das zu lösende Sendungsmodell sowie Optimierungsparameter definiert.

Felder
parent	string Erforderlich. Zielprojekt oder Standort zum Anrufen festlegen. Format: projects/{project-id} projects/{project-id}/locations/- Regionale {location-id}-Werte werden nicht unterstützt.
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 früher eintritt. Bei asynchronen Anfragen generiert der Server (wenn möglich) eine Lösung, bevor das Zeitlimit abgelaufen ist.
model	ShipmentModel Zu lösendes Sendungsmodell.
solving_mode	SolvingMode Standardmäßig ist der Lösungsmodus DEFAULT_SOLVE (0).
search_mode	SearchMode Suchmodus, der zum Lösen der Anfrage verwendet wird.
injected_first_solution_routes[]	ShipmentRoute Den Optimierungsalgorithmus anleiten, eine erste Lösung zu finden, die einer vorherigen 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: Für alle Routen muss vehicle_index im Bereich liegen und darf nicht dupliziert werden. Für alle Besuche müssen shipment_index und visit_request_index im Bereich liegen. Eine Sendung darf nur auf einer Route referenziert werden. Die Abholung einer Abhol- und Lieferlieferung muss vor der Lieferung erfolgen. darf maximal eine Abhol- oder Lieferalternative für eine Sendung durchgeführt werden. für alle Routen die Zeiten zunehmen (d.h. vehicle_start_time <= visits[0].start_time <= visits[1].start_time ... <= vehicle_end_time). Eine Sendung darf nur mit einem zulässigen Fahrzeug ausgeführt werden. Ein Fahrzeug ist zulässig, wenn Shipment.allowed_vehicle_indices leer ist oder der Wert für vehicle_index in Shipment.allowed_vehicle_indices enthalten ist. Wenn die eingefügte Lösung nicht möglich 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 Schränken Sie den Optimierungsalgorithmus ein, um eine endgültige Lösung zu finden, die einer vorherigen Lösung ähnelt. Damit können beispielsweise Teile von Routen eingefroren werden, die bereits abgeschlossen sind oder die abgeschlossen werden sollen, aber nicht geändert werden dürfen. Wenn die eingefügte Lösung nicht möglich 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 das Feld nicht leer ist, werden die angegebenen Routen aktualisiert, ohne dass die zugrunde liegende Reihenfolge der Besuche oder die Fahrzeiten geändert werden. 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 Stopps in allen nicht leeren Routen ausgefüllt, unabhängig davon, ob die zugehörigen Sendungen oder Fahrzeuge ignoriert werden.
interpret_injected_solutions_using_labels	bool Wenn „true“: Verwendet ShipmentRoute.vehicle_label anstelle von vehicle_index, um Routen in einer eingefügten Lösung mit Fahrzeugen in der Anfrage abzugleichen. Die Zuordnung der ursprünglichen ShipmentRoute.vehicle_index zu den neuen ShipmentRoute.vehicle_index wird wiederverwendet, um ConstraintRelaxation.vehicle_indices zu aktualisieren, falls nicht leer. Die Zuordnung muss jedoch eindeutig sein (d. h., mehrere ShipmentRoute dürfen nicht dieselbe ursprüngliche vehicle_index haben). verwendet ShipmentRoute.Visit.shipment_label anstelle von shipment_index, um Besuche in einer eingefügten Lösung mit Sendungen in der Anfrage abzugleichen; verwendet SkippedShipment.label anstelle von SkippedShipment.index, um übersprungene Sendungen in der eingefügten Lösung mit Anfragesendungen abzugleichen. 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 Sendungs- oder Fahrzeugindizes 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. Wenn „true“, dürfen Labels in den folgenden Kategorien höchstens einmal in ihrer Kategorie vorkommen: Vehicle.label in der Anfrage; Shipment.label in der Anfrage; ShipmentRoute.vehicle_label in der injizierten Lösung; SkippedShipment.label und ShipmentRoute.Visit.shipment_label in der eingefügten Lösung (außer Abhol-/Lieferbesuchspaare, deren shipment_label zweimal vorkommen muss). Wenn ein vehicle_label in der eingefügten Lösung nicht einem Fahrzeug in der Anfrage 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 keiner angeforderten Sendung entspricht, wird der entsprechende Besuch aus der Lösung entfernt. Wenn ein SkippedShipment.label in der eingefügten Lösung keiner Sendung in der Anfrage entspricht, wird der SkippedShipment aus der Lösung entfernt. Wenn Sie Routenbesuche oder ganze Routen aus einer eingefügten Lösung entfernen, kann sich das auf die implizierten Einschränkungen auswirken. Dies kann zu einer Änderung der Lösung, zu Validierungsfehlern oder zu einer Unmöglichkeit der Ausführung führen. HINWEIS: Der Aufrufer muss dafür sorgen, dass jedes Vehicle.label (bzw. Shipment.label) identifiziert eindeutig eine Fahrzeug- (bzw. Sendungs-)Entität, die in den beiden relevanten Anfragen verwendet wird: der früheren Anfrage, die die in der eingefügten Lösung verwendete OptimizeToursResponse erzeugt 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 ShipmentRoute-Felder 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 den ShipmentRoutes der Antwort eingefügt.
populate_transition_polylines	bool Wenn „true“, werden Polylinien und Routentokens in der Antwort ShipmentRoute.transitions ausgefüllt.
allow_large_deadline_despite_interruption_risk	bool Wenn diese Option 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 langlebige Anfragen ein deutlich größeres (aber immer noch geringes) Risiko für Unterbrechungen haben.
use_geodesic_distances	bool Wenn „true“, werden Entfernungen anhand von geodätischen Entfernungen anstelle von Google Maps-Entfernungen berechnet. Die Reisezeiten werden anhand von geodätischen Entfernungen mit einer durch geodesic_meters_per_second definierten Geschwindigkeit berechnet.
label	string Label, das zur Identifizierung dieser Anfrage verwendet werden kann und in der OptimizeToursResponse.request_label zurückgegeben wird.
geodesic_meters_per_second	double Wenn use_geodesic_distances auf „true“ gesetzt ist, muss dieses Feld festgelegt werden. Es definiert die Geschwindigkeit, die zur Berechnung der Reisedauer 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 werden in der Regel als BadRequest-Fehlerdetail (https://cloud.google.com/apis/design/errors#error_details)) an eine INVALID_ARGUMENT-Fehlernutzlast angehängt, es sei denn, solving_mode=VALIDATE_ONLY: siehe 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 Anfragefrist erzwungen.

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	Die gesamte verfügbare Zeit für die Suche nach besseren Lösungen aufwenden.

SolvingMode

Definiert, wie der Solver die Anfrage verarbeiten soll. In allen Modi außer VALIDATE_ONLY erhalten Sie bei einer ungültigen Anfrage den Fehler INVALID_REQUEST. Unter max_validation_errors finden Sie Informationen dazu, wie Sie die Anzahl der zurückgegebenen Fehler begrenzen können.

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	Validiert nur das Modell, ohne es zu lösen: füllt so viele OptimizeToursResponse.validation_errors wie möglich aus.
DETECT_SOME_INFEASIBLE_SHIPMENTS	Nur OptimizeToursResponse.validation_errors oder OptimizeToursResponse.skipped_shipments wird ausgefüllt und der Rest der Anfrage wird nicht gelöst (status und routes sind in der Antwort nicht festgelegt). Wenn in injected_solution_constraint-Routen Unzulässigkeiten erkannt werden, werden sie in das Feld OptimizeToursResponse.validation_errors eingetragen und OptimizeToursResponse.skipped_shipments bleibt leer. WICHTIG: Hier werden nicht alle nicht ausführbaren Sendungen zurückgegeben, sondern nur die, die während der Vorverarbeitung als nicht ausführbar erkannt werden.
TRANSFORM_AND_RETURN_REQUEST	Dieser Modus funktioniert nur, wenn ShipmentModel.objectives nicht leer ist. Die Anfrage ist nicht gelöst. Er wird nur validiert und mit Kosten gefüllt, die den angegebenen Zielen entsprechen. 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 dem Lösen eines Tourenoptimierungsproblems, die die von jedem Fahrzeug zurückgelegten Routen, die übersprungenen Sendungen und die Gesamtkosten der Lösung enthält.

Felder
routes[]	ShipmentRoute Für jedes Fahrzeug berechnete Routen. Die i-te Route entspricht dem i-ten Fahrzeug im Modell.
request_label	string Kopie des 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 erkennen konnten. Weitere Informationen finden Sie in der Erklärung zu „MULTIPLE ERRORS“ für die Nachricht OptimizeToursValidationError. Anstelle von Fehlern werden Warnungen angezeigt, wenn solving_mode den Wert DEFAULT_SOLVE hat.
processed_request	OptimizeToursRequest In einigen Fällen ändern wir die eingehende Anfrage, bevor wir sie lösen, z.B. durch Hinzufügen von Kosten. Wenn „solving_mode == TRANSFORM_AND_RETURN_REQUEST“, wird hier die geänderte Anfrage zurückgegeben. Experimentell: Weitere Informationen finden Sie unter https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request.
metrics	Metrics Dauer, Entfernung und Nutzungsmesswerte für diese Lösung.

Messwerte

Gesamtmesswerte, aggregiert über alle Routen.

Felder
aggregated_route_metrics	AggregatedMetrics Über die Routen aggregiert. Jeder Messwert ist die Summe (oder der Höchstwert für Lasten) aller ShipmentRoute.metrics-Felder mit demselben Namen.
skipped_mandatory_shipment_count	int32 Anzahl der übersprungenen obligatorischen Sendungen.
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 Der früheste Beginn für ein verwendetes Fahrzeug, berechnet als Minimum über alle verwendeten Fahrzeuge von ShipmentRoute.vehicle_start_time.
latest_vehicle_end_time	Timestamp Die späteste Endzeit für ein verwendetes Fahrzeug, berechnet als Maximum über alle verwendeten Fahrzeuge von ShipmentRoute.vehicle_end_time.
costs	map<string, double> Kosten der Lösung, aufgeschlüsselt nach kostenbezogenen Anfragefeldern. Die Schlüssel sind Proto-Pfade, relativ zur Eingabe „OptimizeToursRequest“, 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, mit Ausnahme der Kosten im Zusammenhang mit TransitionAttributes, die ab Januar 2022 nur noch aggregiert aufgeführt 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/- Regionale {location-id}-Werte werden nicht unterstützt.
input	Uri Erforderlich. Der URI des Cloud Storage-Objekts, das die OptimizeToursRequest enthält.
output	Uri Erforderlich. Der URI des Cloud Storage-Objekts, das die 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, entweder als JSON oder als textproto codiert. 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 der Inhalt der Ressource geändert wurde.

OptimizeToursValidationError

Beschreibt einen Fehler oder eine Warnung, die bei der Validierung 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. MEHRERE FEHLER: Wenn mehrere Fehler vorliegen, versucht der Validierungsprozess, mehrere davon auszugeben. Ähnlich wie bei einem Compiler ist dies ein unvollkommener Prozess. Einige Validierungsfehler sind „schwerwiegend“, d. h., sie beenden den gesamten Validierungsprozess. Dies ist u. a. bei display_name="UNSPECIFIED"-Fehlern der Fall. Einige Fehler können dazu führen, dass der Validierungsprozess andere Fehler überspringt. STABILITÄT: code und display_name sollten sehr stabil sein. Im Laufe der Zeit können jedoch neue Codes und Anzeigenamen hinzukommen. Das kann dazu führen, dass eine bestimmte (ungültige) Anfrage ein anderes (code, display_name)-Paar ergibt, weil der neue Fehler den alten verdeckt. Beispiel: „MULTIPLE ERRORS“.
display_name	string Der Anzeigename des Fehlers.
fields[]	FieldReference Ein Fehlerkontext kann 0, 1 (meistens) oder mehr Felder umfassen. Beispielsweise können Sie sich so auf Fahrzeug 4 und die erste Abholung von Sendung 2 beziehen: fields { name: "vehicles" index: 4} fields { name: "shipments" index: 2 sub_field {name: "pickups" index: 0} } Beachten Sie jedoch, dass sich die Kardinalität von fields für einen bestimmten Fehlercode nicht ändern sollte.
error_message	string Menschenlesbarer 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. Diese Option ist nicht immer verfügbar. Sie sollten sich auf keinen Fall darauf verlassen und es nur für das manuelle Modell-Debugging 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: Element 2 von start_time_windows für Fahrzeug 5 kann so angegeben werden:

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

Wir lassen jedoch Entitäten auf oberster Ebene wie OptimizeToursRequest oder ShipmentModel weg, um die Nachricht nicht zu überladen.

Felder
name	string Name des Felds, z.B. „vehicles“.
sub_field	FieldReference Rekursiv verschachteltes Unterfeld, falls erforderlich.
Union-Feld index_or_key. Für index_or_key ist nur einer der folgenden Werte zulässig:
index	int32 Index des Felds, falls wiederholt.
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 bei der Berechnung von Fahrzeugrouten erfüllt werden müssen. Dies ähnelt RouteModifiers in der Routes Preferred API der Google Maps Platform. 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 Verkehrsmittel.
avoid_highways	bool Gibt an, ob Autobahnen nach Möglichkeit vermieden werden sollen. Routen ohne Autobahnen werden bevorzugt. Gilt nur für motorisierte Fortbewegungsarten.
avoid_ferries	bool Gibt an, ob Fähren nach Möglichkeit vermieden werden sollen. Routen ohne Fähren werden bevorzugt. Gilt nur für motorisierte Fortbewegungsarten.
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 Mobilitätsmodus WALKING.

Versand

Die Sendung eines einzelnen Artikels von einer der Abholungen zu einer der Lieferungen. Damit eine Sendung als ausgeführt gilt, muss ein einzelnes Fahrzeug einen ihrer Abholorte besuchen (und seine freien Kapazitäten entsprechend verringern) und später einen ihrer Lieferorte besuchen (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 nicht angegeben, muss das Fahrzeug nur einen Ort anfahren, der den Lieferungen entspricht.
deliveries[]	VisitRequest Satz von Lieferalternativen, die mit der Sendung verknüpft sind. Wenn nicht angegeben, muss das Fahrzeug nur einen Ort besuchen, der den Abholungen entspricht.
load_demands	map<string, Load> Ladeanforderungen der Sendung (z. B. Gewicht, Volumen, Anzahl der Paletten usw.) Die Schlüssel in der Zuordnung sollten IDs sein, die den Typ der entsprechenden Last beschreiben, idealerweise auch mit den Einheiten. Beispiele: „weight_kg“, „volume_gallons“, „pallet_count“ usw. Wenn ein bestimmter Schlüssel nicht in der Zuordnung enthalten ist, wird die entsprechende Last als null betrachtet.
allowed_vehicle_indices[]	int32 Die Fahrzeuge, die diese Sendung ausführen können. Wenn das Feld leer ist, können alle Fahrzeuge die Fahrt ausführen. Fahrzeuge werden durch ihren Index in der Liste vehicles des ShipmentModel angegeben.
costs_per_vehicle[]	double Gibt die Kosten an, die anfallen, wenn diese Sendung von jedem Fahrzeug zugestellt wird. Wenn angegeben, muss 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 dem i-ten Fahrzeug 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 Indizes der Fahrzeuge, für die costs_per_vehicle gilt. Wenn das Feld nicht leer ist, muss es dieselbe Anzahl von Elementen wie costs_per_vehicle enthalten. Ein Fahrzeugindex darf nicht mehrmals angegeben werden. Wenn ein Fahrzeug von costs_per_vehicle_indices ausgeschlossen ist, sind die Kosten null.
pickup_to_delivery_absolute_detour_limit	Duration Gibt die maximale absolute Umwegzeit im Vergleich zur kürzesten Route von der Abholung bis zur Lieferung an. Wenn angegeben, muss der Wert nicht negativ sein und die Sendung muss mindestens eine Abholung und eine Lieferung enthalten. Beispiel: t ist die kürzeste Zeit, die benötigt wird, um von der ausgewählten Abholalternative direkt zur ausgewählten Lieferalternative zu gelangen. Wenn Sie pickup_to_delivery_absolute_detour_limit festlegen, wird Folgendes erzwungen: start_time(delivery) - start_time(pickup) <= t + pickup_to_delivery_absolute_detour_limit Wenn für dieselbe Sendung sowohl relative als auch absolute Limits angegeben sind, wird für jedes mögliche Abhol-/Lieferpaar das restriktivere Limit verwendet. Seit Oktober 2017 werden Umwege nur unterstützt, wenn die Reisedauer nicht von Fahrzeugen abhängt.
pickup_to_delivery_time_limit	Duration Gibt die maximale Dauer vom Beginn der Abholung bis zum Beginn der Lieferung einer Sendung an. Wenn angegeben, muss er nicht negativ sein und die Sendung muss mindestens eine Abholung und eine Lieferung enthalten. Dies hängt weder davon ab, welche Alternativen für die Abholung und Lieferung ausgewählt werden, noch von der Fahrzeuggeschwindigkeit. Dies kann zusammen mit Einschränkungen für den maximalen Umweg angegeben werden. Die Lösung berücksichtigt beide Angaben.
shipment_type	string Nicht leere Zeichenfolge, die 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“, wird diese Sendung übersprungen, aber es wird kein penalty_cost angewendet. Wenn Sie eine Sendung ignorieren, führt dies zu einem Validierungsfehler, wenn im Modell shipment_type_requirements vorhanden sind. Das Ignorieren einer Sendung, die in injected_first_solution_routes oder injected_solution_constraint ausgeführt wird, ist zulässig. Der Solver entfernt die zugehörigen Abhol-/Lieferbesuche aus der ausführenden Route. precedence_rules, die sich auf ignorierte Sendungen beziehen, werden ebenfalls ignoriert.
penalty_cost	double Wenn die Sendung nicht abgeschlossen wird, wird diese Strafe zu den Gesamtkosten der Routen addiert. Eine Sendung gilt als abgeschlossen, wenn eine der Abhol- und Lieferalternativen besucht wurde. Die Kosten können in derselben Einheit angegeben werden, die für alle anderen kostenbezogenen Felder im Modell verwendet wird, 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 zur kürzesten Route von der Abholung bis zur Lieferung an. Wenn angegeben, muss er nicht negativ sein und die Sendung muss mindestens eine Abholung und eine Lieferung enthalten. Beispiel: t ist die kürzeste Zeit, die benötigt wird, um von der ausgewählten Abholalternative direkt zur ausgewählten Lieferalternative zu gelangen. Wenn Sie 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 für dieselbe Sendung sowohl relative als auch absolute Limits angegeben sind, wird für jedes mögliche Abhol-/Lieferpaar das restriktivere Limit verwendet. Seit Oktober 2017 werden Umwege nur unterstützt, wenn die Reisedauer nicht von Fahrzeugen abhängt.

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 dieser Betrag definiert. load_demands ansehen.

Felder
amount	int64 Der Betrag, um den sich die Last des Fahrzeugs, das den entsprechenden Besuch ausführt, ändert. Da es sich um eine Ganzzahl handelt, sollten Nutzer eine geeignete Einheit wählen, um Genauigkeitsverluste zu vermeiden. Muss ≥ 0 sein.

VisitRequest

Anfrage für einen Besuch, der von einem Fahrzeug ausgeführt werden kann: Er hat einen Standort (oder zwei, siehe unten), Öffnungs- und Schließzeiten, die durch Zeitfenster dargestellt werden, und eine Servicedauer (Zeit, die das Fahrzeug nach der Ankunft für die Abholung oder Lieferung von Waren benötigt).

Felder
arrival_location	LatLng Der geografische Standort, an dem das Fahrzeug bei der Ausführung dieses VisitRequest ankommt. Wenn das Sendungsmodell Dauermatritzen 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 Sendungsmodell Dauermatritzen enthält, darf arrival_waypoint nicht angegeben werden.
departure_location	LatLng Der geografische Standort, von dem das Fahrzeug nach Abschluss dieses VisitRequest abfährt. Kann weggelassen werden, wenn er mit arrival_location übereinstimmt. Wenn das Sendungsmodell Dauermatrixen 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 er mit arrival_waypoint übereinstimmt. Wenn das Sendungsmodell Dauermatrixen enthält, darf departure_waypoint nicht angegeben werden.
tags[]	string Gibt 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 außerhalb des Ankunftszeitfensters abfahren, d.h. Ankunftszeit + Dauer müssen nicht innerhalb eines Zeitfensters liegen. Dies kann zu Wartezeiten führen, wenn das Fahrzeug vor TimeWindow.start_time ankommt. Wenn TimeWindow nicht vorhanden ist, kann das Fahrzeug diesen Besuch jederzeit ausführen. Zeitfenster dürfen sich nicht überschneiden, d.h. kein Zeitfenster darf sich mit einem anderen überschneiden oder an ein anderes angrenzen, und sie 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. die Zeit, die das Fahrzeug zwischen Ankunft und Abfahrt verbringt (muss zur möglichen Wartezeit hinzugefügt werden; siehe time_windows).
cost	double Kosten für die Erfüllung dieser Besuchsanfrage auf einer Fahrzeugroute. Damit können Sie unterschiedliche Kosten für jede alternative Abholung oder Lieferung einer Sendung bezahlen. Diese Kosten müssen in derselben Einheit wie Shipment.penalty_cost angegeben werden und dürfen nicht negativ sein.
load_demands	map<string, Load> Ladeanforderungen dieser Besuchsanfrage. Dieses Feld entspricht dem Feld Shipment.load_demands, gilt aber nur für diese VisitRequest und nicht für die gesamte Shipment. Die hier aufgeführten Anforderungen werden den in Shipment.load_demands aufgeführten Anforderungen hinzugefügt.
visit_types[]	string Gibt die Typen 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 diese VisitRequest an. Dieses Label wird in der Antwort als visit_label im entsprechenden ShipmentRoute.Visit gemeldet.
avoid_u_turns	bool Gibt an, ob Wendemanöver auf Fahrstrecken an diesem Ort vermieden werden sollen. Die Vermeidung von Wendemanövern erfolgt nach bestem Wissen und Gewissen. Eine vollständige Vermeidung kann nicht garantiert 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 Sendungsmodell enthält eine Reihe von Sendungen, die von einer Reihe von Fahrzeugen ausgeführt werden müssen, wobei die Gesamtkosten minimiert werden müssen. Diese setzen sich zusammen aus:

• die Kosten für die Routenplanung der Fahrzeuge (Summe der Kosten pro Gesamtzeit, Kosten pro Fahrtzeit und Fixkosten für alle Fahrzeuge).
• die Strafen für nicht ausgeführte Sendungen.
• die Kosten für die Gesamtdauer der Sendungen

Felder
shipments[]	Shipment Satz von Sendungen, die im Modell ausgeführt werden müssen.
vehicles[]	Vehicle Satz von Fahrzeugen, die für Besuche verwendet werden können.
objectives[]	Objective Die Zielvorhaben für dieses Modell, die in Kosten umgewandelt werden. Wenn das Eingabemodell nicht leer ist, muss es kostenlos sein. Verwenden Sie solving_mode = TRANSFORM_AND_RETURN_REQUEST, um die geänderte Anfrage zu erhalten. In diesem Fall wird die Anfrage nicht gelöst. Siehe entsprechende 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 werden nicht berücksichtigt. Die Zeitspanne des Modells muss weniger als ein Jahr betragen, d. h., die global_end_time und die global_start_time müssen innerhalb von 31.536.000 Sekunden voneinander liegen. Wenn Sie cost_per_*hour-Felder verwenden, sollten Sie dieses Zeitfenster auf ein kleineres Intervall festlegen, um die Leistung zu erhöhen. Wenn Sie beispielsweise einen einzelnen Tag modellieren, sollten Sie die globalen Zeitlimits auf diesen Tag festlegen. Wenn nicht festgelegt, wird der 1. Januar 1970, 00:00:00 UTC (d. h. Sekunden: 0, Nanosekunden: 0) als Standard verwendet.
global_end_time	Timestamp Wenn nicht festgelegt, wird 00:00:00 UTC, 1. Januar 1971 (d. h. Sekunden: 31536000, Nanosekunden: 0) als Standard 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 Kosten 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 Entfernungen 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. 1 Fahrzeug, das seine Route bei locA beginnt und bei locA beendet. 1 Anfrage für einen Abholbesuch an locB. 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 an locC. 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 die 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 bestimmter 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 Fahrt 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 bestimmter 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 Satz von Rangfolgeregeln, die im Modell erzwungen werden müssen. WICHTIG: Die Verwendung von Rangfolgeregeln schränkt die Größe des Problems ein, das optimiert werden kann. Anfragen mit Rangfolgeregeln, die viele Sendungen enthalten, werden möglicherweise abgelehnt.
max_active_vehicles	int32 Begrenzt die maximale Anzahl aktiver Fahrzeuge. Ein Fahrzeug ist aktiv, wenn auf seiner Route mindestens eine Sendung ausgeführt wird. Damit lässt sich die Anzahl der Routen begrenzen, wenn es weniger Fahrer als Fahrzeuge gibt und die Fahrzeugflotte heterogen ist. Bei der Optimierung wird dann die beste Teilmenge von Fahrzeugen ausgewählt. Muss strikt positiv sein.

DurationDistanceMatrix

Gibt eine Dauer- und Distanzmatrix von den Startorten der Besuche und Fahrzeuge zu den Zielorten der Besuche und Fahrzeuge an.

Felder
rows[]	Row Gibt die Zeilen der Dauer- und Distanzmatrix 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 dies für alle Fahrzeuge und es kann nur eine einzige Matrix geben. Jeder Fahrzeugstart muss genau einer Matrix entsprechen, d.h., genau eines der start_tags-Felder muss mit dem vehicle_start_tag einer Matrix (und nur dieser Matrix) übereinstimmen. Alle Matrizen müssen einen anderen vehicle_start_tag haben.

Zeile

Gibt eine Zeile der Dauer- und Distanzmatrix 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 keine Kosten oder Einschränkungen auf Entfernungen im Modell beziehen, kann dieses Feld leer bleiben. Andernfalls muss es so viele Elemente wie durations enthalten.

Ziel

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

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

Felder
type	Type Der Typ des Ziels.
weight	double Wie stark dieses Ziel im Vergleich zu den anderen gewichtet werden soll. Dies kann eine beliebige nicht negative Zahl sein. Die Summe der Gewichtungen muss nicht 1 ergeben. Die Standardgewichtung ist 1,0.

Typ

Der Zieltyp, 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 eigenständig verwendet werden, wird aber auch immer mit der Gewichtung 1,0 als Referenz zu den vom Nutzer angegebenen Zielen hinzugefügt, falls es noch nicht vorhanden ist.
MIN_DISTANCE	„MIN“-Ziele. Die insgesamt zurückgelegte Strecke minimieren.
MIN_WORKING_TIME	Minimieren Sie die Gesamtarbeitszeit, summiert über alle Fahrzeuge.
MIN_TRAVEL_TIME	Wie oben, aber nur auf die Reisedauer bezogen.
MIN_NUM_VEHICLES	Minimieren Sie die Anzahl der verwendeten Fahrzeuge.

PrecedenceRule

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

Mehrere Prioritäten können sich auf dieselben (oder verwandte) Ereignisse beziehen, z.B. „Abholung von B erfolgt nach Lieferung von A“ und „Abholung von C erfolgt nach Abholung von B“.

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

Felder
first_is_delivery	bool Gibt an, ob das „erste“ Ereignis eine Zustellung ist.
second_is_delivery	bool Gibt an, ob das „zweite“ Ereignis eine Zustellung ist.
offset_duration	Duration Der Versatz zwischen dem „ersten“ und dem „zweiten“ Ereignis. Der Wert kann negativ sein.
first_index	int32 Sendungsindex des „ersten“ Ereignisses. Dieses Feld muss angegeben werden.
second_index	int32 Sendungsindex des „zweiten“ Ereignisses. Dieses Feld muss angegeben werden.

ShipmentRoute

Die Route eines Fahrzeugs kann entlang der Zeitachse so aufgeteilt 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:

• „Punktuelle Ereignisse“ wie der Start und das Ende des Fahrzeugs sowie der Beginn und das Ende jedes Besuchs (Ankunft und Abfahrt). Sie finden zu einer bestimmten Sekunde statt.
• „Zeitintervalle“, z. B. die Besuche selbst und der Übergang zwischen den Besuchen. Zeitintervalle können manchmal eine Dauer von null haben, d. h. sie beginnen und enden in derselben Sekunde. Häufig haben sie jedoch eine positive Dauer.

Invarianten:

• Wenn es n Besuche gibt, gibt es n + 1 Übergänge.
• Ein Besuch wird immer von einem Übergang davor (gleicher Index) und einem Übergang danach (Index + 1) umgeben.
• Auf den Fahrzeugstart folgt immer der Übergang 0.
• Dem Fahrzeugende geht immer der Übergang #n voraus.

Hier 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

Hier sehen Sie, wie TRAVEL, BREAKS, DELAY und WAIT während eines Übergangs angeordnet werden können.

• 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 Fahrt) sein. Es reicht also, die Dauer der Verzögerung zu kennen, um die Start- und Endzeit zu kennen.
• Die BREAKS sind zusammenhängende, sich nicht überschneidende Zeiträume. In der Antwort werden der Beginn und die Dauer jeder Pause angegeben.
• TRAVEL und WAIT sind „vorzeitig beendbar“: Sie können während dieses Übergangs mehrmals unterbrochen werden. Clients können davon ausgehen, dass die Fahrt „so schnell wie möglich“ erfolgt und dass die verbleibende Zeit mit „Warten“ gefü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 Fahrzeug, das die Route ausführt, identifiziert durch seinen Index in der Quelle ShipmentModel.
vehicle_label	string Label des Fahrzeugs, das diese Route ausfü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 Zeitpunkt, zu dem das Fahrzeug seine Route beendet.
visits[]	Visit Geordnete Abfolge 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 Inkonsistenzen bei den Routenzeiten mithilfe von verkehrsbasierten Schätzungen der Reisedauer vorhergesagt werden. Möglicherweise reicht die Zeit nicht aus, um die verkehrsabhängigen Fahrten, Verzögerungen und Pausen zwischen den Besuchen, vor dem ersten Besuch oder nach dem letzten Besuch abzuschließen 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 Besuchsort erfolgt wahrscheinlich später als im aktuellen Zeitfenster, da die geschätzte Fahrtzeit travel_duration(previous_visit, next_visit) aufgrund des Verkehrs höher ist. Außerdem kann es aufgrund einer Erhöhung der geschätzten Fahrtzeit und Einschränkungen des Zeitfensters für Besuche oder Pausen zu einer Überschneidung von Pause und Besuch kommen.
route_polyline	EncodedPolyline Die codierte Polyliniendarstellung 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 Sequenz breaks stellt Zeitintervalle dar, die jeweils beim entsprechenden start_time beginnen und duration Sekunden dauern.
metrics	AggregatedMetrics Dauer, Entfernung und Auslastung 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, um zu berechnen, wie nah die begrenzten Messwerte an den jeweiligen Fahrzeuglimits liegen. Die Felder sind Verhältnisse zwischen einem begrenzten Messwertfeld (z.B. AggregatedMetrics.travel_distance_meters) und dem zugehörigen Fahrzeuglimit (z.B. Vehicle.route_distance_limit). Experimentell: 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 Proto-Pfade, relativ zur 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 auf der Route. Alle im Modell definierten Kosten werden hier detailliert aufgeführt, mit Ausnahme der Kosten im Zusammenhang mit TransitionAttributes, die ab Januar 2022 nur noch aggregiert aufgeführt 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 Beginn einer Pause.
duration	Duration Dauer einer Pause.

EncodedPolyline

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

Felder
points	string String, der codierte 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 dieses Übergangs.
travel_distance_meters	double Während des Übergangs zurückgelegte Strecke.
traffic_info_unavailable	bool Wenn Verkehrsinformationen über OptimizeToursRequest.consider_road_traffic angefordert werden und die Verkehrsinformationen für eine Transition nicht abgerufen werden konnten, wird dieser boolesche Wert auf „true“ gesetzt. Dies kann vorübergehend (seltener Fehler auf den Echtzeit-Verkehrsservern) oder dauerhaft (keine Daten für diesen Standort) 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 Fahrzeugende). TransitionAttributes.delay ansehen.
break_duration	Duration Summe der Dauer der Pausen, die während dieses Übergangs auftreten, falls vorhanden. Details zum Beginn und zur Dauer jeder Unterbrechung werden in ShipmentRoute.breaks gespeichert.
wait_duration	Duration Wartezeit während dieses Übergangs. Die Wartezeit entspricht der Leerlaufzeit und umfasst keine Pausen. Diese Wartezeit kann auch in mehrere nicht zusammenhängende Intervalle aufgeteilt sein.
total_duration	Duration Gesamtdauer des Übergangs, zur Vereinfachung angegeben. Sie entspricht: start_time des nächsten Besuchs (oder vehicle_end_time, wenn dies der letzte Übergang ist) – start_time dieses Übergangs; Wenn ShipmentRoute.has_traffic_infeasibilities „false“ ist, gilt außerdem Folgendes: `total_duration = travel_duration + delay_duration break_duration + wait_duration`.
start_time	Timestamp Startzeit dieses Übergangs.
route_polyline	EncodedPolyline Die codierte Polyliniendarstellung der Route, die während des Übergangs zurückgelegt wurde. Dieses Feld wird nur ausgefüllt, wenn populate_transition_polylines auf „true“ gesetzt ist.
route_token	string Nur Ausgabe. Ein opakes Token, das an das Navigation SDK übergeben werden kann, um die Route während der Navigation zu rekonstruieren und bei einer Routenneuberechnung die ursprüngliche Absicht bei der Erstellung der Route zu berücksichtigen. Behandeln Sie dieses Token als intransparentes 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> Fahrzeuglasten während dieses Übergangs für jeden Typ, der entweder in den Vehicle.load_limits dieses Fahrzeugs vorkommt oder für den bei einer Sendung auf dieser Route ein Shipment.load_demands ungleich null gilt. Die Lasten während des ersten Übergangs sind die Startlasten der Fahrzeugroute. Nach jedem Besuch werden die load_demands des Besuchs entweder addiert oder subtrahiert, um die Lasten des nächsten Übergangs zu erhalten, je nachdem, ob es sich um eine Abholung oder eine Lieferung handelte.

VehicleLoad

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

Felder
amount	int64 Die Last des Fahrzeugs für den angegebenen Typ. Die Einheit der Last wird normalerweise durch den Typ angegeben. Transition.vehicle_loads ansehen.

Aufrufen

Ein Besuch, der während einer Route durchgeführt wird. Dieser Besuch entspricht der 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 der Abholung eines Shipment. Andernfalls entspricht es einer Lieferung.
visit_request_index	int32 Index von VisitRequest im Feld „pickup“ oder „delivery“ von Shipment (siehe is_pickup).
start_time	Timestamp Uhrzeit, zu der der Besuch beginnt. Das Fahrzeug kann früher am Besuchsort eintreffen. Die Zeiten stimmen mit ShipmentModel überein.
load_demands	map<string, Load> Gesamtlastbedarf für den Besuch als Summe der Sendung und der Besuchsanfrage load_demands. Die Werte sind negativ, wenn der Besuch eine Lieferung ist. Die Nachfrage wird für dieselben Typen wie Transition.loads gemeldet (siehe dieses Feld).
detour	Duration Zusätzliche Umwegzeit aufgrund der Sendungen, die vor dem Besuch auf der Route besucht wurden, und der potenziellen Wartezeit, die durch Zeitfenster verursacht wird. Wenn es sich um eine Lieferung handelt, wird der Umweg anhand des entsprechenden Abholbesuchs 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 start_location des Fahrzeugs berechnet und entspricht: start_time - vehicle_start_time - travel duration from the vehicle's `start_location` to the visit.
shipment_label	string Kopie des entsprechenden Shipment.label, falls im Shipment angegeben.
visit_label	string Kopie des entsprechenden VisitRequest.label, falls im 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 darstellt. Dieses Feld kann in den 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 bei dem Besuch um eine Abholung, eine Lieferung oder einen Besuch bei einem Stop handelt. Besuche an einer Haltestelle werden nur verwendet, wenn die multimodale Optimierung aktiviert ist.

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

ShipmentTypeIncompatibility

Gibt Inkompatibilitäten zwischen Sendungen je nach „shipment_type“ an. Das Auftreten 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-Werten sind „inkompatibel“.
incompatibility_mode	IncompatibilityMode Modus, der auf die Inkompatibilität angewendet wird.

IncompatibilityMode

Modi, die festlegen, wie das Auftreten 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 nie dasselbe Fahrzeug nutzen.
NOT_IN_SAME_VEHICLE_SIMULTANEOUSLY	In diesem Modus können zwei Sendungen mit inkompatiblen Typen nie gleichzeitig im selben Fahrzeug sein: Sie können dasselbe Fahrzeug nur dann gemeinsam nutzen, wenn ein Fahrzeug geliefert wird, bevor das andere abgeholt wird. Wenn beide Sendungen nur Abholungen (keine Lieferungen) oder nur Lieferungen (keine Abholungen) sind, können sie überhaupt nicht dasselbe Fahrzeug nutzen.

ShipmentTypeRequirement

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

Felder
required_shipment_type_alternatives[]	string Liste der alternativen Versandarten, die für dependent_shipment_types erforderlich sind.
dependent_shipment_types[]	string Für alle Sendungen mit einem Typ im Feld dependent_shipment_types muss mindestens eine Sendung vom Typ required_shipment_type_alternatives auf derselben Route besucht werden. HINWEIS: Ketten von Anforderungen, bei denen ein shipment_type von sich selbst abhängt, sind nicht zulässig.
requirement_mode	RequirementMode Auf die Anforderung angewendeter Modus.

RequirementMode

Modi, die das Erscheinungsbild abhängiger 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 verwenden.
IN_SAME_VEHICLE_AT_PICKUP_TIME	Im Modus IN_SAME_VEHICLE_AT_PICKUP_TIME muss für alle „abhängigen“ Sendungen zum Zeitpunkt der Abholung mindestens eine „erforderliche“ Sendung im Fahrzeug vorhanden sein. Eine „abhängige“ Abholung muss daher entweder: Eine „erforderliche“ Sendung, die nur zugestellt werden kann, wird auf der Route danach zugestellt oder Eine „erforderliche“ Sendung, die auf der Route davor abgeholt wurde. Wenn die „erforderliche“ Sendung eine Lieferung hat, muss diese Lieferung nach der Abholung der „abhängigen“ Sendung erfolgen.
IN_SAME_VEHICLE_AT_DELIVERY_TIME	Wie zuvor, nur dass die „abhängigen“ Sendungen zum Zeitpunkt der Lieferung eine „erforderliche“ Sendung im Fahrzeug haben müssen.

SkippedShipment

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

Felder
index	int32 Der Index entspricht dem Index der Sendung in der Quelle ShipmentModel.
label	string Kopie des entsprechenden Shipment.label, falls im Shipment angegeben.
reasons[]	Reason Eine Liste von 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 der Shipment.penalty_cost, die hier aufgeführt ist, um die Schwere einer übersprungenen Lieferung zu verdeutlichen. Experimentell: Das Verhalten oder die Existenz dieses Felds kann sich in Zukunft ändern.
estimated_incompatible_vehicle_ratio	double Geschätzter Anteil der Fahrzeuge, die diese Sendung aus mindestens einem der folgenden Gründe nicht ausführen können. Hinweis: Dieses Feld wird nur ausgefüllt, wenn die Gründe ein Fahrzeug betreffen. Experimentell: 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. Eine übersprungene Sendung darf keine doppelten Gründe haben, d.h. alle Felder sind gleich, 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 für „Äpfel“ mindestens eines Fahrzeugs würde überschritten (einschließlich Fahrzeug 1), die Kapazität für „Birnen“ mindestens eines Fahrzeugs würde überschritten (einschließlich Fahrzeug 3) und das Distanzlimit mindestens eines Fahrzeugs würde überschritten (einschließlich Fahrzeug 1).

Felder
code	Code Sehen Sie sich die Kommentare im Code an.
example_vehicle_indices[]	int32 Entspricht example_vehicle_index, mit dem Unterschied, dass wir die Liste der mehreren identifizierten Fahrzeuge bereitstellen. Diese Liste ist nicht unbedingt vollständig. Dieses Feld wird nur ausgefüllt, wenn [fill_example_vehicle_indices_in_skipped_reasons][] „true“ ist. Experimentell: Das Verhalten oder die Existenz dieses Felds kann sich in Zukunft ändern.
example_exceeded_capacity_type	string Wenn der Ursachencode DEMAND_EXCEEDS_VEHICLE_CAPACITY lautet, wird ein Kapazitätstyp dokumentiert, der überschritten wurde.
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, der den Grundtyp angibt. Die Reihenfolge ist hier bedeutungslos. Insbesondere gibt es keinen Hinweis darauf, ob ein bestimmter Grund vor einem anderen in der Lösung erscheint, wenn beide zutreffen.

Enums
CODE_UNSPECIFIED	Sollte nicht verwendet werden.
NO_VEHICLE	Im Modell ist kein Fahrzeug vorhanden, sodass alle Lieferungen unmöglich sind.
DEMAND_EXCEEDS_VEHICLE_CAPACITY	Die Anforderungen der Sendung überschreiten die Kapazität eines Fahrzeugs für einige Kapazitätstypen, darunter example_exceeded_capacity_type.
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DISTANCE_LIMIT	Die Mindestentfernung, die für diese Sendung erforderlich ist, d.h. vom start_location des Fahrzeugs zu den Abhol- und/oder Lieferorten der Sendung und zum Zielort des Fahrzeugs, überschreitet die route_distance_limit des Fahrzeugs. Beachten Sie, dass wir für diese Berechnung die geodätischen Entfernungen verwenden.
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT	Die für diese Sendung erforderliche Mindestzeit, einschließlich Fahrtzeit, Wartezeit und Servicezeit, überschreitet die route_duration_limit des Fahrzeugs. Hinweis: Die Reisedauer wird im Best-Case-Szenario berechnet, d. h. als geodätische Entfernung × 36 m/s (ca. 130 km/h).
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TRAVEL_DURATION_LIMIT	Wie oben, aber wir vergleichen nur die minimale Reisedauer und die travel_duration_limit des Fahrzeugs.
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TIME_WINDOWS	Das Fahrzeug kann diese Sendung im besten Fall nicht ausführen (siehe CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT für die Zeitberechnung), wenn es zum frühestmöglichen Zeitpunkt startet: Die Gesamtzeit würde dazu führen, dass das Fahrzeug nach dem spätesten Endzeitpunkt ankommt.
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“. Experimentell: Das Verhalten oder die Existenz dieses Felds kann sich in Zukunft ändern.
SHIPMENT_IGNORED	Das Feld ignore der Sendung ist „true“. Experimentell: Das Verhalten oder die Existenz dieses Felds kann sich in Zukunft ändern.
SKIPPED_IN_INJECTED_SOLUTION_CONSTRAINT	Die Sendung wird im injected_solution_constraint übersprungen. Experimentell: Das Verhalten oder die Existenz dieses Felds kann sich in Zukunft ändern.
VEHICLE_ROUTE_IS_FULLY_SEQUENCE_CONSTRAINED	Die in der injected_solution_constraint angegebene Lockerung der Fahrzeugroute lässt das Einfügen von Besuchen nicht zu. Experimentell: Das Verhalten oder die Existenz dieses Felds kann sich in Zukunft ändern.
ZERO_PENALTY_COST	Für die Sendung fallen keine Strafkosten an. Dies kann als erweiterte Modellierungsoption nützlich sein, aber auch im Nachhinein erklären, warum eine Sendung übersprungen wurde. Experimentell: 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.

Die harten Zeitfenstergrenzen start_time und end_time erzwingen den frühesten und spätesten Zeitpunkt des Ereignisses, sodass start_time <= event_time <= end_time gilt. Die weiche Untergrenze des Zeitfensters, soft_start_time, drückt eine Präferenz dafür aus, dass das Ereignis am oder nach dem soft_start_time stattfindet. Dabei fallen Kosten an, die proportional dazu sind, wie lange vor soft_start_time das Ereignis eintritt. Die Obergrenze des weichen Zeitfensters, soft_end_time, drückt eine Präferenz dafür aus, dass das Ereignis am oder vor dem soft_end_time stattfindet. Dabei fallen Kosten an, die proportional dazu sind, wie lange nach dem soft_end_time das Ereignis eintritt. 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 Der Beginn des harten Zeitfensters. Wenn nicht angegeben, wird ShipmentModel.global_start_time festgelegt.
end_time	Timestamp Das Ende des harten Zeitfensters. Wenn nicht angegeben, wird ShipmentModel.global_end_time festgelegt.
soft_start_time	Timestamp Der weiche Beginn des Zeitfensters.
soft_end_time	Timestamp Das weiche Ende des Zeitfensters.
cost_per_hour_before_soft_start_time	double Kosten pro Stunde, die zu anderen Kosten im Modell hinzugefügt werden, wenn das Ereignis vor „soft_start_time“ auftritt. Berechnung: 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 zu anderen Kosten im Modell hinzugefügt werden, wenn das Ereignis nach soft_end_time eintritt. Berechnung: 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 für Übergänge 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 gilt (gemäß der natürlichen „UND“-Semantik).

Felder
src_tag	string Tags, die die Gruppe von (src->dst)-Übergängen definieren, für die diese Attribute gelten. Ein Quellbesuch oder Fahrzeugstart stimmt überein, wenn 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 der Felder src_tag und excluded_src_tag darf nicht leer sein.
dst_tag	string Ein Zielbesuch oder ein Fahrzeugende stimmt überein, wenn 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 der Felder dst_tag und excluded_dst_tag darf nicht leer sein.
cost	double Gibt die Kosten für die Durchführung dieser Umstellung an. Die Einheit ist dieselbe wie bei allen anderen Kosten im Modell und der Wert darf nicht negativ sein. Sie wird zusätzlich zu allen anderen bestehenden Kosten erhoben.
cost_per_kilometer	double Gibt die Kosten pro Kilometer an, die für die während dieses Übergangs zurückgelegte Strecke anfallen. Sie wird zu allen Vehicle.cost_per_kilometer-Werten 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 weiche Limits 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 Besuchs am Ausgangsort und vor dem Beginn des Besuchs am Zielort 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 das Suffix .json haben. Wenn die Ressource als textproto codiert ist, muss der Ressourcenname das Suffix .txtpb haben. Ein Google Cloud Storage-URI zu einer JSON-codierten Datei könnte beispielsweise so aussehen: gs://bucket/path/input/object.json.

Fahrzeug

Modelliert ein Fahrzeug in einem Lieferproblem. Wenn Sie ein Lieferproblem lösen, wird für dieses Fahrzeug eine Route erstellt, die bei start_location beginnt und bei end_location endet. Eine Route ist eine Abfolge 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 Der Reisemodus, der sich auf die vom Fahrzeug befahrbaren 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 der Routen für das jeweilige Fahrzeug auswirken.
start_location	LatLng Geografischer Standort, an dem das Fahrzeug startet, bevor es Sendungen abholt. Wenn nicht angegeben, startet das Fahrzeug bei der ersten Abholung. Wenn das Sendungsmodell Dauer- und Distanzmatrizen enthält, darf start_location nicht angegeben werden.
start_waypoint	Waypoint Wegpunkt, der einen geografischen Standort darstellt, an dem das Fahrzeug startet, bevor es Sendungen abholt. Wenn weder start_waypoint noch start_location angegeben ist, startet das Fahrzeug bei der ersten Abholung. Wenn das Sendungsmodell Dauer- und Distanzmatrizen enthält, darf start_waypoint nicht angegeben werden.
end_location	LatLng Geografischer Standort, an dem sich das Fahrzeug nach Abschluss der letzten VisitRequest befindet. Wenn nicht angegeben, endet die ShipmentRoute des Fahrzeugs sofort, wenn es die letzte VisitRequest abgeschlossen hat. Wenn das Sendungsmodell Dauer- und Distanzmatrizen enthält, darf end_location nicht angegeben werden.
end_waypoint	Waypoint Wegpunkt, der einen geografischen Standort darstellt, an dem sich das Fahrzeug nach Abschluss der letzten VisitRequest befindet. Wenn weder end_waypoint noch end_location angegeben ist, endet die ShipmentRoute des Fahrzeugs sofort, wenn es die letzte VisitRequest abgeschlossen hat. Wenn das Sendungsmodell Dauer- und Distanzmatrizen enthält, darf end_waypoint nicht angegeben werden.
start_tags[]	string Gibt Tags an, die am Anfang der Route des Fahrzeugs angehängt werden. 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 seinen Startort verlassen darf. Sie müssen innerhalb der globalen Zeitlimits liegen (siehe ShipmentModel.global_*-Felder). Wenn keine Angabe erfolgt, gibt es außer diesen globalen Zeitlimits keine Einschränkungen. Zeitfenster, die zum selben wiederkehrenden Feld gehören, dürfen sich nicht überschneiden, d.h. kein Zeitfenster darf sich mit einem anderen überschneiden oder an ein anderes angrenzen, und sie müssen in chronologischer Reihenfolge sein. 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 ankommen darf. Sie müssen innerhalb der globalen Zeitlimits liegen (siehe ShipmentModel.global_*-Felder). Wenn keine Angabe erfolgt, gibt es außer diesen globalen Zeitlimits keine Einschränkung. Zeitfenster, die zum selben wiederkehrenden Feld gehören, dürfen sich nicht überschneiden, d.h. kein Zeitfenster darf sich mit einem anderen überschneiden oder an ein anderes angrenzen, und sie müssen in chronologischer Reihenfolge sein. 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 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 Zuordnung sind die Kennungen des Lasttyps und entsprechen den Schlüsseln des Felds Shipment.load_demands. Wenn ein bestimmter Schlüssel in dieser Zuordnung nicht vorhanden ist, 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, einschließlich Fahrtzeit, 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 Reisedauer der Route angewendet (d.h. die in ShipmentRoute.transitions angegebene Zeit) und umfassen nicht die Wartezeiten und Besuchszeit.
cost_per_kilometer	double Kosten pro Kilometer der Fahrzeugroute. Diese Kosten werden auf die im ShipmentRoute.transitions angegebene Entfernung angewendet und nicht auf die implizit zurückgelegte Entfernung vom arrival_location zum departure_location einer einzelnen VisitRequest.
fixed_cost	double Feste Kosten, die anfallen, wenn dieses Fahrzeug für eine Sendung verwendet wird.
used_if_route_is_empty	bool Dieses Feld gilt nur für Fahrzeuge, deren Route keine Sendungen umfasst. Gibt an, ob das Fahrzeug in diesem Fall als gebraucht gilt. Wenn „true“, fährt das Fahrzeug von seinem Start- zu seinem Zielort, auch wenn es keine Sendungen ausliefert. Die Zeit- und Entfernungskosten, die sich aus der Fahrt vom Start- zum Zielort ergeben, werden berücksichtigt. Andernfalls fährt es nicht vom Start- zum Zielort und für dieses Fahrzeug sind keine break_rule oder Verspätungen (aus TransitionAttributes) geplant. In diesem Fall enthält das 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 Limit für die Fahrtdauer der Route des Fahrzeugs. In einer bestimmten OptimizeToursResponse ist die Reisedauer der Route die Summe aller transitions.travel_duration.
route_distance_limit	DistanceLimit Limit, das auf die Gesamtlänge der Route des Fahrzeugs angewendet wird. In einem bestimmten OptimizeToursResponse ist die Routenentfernung die Summe aller transitions.travel_distance_meters.
extra_visit_duration_for_visit_type	map<string, Duration> Gibt eine Zuordnung von visit_types-Strings zu Dauern an. Die Dauer ist die Zeit, die zusätzlich zu VisitRequest.duration für Besuche mit der angegebenen visit_types benötigt wird. Diese zusätzliche Besuchsdauer verursacht Kosten, wenn cost_per_hour angegeben ist. Schlüssel (z.B. visit_types) dürfen keine leeren Strings sein. Wenn eine Besuchsanfrage mehrere Typen hat, wird für jeden Typ in der Karte eine Dauer hinzugefügt.
break_rule	BreakRule Beschreibt den Pausenplan, der für dieses Fahrzeug erzwungen werden soll. Wenn das Feld leer ist, werden für dieses Fahrzeug keine Pausen geplant.
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“, muss used_if_route_is_empty „false“ sein und dieses Fahrzeug wird nicht verwendet. Wenn eine Sendung 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 ausgeführt wird und eine zugehörige Abholung/Lieferung auf dem Fahrzeug verbleiben muss (d.h. nicht auf Ebene RELAX_ALL_AFTER_THRESHOLD gelockert wird), wird sie in der Antwort übersprungen. Wenn eine Sendung ein nicht leeres allowed_vehicle_indices-Feld hat und alle zulässigen Fahrzeuge ignoriert werden, wird sie in der Antwort übersprungen.
travel_duration_multiple	double Gibt einen Multiplikationsfaktor an, mit dem die Fahrzeiten dieses Fahrzeugs erhöht oder verringert werden können. Wenn Sie diesen Wert beispielsweise auf 2,0 festlegen, bedeutet das, dass dieses Fahrzeug langsamer ist und die Fahrtzeiten doppelt so lang sind wie bei Standardfahrzeugen. Dieses Vielfache hat keine Auswirkungen auf die Besuchsdauer. Es wirkt sich auf die Kosten aus, wenn cost_per_hour oder cost_per_traveled_hour angegeben ist. Der Wert muss im Bereich [0,001, 1.000,0] liegen. Wenn nicht festgelegt, ist das Fahrzeug ein Standardfahrzeug und dieser Multiplikator wird als 1, 0 betrachtet. WARNUNG: Die Reisedauer wird auf die nächste Sekunde gerundet, nachdem dieses Vielfache angewendet wurde, aber bevor numerische Vorgänge ausgeführt werden. Ein kleines Vielfaches kann daher zu einem Verlust an Genauigkeit führen. Siehe auch extra_visit_duration_for_visit_type unten.

DurationLimit

Ein Limit, das 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 Schwellenwert für das weiche Limit als auch die zugehörigen Kosten definiert werden.

Felder
max_duration	Duration Ein festes Limit, das die Dauer auf maximal „max_duration“ beschränkt.
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. Falls definiert, darf soft_max_duration nicht negativ sein. Wenn „max_duration“ ebenfalls definiert ist, muss soft_max_duration kleiner als „max_duration“ sein.
quadratic_soft_max_duration	Duration Ein weiches Limit, das keine maximale Dauer erzwingt, aber bei Überschreitung zu Kosten führt, die quadratisch zur Dauer sind. 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: Der Wert darf nicht negativ sein. max_duration muss definiert werden. quadratic_soft_max_duration muss kleiner als max_duration sein. Der Unterschied darf nicht mehr als 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 Grenzwert für soft_max_duration ü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_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 Schwellenwert quadratic_soft_max_duration ü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 eine Lastgrenze 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 der 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, gilt die folgende Kostenstrafe (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 Lastintervall des Fahrzeugs zu Beginn der Route.
end_load_interval	Interval Das zulässige Lastintervall des Fahrzeugs am Ende der Route.
max_load	int64 Die maximal zulässige Last.
cost_per_kilometer	LoadCost Kosten für den Transport einer Ladeeinheit über einen Kilometer für dieses 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 Beförderung einer Ladeeinheit mit diesem Fahrzeug während einer Stunde. Experimentell: Weitere Informationen finden Sie unter https://developers.google.com/maps/tt/route-optimization/experimental/load-cost/make-request.

Intervall

Intervall akzeptabler Lastmengen.

Felder
min	int64 Eine akzeptable Mindestlast. Muss ≥ 0 sein. Wenn beide angegeben sind, muss min ≤ max sein.
max	int64 Eine maximal akzeptable Last. Muss ≥ 0 sein. Wenn keine Angabe gemacht wird, ist die maximale Last durch diese Nachricht nicht eingeschränkt. Wenn beide angegeben sind, muss min ≤ max sein.

LoadCost

Kosten für das Verschieben einer Lasteinheit während eines Transition. Für eine bestimmte Last setzen sich die Kosten 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, bei denen hohe Anforderungen zuerst erfüllt oder hohe Anforderungen zuletzt abgeholt werden. 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
    }
  }
}

und 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 betragen die durch diese LoadCost verursachten Kosten (cost_below * load_below * Kilometer + cost_above * load_above * Kilometer).

• Ü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 über die Route beträgt also 120,0.

Wenn die Route jedoch „Start, Abholung, Lieferung, Abholung, Lieferung, Ende“ mit Übergängen ist:

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 }

dann betragen die durch diese LoadCost verursachten Kosten

• Ü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 die LoadCost über 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 Lastmenge, ab der sich die Kosten für das Verschieben 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 das Verschieben 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 das Verschieben einer Lasteinheit für jede Einheit über dem Schwellenwert. Im Sonderfall „Grenzwert = 0“ sind dies feste Kosten pro Einheit. Muss ein endlicher Wert und >= 0 sein.

TravelMode

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

Diese sollten eine Teilmenge der Mobilitätsformen der Routes API der Google Maps Platform 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. Es kann vorkommen, dass Gehwege oder Fußgängerwege fehlen. Sie müssen diese Warnung für alle Fußgängerrouten anzeigen, die Sie in Ihrer App einblenden.

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

UnloadingPolicy

Richtlinie zum Entladen eines Fahrzeugs. Gilt nur für Sendungen, die sowohl eine Abholung als auch eine Lieferung umfassen.

Andere Sendungen können unabhängig von unloading_policy an einer beliebigen Stelle auf der Route erfolgen.

Enums
UNLOADING_POLICY_UNSPECIFIED	Nicht angegebene Entladerichtlinie; Lieferungen müssen nur nach den entsprechenden Abholungen erfolgen.
LAST_IN_FIRST_OUT	Die Lieferungen müssen in umgekehrter Reihenfolge der Abholungen erfolgen.
FIRST_IN_FIRST_OUT	Lieferungen müssen in derselben Reihenfolge wie die 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 begrenzten Messwertfeld (z.B. AggregatedMetrics.travel_distance_meters) und dem zugehörigen Fahrzeuglimit (z.B. Vehicle.route_distance_limit) berechnet, falls vorhanden. Andernfalls bleibt das Füllverhältnis unbestimmt. Wenn das Limit 0 ist, wird das Feld auf 1 gesetzt. Hinweis: Wenn eine Route aufgrund von Verkehrsproblemen nicht möglich ist, können einige Rohwerte für die Auslastung 1,0 überschreiten, z. B. wenn das Fahrzeug sein Distanzlimit überschreitet. In diesen Fällen begrenzen wir die Werte für die Auslastung 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, wird 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, wird 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, wird dieses Feld nicht festgelegt.
max_load	double Das maximale Verhältnis aller Typen von [AggregatedMetrics.max_load][] und der jeweiligen Vehicle.load_limits. Wenn alle Vehicle.load_limits-Felder nicht festgelegt sind, wird 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 die Ankunfts- und Abfahrtsorte von VisitRequests sowie die Start- und Zielorte von Fahrzeugen.

Felder
side_of_road	bool Optional. Gibt an, dass der Standort dieses Wegpunkts eine Präferenz für das Fahrzeug darstellt, auf einer bestimmten Straßenseite anzuhalten. Wenn Sie diesen Wert festlegen, führt die Route durch den Ort, sodass das Fahrzeug auf der Straßenseite anhalten kann, die vom Mittelpunkt der Straße aus gesehen 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 gedacht ist, die dort anhalten, um jemanden abzuholen oder abzusetzen. Diese Option funktioniert nur für den Reisemodus „DRIVING“ und wenn „location_type“ auf „location“ gesetzt ist. Experimentell: 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 durch geografische Koordinaten angegeben wird, einschließlich eines optionalen Kurses.
place_id	string Die Orts-ID des POI, der mit dem Wegpunkt verknüpft ist. Wenn Sie eine Orts-ID verwenden, um den Ankunfts- oder Abfahrtsort einer VisitRequest anzugeben, muss die Orts-ID spezifisch genug sein, um einen LatLng-Standort für die Navigation zum Ort zu bestimmen. Eine Orts-ID, die ein Gebäude darstellt, ist beispielsweise geeignet, eine Orts-ID, die eine Straße darstellt, jedoch nicht.