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)OptimizeToursRequest
(Meldung)OptimizeToursRequest.SearchMode
(Option)OptimizeToursRequest.SolvingMode
(Option)OptimizeToursResponse
(Meldung)OptimizeToursResponse.Metrics
(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.PrecedenceRule
(Meldung)ShipmentRoute
(Meldung)ShipmentRoute.Break
(Meldung)ShipmentRoute.EncodedPolyline
(Meldung)ShipmentRoute.Transition
(Meldung)ShipmentRoute.VehicleLoad
(Meldung)ShipmentRoute.Visit
(Meldung)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)Vehicle
(Meldung)Vehicle.DurationLimit
(Meldung)Vehicle.LoadLimit
(Meldung)Vehicle.LoadLimit.Interval
(Meldung)Vehicle.TravelMode
(Option)Vehicle.UnloadingPolicy
(Option)Waypoint
(Meldung)
RouteOptimization
Ein Dienst zur Optimierung von Fahrzeugtouren.
Gültigkeit bestimmter Feldtypen:
google.protobuf.Timestamp
- Zeitangaben sind in Unix-Zeit: Sekunden seit 1970-01-01T00:00:00+00:00.
- Sekunden müssen in [0, 253402300799] angegeben werden, d.h. in [1970-01-01T00:00:00+00:00, 9999-12-31T23:59:59+00:00].
- Nanos müssen nicht festgelegt oder auf 0 gesetzt sein.
google.protobuf.Duration
- Sekunden müssen in [0, 253402300799] angegeben werden, d.h. in [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
- latitude muss im Bereich [-90.0, 90.0] liegen.
- longitude muss im Bereich [-180.0, 180.0] liegen.
- Mindestens einer von „latitude“ und „longitude“ muss einen Wert ungleich Null haben.
BatchOptimizeTours |
---|
Optimiert Fahrzeugrundfahrten für eine oder mehrere Diese Methode ist ein Vorgang mit langer Ausführungszeit. Die Eingaben für die Optimierung ( Der Nutzer kann Wenn das Feld Wenn das Feld
|
OptimizeTours |
---|
Sendet eine Ein Das Ziel besteht darin, eine Zuweisung von
|
AggregatedMetrics
Zusammengefasste Messwerte für ShipmentRoute
(bzw. OptimizeToursResponse
für alle Transition
- und/oder Visit
-Elemente (bzw. für alle ShipmentRoute
)
Felder | |
---|---|
performed_shipment_count |
Anzahl der ausgeführten Sendungen. Beachten Sie, dass ein Abhol- und Lieferpaar nur einmal gezählt wird. |
travel_duration |
Die Gesamtfahrzeit für eine Route oder eine Lösung. |
wait_duration |
Gesamtwartezeit für eine Route oder Lösung. |
delay_duration |
Gesamtverzögerungsdauer für eine Route oder eine Lösung. |
break_duration |
Gesamtunterbrechungsdauer für eine Route oder eine Lösung. |
visit_duration |
Gesamtbesuchsdauer für eine Route oder Lösung. |
total_duration |
Die Gesamtdauer sollte der Summe aller oben genannten Dauern entsprechen. Für Routen entspricht er außerdem:
|
travel_distance_meters |
Gesamte Entfernung für eine Route oder eine Lösung. |
max_loads |
Maximale Belastung auf der gesamten Route (bzw. Lösung) für jede Menge auf dieser Route (bzw. Lösung), berechnet als Maximum über alle |
BatchOptimizeToursMetadata
Dieser Typ hat keine Felder.
Metadaten für Vorgänge bei BatchOptimizeToursRequest
-Aufrufen.
BatchOptimizeToursRequest
Batch-Optimierung von Touren als asynchronen Vorgang anfordern Jede Eingabedatei sollte eine OptimizeToursRequest
und jede Ausgabedatei eine OptimizeToursResponse
enthalten. Die Anfrage enthält Informationen zum Lesen/Schreiben und Parsen der Dateien. Alle Eingabe- und Ausgabedateien sollten sich im selben Projekt befinden.
Felder | |
---|---|
parent |
Erforderlich. Zielprojekt und Standort zum Anrufen festlegen. Format: * Wenn kein Standort angegeben ist, wird automatisch eine Region ausgewählt. |
model_configs[] |
Erforderlich. Eingabe-/Ausgabeinformationen für jedes Kaufmodell, z. B. Dateipfade und Datenformate. |
AsyncModelConfig
Informationen zum asynchronen Lösen eines Optimierungsmodells.
Felder | |
---|---|
display_name |
Optional. Benutzerdefinierter Modellname. Kann von Nutzern als Alias verwendet werden, um Modelle nachzuverfolgen. |
input_config |
Erforderlich. Informationen zum Eingabemodell. |
output_config |
Erforderlich. Die gewünschten Informationen zum Ausgabeort. |
BatchOptimizeToursResponse
Dieser Typ hat keine Felder.
Antwort auf BatchOptimizeToursRequest
. Sie wird im lang andauernden Vorgang zurückgegeben, nachdem der Vorgang abgeschlossen ist.
BreakRule
Regeln zum Generieren von Zeitpausen für ein Fahrzeug (z.B. Mittagspausen). Eine Pause ist ein zusammenhängender Zeitraum, in dem das Fahrzeug an seiner aktuellen Position inaktiv bleibt und keinen Besuch durchführen kann. Es kann zu einer Unterbrechung kommen:
- während der Reise zwischen zwei Besuchen (einschließlich der Zeit unmittelbar vor oder unmittelbar nach einem Besuch, aber nicht während eines Besuchs). In diesem Fall wird die entsprechende Laufzeit zwischen den Besuchen verlängert.
- oder vor dem Start (das Fahrzeug startet möglicherweise nicht mitten in der Pause). In diesem Fall wirkt sich dies nicht auf die Fahrzeugstartzeit aus.
- oder nach dem Fahrzeugende (ditto mit der Endzeit des Fahrzeugs).
Felder | |
---|---|
break_requests[] |
Reihenfolge der Unterbrechungen Siehe die Meldung |
frequency_constraints[] |
Es können mehrere |
BreakRequest
Die Reihenfolge der Pausen (Anzahl und Reihenfolge), die für jedes Fahrzeug gelten, muss im Voraus bekannt sein. Die wiederholten BreakRequest
s definieren diese Sequenz in der Reihenfolge, in der sie auftreten müssen. Die Zeitfenster (earliest_start_time
/ latest_start_time
) dürfen sich überschneiden, müssen aber mit der Bestellung kompatibel sein (dies wird geprüft).
Felder | |
---|---|
earliest_start_time |
Erforderlich. Untergrenze (einschließlich) zu Beginn der Unterbrechung. |
latest_start_time |
Erforderlich. Obergrenze (einschließlich) zu Beginn der Unterbrechung. |
min_duration |
Erforderlich. Minimale Dauer der Pause Muss positiv sein. |
FrequencyConstraint
Die Häufigkeit und Dauer der oben genannten Pausen kann weiter eingeschränkt werden, indem eine Mindestpausenfrequenz erzwungen wird, z. B. „Alle 12 Stunden muss eine Pause von mindestens einer Stunde eingelegt werden“. Unter der Annahme, dass dies als „In einem fließenden Zeitfenster von 12 Stunden muss mindestens eine Pause von mindestens einer Stunde vorhanden sein“ interpretiert werden kann, würde sich dieses Beispiel so ergeben: FrequencyConstraint
:
{
min_break_duration { seconds: 3600 } # 1 hour.
max_inter_break_duration { seconds: 39600 } # 11 hours (12 - 1 = 11).
}
Beim Timing und bei der Dauer der Pausen in der Lösung werden alle diese Einschränkungen berücksichtigt, zusätzlich zu den bereits in BreakRequest
angegebenen Zeitfenstern und Mindestdauern.
Ein FrequencyConstraint
kann in der Praxis auch für nicht aufeinanderfolgende Unterbrechungen gelten. Im folgenden Zeitplan wird beispielsweise die „1h alle 12h“ berücksichtigt. Beispiel:
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 |
Erforderlich. Minimale Unterbrechungsdauer für diese Einschränkung. Nicht negativ. Siehe Beschreibung von |
max_inter_break_duration |
Erforderlich. Maximale zulässige Spanne eines Zeitintervalls auf der Route, das nicht mindestens teilweise eine Pause von |
DataFormat
Datenformate für Ein- und Ausgabedateien.
Enums | |
---|---|
DATA_FORMAT_UNSPECIFIED |
Ungültiger Wert, das Format darf nicht UNSPECIFIED sein. |
JSON |
JavaScript Object Notation. |
PROTO_TEXT |
Protokollzwischenspeicher-Textformat. Weitere Informationen finden Sie unter https://protobuf.dev/reference/protobuf/textformat-spec/. |
DistanceLimit
Ein Limit, das eine maximale Strecke definiert, die zurückgelegt werden kann. Er 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 werden und nicht negativ sein.
Felder | |
---|---|
max_meters |
Ein fester Grenzwert, der den Abstand auf maximal „max_meters“ beschränkt. Der Grenzwert darf nicht negativ sein. |
soft_max_meters |
Ein weicher Grenzwert, bei dem kein maximales Entfernungslimit durchgesetzt wird, aber ein Verstoß führt zu Kosten, die zu anderen im Modell definierten Kosten mit derselben Einheit addiert werden. Falls definiert, muss „soft_max_meters“ kleiner als „max_meters“ sein und darf nicht negativ sein. |
cost_per_kilometer_below_soft_max |
Die Kosten pro angefallenem Kilometer werden mit folgender Formel um bis zu
Diese Kosten werden in |
cost_per_kilometer_above_soft_max |
Kosten pro Kilometer, wenn die Strecke über dem Limit von
Die Kosten dürfen nicht negativ sein. |
GcsDestination
Der Google Cloud Storage-Speicherort, in den die Ausgabedateien geschrieben werden.
Felder | |
---|---|
uri |
Erforderlich. Google Cloud Storage-URI. |
GcsSource
Der Google Cloud Storage-Speicherort, aus dem die Eingabedatei gelesen wird.
Felder | |
---|---|
uri |
Erforderlich. URI eines Google Cloud Storage-Objekts im Format |
InjectedSolutionConstraint
In die Anfrage eingefügte Lösung mit Informationen dazu, welche Besuche eingeschränkt werden müssen und wie sie eingeschränkt werden müssen
Felder | |
---|---|
routes[] |
Routen der einzuschleusenden Lösung. Einige Routen können in der ursprünglichen Lösung weggelassen werden. Die Routen und übersprungenen Sendungen müssen die grundlegenden Gültigkeitsannahmen erfüllen, die für |
skipped_shipments[] |
Übersprungene Lieferungen der einzuschleusenden Lösung. Einige können in der ursprünglichen Lösung weggelassen werden. Weitere Informationen finden Sie im Feld |
constraint_relaxations[] |
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, an welchen Schwellenwerten die Beschränkungen für Besuche gelockert werden und bis zu welcher Ebene. Lieferungen, die im Feld skipped_shipment
aufgeführt sind, können nur übersprungen werden. d.h. sie können nicht ausgeführt werden.
Felder | |
---|---|
relaxations[] |
Alle Lockerungen der Besuchsbeschränkung, die auf Besuche auf Routen mit Fahrzeugen in |
vehicle_indices[] |
Gibt die Fahrzeugindizes an, für die die Besuchsbeschränkung Ein Fahrzeugindex wird genauso kartiert wie |
Entspannung
Wenn relaxations
leer ist, sind der Beginn und die Reihenfolge aller Besuche auf routes
vollständig eingeschränkt und es können keine neuen Besuche eingefügt oder diesen Routen hinzugefügt werden. Außerdem sind die Start- und Endzeit eines Fahrzeugs in routes
vollständig begrenzt, es sei denn, das Fahrzeug ist leer, d.h. es hat keine Besuche und used_if_route_is_empty
ist im Modell auf „false“ gesetzt.
relaxations(i).level
gibt das Grad der Einschränkung der Einschränkung an, das auf einen Besuch #j angewendet wird, auf den Folgendes zutrifft:
route.visits(j).start_time >= relaxations(i).threshold_time
UNDj + 1 >= relaxations(i).threshold_visit_count
Ebenso wird der Fahrzeugstart auf relaxations(i).level
gelockert, wenn folgende Bedingungen erfüllt sind:
vehicle_start_time >= relaxations(i).threshold_time
UNDrelaxations(i).threshold_visit_count == 0
und das Fahrzeugende wird aufrelaxations(i).level
entspannt, wenn Folgendes erfüllt ist:vehicle_end_time >= relaxations(i).threshold_time
UNDroute.visits_size() + 1 >= relaxations(i).threshold_visit_count
Wenn ein Besuch die threshold_visit_count
ODER die threshold_time
erfüllt, fügen Sie zwei relaxations
mit derselben level
hinzu: eine mit nur threshold_visit_count
und eine mit nur threshold_time
. Wenn ein Besuch die Bedingungen mehrerer relaxations
erfüllt, wird die ruhigere Stufe angewendet. Dadurch wird das Entspannungsniveau vom Start des Fahrzeugs über die Besuche der Route bis zum Ende entspannter: Das heißt, das Entspannungsniveau nimmt im Verlauf der Route nicht ab.
Das Timing und die Abfolge von Routenbesuchen, die die Schwellenwertbedingungen von relaxations
nicht erfüllen, sind vollständig eingeschränkt. In diese Sequenzen können keine Besuche eingefügt werden. Wenn ein Fahrzeugstart oder -ende nicht die Bedingungen für eine Lockerung erfüllt, ist die Zeit festgelegt, es sei denn, das Fahrzeug ist leer.
Felder | |
---|---|
level |
Der Grad der Lockerung der Einschränkung, der gilt, wenn die Bedingungen ab |
threshold_time |
Der Zeitpunkt, zu oder nach dem die Lockerung |
threshold_visit_count |
Die Anzahl der Besuche, ab der die Lockerung Wenn |
Level
Gibt die verschiedenen Ebenen der Lockerung von Einschränkungen an, die für einen Besuch angewendet werden und die folgen, wenn die Grenzbedingungen erfüllt sind.
Die folgende Aufzählung erfolgt in der Reihenfolge, in der die Lockerung zunimmt.
Enums | |
---|---|
LEVEL_UNSPECIFIED |
Implizierte Standardlockerung: Es gibt keine Beschränkungen, die gelockert werden, d.h. alle Besuche sind vollständig eingeschränkt. Dieser Wert darf nicht explizit in |
RELAX_VISIT_TIMES_AFTER_THRESHOLD |
Besuchsbeginn und Start-/Endzeiten des Fahrzeugs werden gelockert, aber jeder Besuch bleibt an dasselbe Fahrzeug gebunden und die Besuchssequenz muss eingehalten werden: Es können keine Besuche zwischen ihnen oder davor eingefügt werden. |
RELAX_VISIT_TIMES_AND_SEQUENCE_AFTER_THRESHOLD |
Wie bei „RELAX_VISIT_TIMES_AFTER_THRESHOLD “, aber die Besuchssequenz ist ebenfalls entspannt: Besuche können nur von diesem Fahrzeug durchgeführt werden, können aber möglicherweise unterbrochen werden. |
RELAX_ALL_AFTER_THRESHOLD |
Wie bei RELAX_VISIT_TIMES_AND_SEQUENCE_AFTER_THRESHOLD , aber das Fahrzeug ist auch entspannt: Besuche sind zum Zeitpunkt des Grenzwerts oder danach völlig kostenlos und können möglicherweise keine Leistung erzielen. |
InputConfig
Geben Sie eine Eingabe für [BatchOptimizeTours][google.maps.routeOptimization.v1.RouteOptimizationService.BatchOptimizeTours] an.
Felder | |
---|---|
data_format |
Erforderlich. Das Format der Eingabedaten. |
Union-Feld source . Erforderlich. Für source ist nur einer der folgenden Werte zulässig: |
|
gcs_source |
Ein Google Cloud Storage-Speicherort. Dabei muss es sich um ein einzelnes Objekt (Datei) handeln. |
Standort
Kapselt einen Standort ein (einen geografischen Punkt und eine optionale Überschrift).
Felder | |
---|---|
lat_lng |
Die geografischen Koordinaten des Wegpunkts. |
heading |
Die Kompassrichtung, die der Verkehrsflussrichtung entspricht. Mit diesem Wert wird die Straßenseite angegeben, die als Start- und Zielpunkt verwendet werden soll. Ausrichtungswerte können zwischen 0 und 360 liegen, wobei 0 eine Richtung nach Norden, 90 eine Richtung nach Osten usw. angibt. |
OptimizeToursRequest
Die Anfrage wird an einen Lösungsmanager für die Touroptimierung gesendet, der das zu lösende Versandmodell sowie die Optimierungsparameter definiert.
Felder | |
---|---|
parent |
Erforderlich. Zielprojekt oder -ort für den Aufruf. Format: * Wenn kein Standort angegeben ist, wird automatisch eine Region ausgewählt. |
timeout |
Wenn dieses Zeitlimit festgelegt ist, gibt der Server eine Antwort zurück, bevor das Zeitlimit überschritten oder die Serverfrist für synchrone Anfragen erreicht ist, je nachdem, was früher eintritt. Bei asynchronen Anfragen generiert der Server (wenn möglich) vor Ablauf des Zeitlimits eine Lösung. |
model |
Zu lösendes Versandmodell. |
solving_mode |
Standardmäßig ist der Lösungsmodus |
search_mode |
Suchmodus, der zum Lösen der Anfrage verwendet wird. |
injected_first_solution_routes[] |
Leiten Sie den Optimierungsalgorithmus an, um eine erste Lösung zu finden, die einer vorherigen Lösung ähnelt. Das Modell wird beim Erstellen der ersten Lösung eingeschränkt. 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:
Wenn die injizierte Lösung nicht durchführbar ist, wird nicht unbedingt ein Validierungsfehler zurückgegeben. Stattdessen wird möglicherweise ein Fehler zurückgegeben, der die Nichtdurchführbarkeit anzeigt. |
injected_solution_constraint |
Schränken Sie den Optimierungsalgorithmus ein, um eine endgültige Lösung zu finden, die einer vorherigen Lösung ähnelt. Dies kann beispielsweise verwendet werden, um Teile von Routen zu fixieren, die bereits abgeschlossen sind oder noch abgeschlossen werden müssen, aber nicht geändert werden dürfen. Wenn die eingebrachte Lösung nicht realisierbar ist, wird nicht unbedingt ein Validierungsfehler zurückgegeben. Stattdessen kann ein Fehler zurückgegeben werden, der auf die Unmöglichkeit hinweist. |
refresh_details_routes[] |
Wenn das Feld nicht leer ist, werden die angegebenen Routen aktualisiert, ohne dass die zugrunde liegende Abfolge von Besuchen oder Fahrtzeiten geändert wird. Es werden nur andere Details aktualisiert. Das Modell wird dadurch nicht gelöst. Seit dem 11. Dezember 2020 werden damit nur Polylinien nicht leerer Routen gefüllt und Die Dieses Feld darf nicht zusammen mit
|
interpret_injected_solutions_using_labels |
Falls wahr:
Diese Interpretation gilt für die Felder Wenn diese Option aktiviert ist, dürfen Labels in den folgenden Kategorien höchstens einmal in ihrer Kategorie vorkommen:
Wenn eine Das Entfernen von Routenbesuchen oder ganzer Routen aus einer eingefügten Lösung kann sich auf die implizierten Einschränkungen auswirken, was zu einer Änderung der Lösung, Validierungsfehlern oder Undurchführbarkeit führen kann. HINWEIS: Der Aufrufer muss sicherstellen, dass jedes |
consider_road_traffic |
Berücksichtigen Sie bei der Berechnung der |
populate_polylines |
Bei Einstellung auf „true“ werden Polylinien in Antwort- |
populate_transition_polylines |
Falls wahr, werden Polylinien in der Antwort |
allow_large_deadline_despite_interruption_risk |
Wenn dieser festgelegt ist, kann die Anfrage ein Zeitlimit (siehe https://grpc.io/blog/deadlines) von bis zu 60 Minuten haben. Andernfalls beträgt die maximale Frist nur 30 Minuten. Beachten Sie, dass bei langlebigen Anfragen ein erheblich größeres, aber dennoch geringes Unterbrechungsrisiko besteht. |
use_geodesic_distances |
Wenn „wahr“ festgelegt ist, werden Reisedistanzen anhand von geodätischen Entfernungen anstelle von Google Maps-Entfernungen berechnet. Reisezeiten werden anhand von geodätischen Entfernungen mit einer Geschwindigkeit berechnet, die durch |
label |
Label, das verwendet werden kann, um diese Anfrage zu identifizieren, die in der |
geodesic_meters_per_second |
Wenn |
max_validation_errors |
Kürzt die Anzahl der zurückgegebenen Validierungsfehler. Diese Fehler werden in der Regel als BadRequest-Fehlerdetail an die Fehlernutzlast INVALID_ARGUMENT angehängt (https://cloud.google.com/apis/design/errors#error_details). Es sei denn, solutions_mode=VALIDATE_ONLY: Siehe Feld |
SearchMode
Modus, der das Verhalten der Suche definiert und dabei Latenz im Vergleich zur Lösungsqualität abwägt. In allen Modi wird das globale Zeitlimit für Anfragen 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 |
Nehmen Sie sich die Zeit, um nach besseren Lösungen zu suchen. |
SolvingMode
Definiert, wie der Matherechner 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
erfahren Sie, wie Sie die Anzahl der zurückgegebenen Fehler begrenzen.
Enums | |
---|---|
DEFAULT_SOLVE |
Löse 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: Es werden so viele OptimizeToursResponse.validation_errors wie möglich ausgefüllt. |
DETECT_SOME_INFEASIBLE_SHIPMENTS |
Wertet nur WICHTIG: Nicht alle nicht durchführbaren Sendungen werden an diese Stelle zurückgesendet, sondern nur solche, die bei der Vorverarbeitung als nicht durchführbar erkannt werden. |
OptimizeToursResponse
Antwort nach der Lösung eines Problems zur Optimierung der Tour mit den Routen, denen jedes Fahrzeug folgt, den übersprungenen Sendungen und den Gesamtkosten der Lösung.
Felder | |
---|---|
routes[] |
Routen, die für jedes Fahrzeug berechnet werden die i-te Route dem i-ten Fahrzeug im Modell entspricht. |
request_label |
Kopie von |
skipped_shipments[] |
Die Liste aller übersprungenen Sendungen. |
validation_errors[] |
Liste aller Validierungsfehler, die unabhängig erkannt wurden. Siehe "MEHRERE FEHLER" Erklärung für die |
metrics |
Messwerte für Dauer, Entfernung und Nutzung für diese Lösung. |
Messwerte
Gesamtmesswerte, zusammengefasst für alle Routen.
Felder | |
---|---|
aggregated_route_metrics |
Aggregiert über die Routen. Jeder Messwert ist die Summe (oder bei Ladevorgängen der maximale Wert) aller |
skipped_mandatory_shipment_count |
Anzahl der obligatorischen Sendungen übersprungen. |
used_vehicle_count |
Anzahl der genutzten Fahrzeuge. Hinweis: Wenn eine Fahrzeugroute leer ist und |
earliest_vehicle_start_time |
Die früheste Startzeit für ein gebrauchtes Fahrzeug, berechnet als Minimum aller gebrauchten Fahrzeuge in der Kategorie „ |
latest_vehicle_end_time |
Die späteste Endzeit für ein Gebrauchtfahrzeug, berechnet als Maximum aller Gebrauchtfahrzeuge von |
costs |
Kosten der Lösung, aufgeschlüsselt nach kostenbezogenen Anfragefeldern. Die Schlüssel sind Proto-Pfade, relativ zur Eingabe von OptimizeToursRequest. Beispiel: „model.shipments.pickups.cost“. Die Werte sind die Gesamtkosten, die vom entsprechenden Kostenfeld generiert und über die gesamte Lösung aggregiert wurden. Mit anderen Worten: „cost“["model.shipments.pickups.cost"] ist die Summe aller Abholkosten der Lösung. Alle im Modell definierten Kosten werden hier detailliert aufgeführt, mit Ausnahme von Kosten im Zusammenhang mit Übergangsattributen, die seit dem 01.01.2022 nur in aggregierter Form gemeldet werden. |
total_cost |
Gesamtkosten der Lösung. Die Summe aller Werte in der Kostenzuordnung. |
OptimizeToursValidationError
Beschreibt einen Fehler oder eine Warnung, die beim Validieren eines OptimizeToursRequest
aufgetreten ist.
Felder | |
---|---|
code |
Ein Validierungsfehler wird durch das Paar ( Die anderen Felder (unten) liefern weitere Informationen zum Fehler. MEHRERE FEHLER: Bei mehreren Fehlern wird bei der Validierung versucht, mehrere davon auszugeben. Ähnlich wie ein Compiler ist dies ein nicht perfekter Prozess. Einige Validierungsfehler sind „schwerwiegend“, das heißt, sie stoppen den gesamten Validierungsprozess. Dies gilt unter anderem für Stabilität: REFERENZ: Eine Liste aller (Code, Name)-Paare:
|
display_name |
Der Anzeigename des Fehlers. |
fields[] |
Ein Fehlerkontext kann in den meisten Fällen 0, 1 oder mehr Felder enthalten. Wenn Sie sich zum Beispiel auf Fahrzeug 4 und Lieferung 2 beziehen, können Sie dies wie folgt tun:
Beachten Sie jedoch, dass sich die Kardinalität von |
error_message |
Für Menschen lesbarer String, der den Fehler beschreibt. Es gibt eine 1:1-Zuordnung zwischen Stabilität: Nicht stabil: Die Fehlermeldung für eine bestimmte |
offending_values |
Kann die Werte der Felder enthalten. Diese Option ist nicht immer verfügbar. Sie sollten sich auf keinen Fall darauf verlassen und nur zum manuellen Debuggen von Modellen verwenden. |
FieldReference
Gibt einen Kontext für den Validierungsfehler an. Ein FieldReference
verweist immer auf ein bestimmtes Feld in dieser Datei und hat dieselbe hierarchische Struktur. Beispielsweise können wir Element 2 von start_time_windows
von Fahrzeug 5 wie folgt angeben:
name: "vehicles" index: 5 sub_field { name: "end_time_windows" index: 2 }
Entitäten der obersten Ebene wie OptimizeToursRequest
oder ShipmentModel
werden jedoch weggelassen, um eine Überfüllung der Nachricht zu vermeiden.
Felder | |
---|---|
name |
Name des Felds, z.B. „Fahrzeuge“. |
sub_field |
Bei Bedarf rekursiv verschachteltes untergeordnetes Feld. |
Union-Feld Für |
|
index |
Index des Felds, falls wiederholt. |
key |
Key, wenn das Feld eine Zuordnung ist. |
OutputConfig
Geben Sie ein Ziel für [BatchOptimizeTours][google.maps.routeOptimization.v1.RouteOptimizationService.BatchOptimizeTours]-Ergebnisse an.
Felder | |
---|---|
data_format |
Erforderlich. Das Ausgabedatenformat. |
Union-Feld destination . Erforderlich. Für destination ist nur einer der folgenden Werte zulässig: |
|
gcs_destination |
Der Google Cloud Storage-Speicherort, in den die Ausgabe geschrieben wird. |
RouteModifiers
Schließt eine Reihe optionaler Bedingungen ein, die bei der Berechnung von Fahrzeugrouten erfüllt werden müssen. Dies ähnelt RouteModifiers
in der Google Maps Platform Routes Preferred API. Weitere Informationen finden Sie unter https://developers.google.com/maps/documentation/routes/reference/rest/v2/RouteModifiers.
Felder | |
---|---|
avoid_tolls |
Gibt an, ob Mautstraßen gegebenenfalls vermieden werden. Routen ohne Mautstraßen werden bevorzugt. Gilt nur für motorisierte Fortbewegungsarten. |
avoid_highways |
Gibt an, ob Autobahnen vermieden werden sollen, sofern dies sinnvoll ist. Vorzug wird Routen gegeben, die keine Autobahnen enthalten. Gilt nur für motorisierte Fortbewegungsarten. |
avoid_ferries |
Gibt an, ob Fähren gegebenenfalls vermieden werden sollen. Routen, die keine Fähren enthalten, werden bevorzugt. Gilt nur für motorisierte Fortbewegungsarten. |
avoid_indoor |
Optional. Gibt an, ob das Fahren in Innenräumen angemessen ist. Routen, die keine Indoor-Navigationssysteme enthalten, haben Vorrang. Gilt nur für die Mobilitätsform |
Versand
Der Versand eines einzelnen Artikels von einer Abholstelle zu einer Lieferstelle. Damit die Sendung als ausgeführt gilt, muss ein einzelnes Fahrzeug einen Abholort anfahren (und die freien Kapazitäten entsprechend reduzieren) und dann später einen der Lieferorte aufsuchen (und die freien Kapazitäten entsprechend erhöhen).
Felder | |
---|---|
display_name |
Der benutzerdefinierte Anzeigename der Sendung. Er kann bis zu 63 Zeichen lang sein und UTF-8-Zeichen enthalten. |
pickups[] |
Eine Reihe von Alternativen für die Abholung, die der Sendung zugeordnet sind. Wenn nicht angegeben, muss das Fahrzeug nur einen Lieferort aufsuchen. |
deliveries[] |
Gruppe von Lieferalternativen für die Lieferung. Wenn nicht angegeben, muss das Fahrzeug nur zu einem Ort aufsuchen, an dem die Abholung stattfindet. |
load_demands |
Die Anforderungen der Sendung (z. B. Gewicht, Menge, Anzahl der Paletten usw.) Die Schlüssel in der Zuordnung sollten IDs sein, die den Typ der entsprechenden Ladung beschreiben, idealerweise auch mit den Einheiten. Beispiel: „weight_kg“, „volumen_gallons“, „pallet_count“ usw. Wenn ein bestimmter Schlüssel nicht auf der Karte erscheint, wird die entsprechende Last als null betrachtet. |
allowed_vehicle_indices[] |
Die Fahrzeuge, die diese Sendung ausführen können. Wenn das Feld leer ist, kann die Aktion von allen Fahrzeugen ausgeführt werden. Fahrzeuge sind gemäß ihrem Index in der |
costs_per_vehicle[] |
Gibt die Kosten an, die anfallen, wenn diese Sendung von jedem Fahrzeug zugestellt wird. Falls angegeben, muss Folgendes vorhanden sein:
Diese Kosten müssen sich in derselben Einheit wie |
costs_per_vehicle_indices[] |
Indizes der Fahrzeuge, für die |
pickup_to_delivery_absolute_detour_limit |
Gibt die maximale absolute Umwegzeit im Vergleich zum kürzesten Weg von Abholung bis Lieferung an. Wenn angegeben, muss er ein positiver Wert sein und die Sendung muss mindestens eine Abholung und eine Lieferung enthalten. Es sollte beispielsweise die kürzeste Zeit sein, die von der ausgewählten Abholoption direkt zur ausgewählten Lieferalternative benötigt wird. Wenn Sie dann
Wenn für dieselbe Lieferung sowohl relative als auch absolute Grenzwerte angegeben sind, wird für jedes mögliche Paar aus Abholung und Lieferung das restriktivere Limit verwendet. Seit dem 10. Oktober 2017 werden Umleitungen nur noch unterstützt, wenn die Reisedauer nicht von den Fahrzeugen abhängig ist. |
pickup_to_delivery_time_limit |
Gibt die maximale Dauer vom Beginn der Abholung bis zum Beginn der Lieferung einer Sendung an. Wenn angegeben, muss der Wert nicht negativ sein und die Sendung muss mindestens eine Abholung und eine Zustellung enthalten. Dies hängt nicht davon ab, welche Alternativen für Abholung und Lieferung ausgewählt werden, oder von der Fahrzeuggeschwindigkeit. Dieser Wert kann zusammen mit Einschränkungen für die maximale Umleitung angegeben werden. Die Lösung berücksichtigt dann beide Spezifikationen. |
shipment_type |
Ein nicht leerer String zur Angabe eines „Typs“ für diese Lieferung. Mit dieser Funktion können Inkompatibilitäten oder Anforderungen zwischen unterscheidet sich von „ |
label |
Gibt ein Label für diese Sendung an. Dieses Label wird in der Antwort im |
ignore |
Wenn wahr, überspringen Sie diese Sendung, aber wenden Sie keine Wenn eine Sendung ignoriert wird, tritt ein Validierungsfehler auf, wenn Das Ignorieren einer Lieferung, die in |
penalty_cost |
Wenn die Lieferung nicht abgeschlossen wird, wird diese Vertragsstrafe auf die Gesamtkosten der Routen aufgeschlagen. Eine Sendung gilt als abgeschlossen, wenn eine ihrer Abhol- und Lieferoptionen aufgerufen wird. Die Kosten können in derselben Einheit angegeben werden, die für alle anderen kostenbezogenen Felder im Modell verwendet wird. Sie müssen positiv sein. WICHTIG: Wenn diese Strafe nicht angegeben ist, gilt sie als unendlich, d.h., der Versand muss abgeschlossen sein. |
pickup_to_delivery_relative_detour_limit |
Gibt die maximale relative Umleitungszeit im Vergleich zum kürzesten Weg von Abholung bis Lieferung an. Wenn angegeben, muss der Wert nicht negativ sein und die Sendung muss mindestens eine Abholung und eine Zustellung enthalten. Es sollte beispielsweise die kürzeste Zeit sein, die von der ausgewählten Abholoption direkt zur ausgewählten Lieferalternative benötigt wird. Dann wird durch das Festlegen von
Wenn für dieselbe Lieferung sowohl relative als auch absolute Grenzwerte angegeben sind, wird für jedes mögliche Paar aus Abholung und Lieferung das restriktivere Limit verwendet. Seit dem 10. Oktober 2017 werden Umleitungen nur noch unterstützt, wenn die Reisedauer nicht von den Fahrzeugen abhängig ist. |
Laden
Bei einem Abholtermin wird unter Umständen ein vordefinierter Betrag zur Fahrzeugauslastung hinzugerechnet, wenn es sich um einen Abholservice handelt, oder einen Abzugsbetrag, wenn es sich um eine Lieferung handelt. In dieser Nachricht wird ein solcher Betrag definiert. load_demands
ansehen.
Felder | |
---|---|
amount |
Der Auslastungsgrad des Fahrzeugs für den entsprechenden Besuch variiert. Da es sich um eine Ganzzahl handelt, sollten Nutzer eine geeignete Einheit auswählen, um Abweichungen bei der Genauigkeit zu vermeiden. Muss ≥ 0 sein. |
VisitRequest
Anfrage für einen Besuch, der mit einem Fahrzeug durchgeführt werden kann: Es hat einen (oder zwei, siehe unten) geografischen Standort, Öffnungszeiten, die durch Zeitfenster dargestellt werden, und eine Dienstleistungsdauer (Zeit, die das Fahrzeug nach der Ankunft für die Abholung oder Abgabe von Waren benötigt).
Felder | |
---|---|
arrival_location |
Der Standort, an dem das Fahrzeug beim Ausführen dieser |
arrival_waypoint |
Der Wegpunkt, an dem das Fahrzeug bei dieser |
departure_location |
Der geografische Standort, an dem das Fahrzeug nach Abschluss dieser |
departure_waypoint |
Der Wegpunkt, an dem das Fahrzeug nach Abschluss dieser |
tags[] |
Gibt Tags an, die an die Besuchsanfrage angehängt sind. Leere oder doppelte Strings sind nicht zulässig. |
time_windows[] |
Zeitfenster, die die Ankunftszeit bei einem Besuch einschränken. Beachten Sie, dass ein Fahrzeug möglicherweise außerhalb der Ankunftszeit abfahren kann, d.h. Ankunftszeit und Dauer müssen nicht innerhalb eines Zeitfensters liegen. Dies kann zu Wartezeiten führen, wenn das Fahrzeug vor Wenn Die Zeitfenster dürfen sich nicht überschneiden, d. h., sie dürfen sich nicht überschneiden oder aneinander angrenzen. Außerdem müssen sie in aufsteigender Reihenfolge angegeben werden.
|
duration |
Dauer des Besuchs, d. h. die Zeit, die das Fahrzeug zwischen Ankunft und Abfahrt verbringt (wird zur möglichen Wartezeit addiert, siehe |
cost |
Kosten für die Bearbeitung dieser Besuchsanfrage auf einer Fahrzeugroute. Damit können unterschiedliche Kosten für jede alternative Abholung oder Lieferung einer Sendung bezahlt werden. Diese Kosten müssen in derselben Einheit wie |
load_demands |
Ladeanforderungen für diese Besuchsanfrage. Dieses Feld funktioniert genauso wie das Feld |
visit_types[] |
Gibt die Arten des Besuchs an. Damit kann zusätzliche Zeit zugewiesen werden, die ein Fahrzeug für diesen Besuch benötigt (siehe Ein Typ kann nur einmal vorkommen. |
label |
Gibt ein Label für dieses |
ShipmentModel
Ein Versandmodell enthält eine Reihe von Sendungen, die von einer Gruppe von Fahrzeugen durchgeführt werden müssen und dabei die Gesamtkosten, die sich aus der folgenden Summe ergeben, zu minimieren:
- die Kosten für die Routenplanung der Fahrzeuge (Summe der Kosten pro Gesamtzeit, Kosten pro Fahrtzeit und Fixkosten für alle Fahrzeuge).
- die nicht erfüllten Versandstrafen.
- die Kosten der globalen Dauer der Lieferungen
Felder | |
---|---|
shipments[] |
Satz von Sendungen, die im Modell ausgeführt werden müssen. |
vehicles[] |
Fahrzeuge, die für Besuche verwendet werden können. |
global_start_time |
Globale Start- und Endzeit des Modells: Zeiten außerhalb dieses Bereichs können nicht als gültig angesehen werden. Der Zeitraum des Modells darf nicht länger als ein Jahr sein. Das heißt, der Wenn Sie |
global_end_time |
Wenn kein Wert festgelegt ist, wird standardmäßig 00:00:00 UTC, der 1. Januar 1971 (Sekunden: 31536000, Nanos: 0) verwendet. |
global_duration_cost_per_hour |
Die „globale Dauer“ des Gesamtplans ist die Differenz zwischen der frühesten effektiven Startzeit und der letzten effektiven Endzeit aller Fahrzeuge. Nutzende können dieser Menge Kosten pro Stunde zuweisen, um beispielsweise zu versuchen, den frühesten Abschluss eines Auftrags zu optimieren. Diese Kosten müssen in derselben Einheit wie |
duration_distance_matrices[] |
Gibt die im Modell verwendeten Matrizen für Dauer und Entfernung an. Wenn dieses Feld leer ist, werden je nach Wert des Felds Typische Syntax:
|
duration_distance_matrix_src_tags[] |
Tags, mit denen die Quellen der Matrizen für Dauer und Entfernung definiert werden Tags entsprechen |
duration_distance_matrix_dst_tags[] |
Tags, mit denen die Ziele der Matrizen für Dauer und Entfernung definiert werden Tags entsprechen |
transition_attributes[] |
Dem Modell wurden Übergangsattribute hinzugefügt. |
shipment_type_incompatibilities[] |
Sets inkompatibler „shipment_types“ (siehe |
shipment_type_requirements[] |
Gruppe von |
precedence_rules[] |
Satz von Prioritätsregeln, die im Modell erzwungen werden müssen. |
max_active_vehicles |
Beschränkt die maximale Anzahl aktiver Fahrzeuge. Ein Fahrzeug ist aktiv, wenn auf seiner Route mindestens eine Sendung ausgeführt wird. Dies kann verwendet werden, um die Anzahl der Routen für den Fall zu begrenzen, dass es weniger Fahrer als Fahrzeuge gibt und der Fuhrpark heterogen ist. Bei der Optimierung wird dann die beste Teilmenge von Fahrzeugen ausgewählt. Muss streng positiv sein. |
DurationDistanceMatrix
Gibt eine Matrix für die Dauer und die Entfernung zwischen Besuchs- und Fahrzeugstartstandorten und Zielstandorten an.
Felder | |
---|---|
rows[] |
Gibt die Zeilen der Dauer- und Distanzmatrix an. Es muss so viele Elemente wie |
vehicle_start_tag |
Tag, das definiert, für welche Fahrzeuge diese Matrix für Dauer und Distanz gilt. Wenn das Feld leer ist, gilt dies für alle Fahrzeuge und es kann nur eine Matrix geben. Jeder Fahrzeugstart muss genau einer Matrix entsprechen, d.h. genau eines der Alle Matrizen müssen eine andere |
Zeile
Gibt eine Zeile mit der Matrix für Dauer und Distanz an.
Felder | |
---|---|
durations[] |
Werte für die Dauer einer bestimmten Zeile. Es muss so viele Elemente wie |
meters[] |
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 |
PrecedenceRule
Eine Vorrangregel zwischen zwei Ereignissen (jedes Ereignis ist die Abholung oder Lieferung einer Sendung): das „zweite“ Ereignis muss mindestens offset_duration
nach dem „ersten“ beginnen hat begonnen.
Mehrere Vorrangstufen können sich auf dieselben (oder ähnliche) Ereignisse beziehen, z. B. „Abholung von B erfolgt nach Lieferung von A“ und „Abhol von C erfolgt nach Abholung von B“.
Darüber hinaus gelten Vorrangstufen nur dann, wenn beide Lieferungen durchgeführt werden, und werden ansonsten ignoriert.
Felder | |
---|---|
first_is_delivery |
Gibt an, ob das erste Ereignis eine Übermittlung ist. |
second_is_delivery |
Gibt an, ob das „second“-Element ist eine Lieferung. |
offset_duration |
Die Zeitspanne zwischen dem ersten und dem zweiten Ereignis. Sie kann negativ sein. |
first_index |
Versandindex der ersten Angabe . Dieses Feld muss angegeben werden. |
second_index |
Versandindex der „zweiten“ Antwort . Dieses Feld muss angegeben werden. |
ShipmentRoute
Die Route eines Fahrzeugs kann so auf der Zeitachse dargestellt werden (wir gehen davon aus, dass es n Besuche gibt):
| | | | | 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
Beachten Sie bitte Folgendes:
- „Pünktliche Ereignisse“, z. B. Start und Ende des Fahrzeugs sowie Start und Ende jedes Besuchs (Ankunft und Abfahrt). Sie finden in einer bestimmten Sekunde statt.
- "Zeitintervalle" wie 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 einer vorherigen (gleicher Index) und einer nachfolgenden (Index + 1) Transition umgeben.
- Auf den Fahrzeugstart folgt immer der Übergang 0.
- Dem Fahrzeugende geht immer der Übergang #n voraus.
Beim Heranzoomen passiert bei Transition
und Visit
Folgendes:
---+-------------------------------------+-----------------------------+-->
| 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
Und hier ist noch eine kurze Zusammenfassung, wie sich TRAVEL, BREAKS, DELAY und WAIT während eines Übergangs anordnen lassen.
- Sie überschneiden sich nicht.
- Die VERZÖGERUNG ist eindeutig und muss ein zusammenhängender Zeitraum direkt vor dem nächsten Besuch (oder dem Ende des Fahrzeugs) sein. Daher reicht es aus, die Verzögerungsdauer zu kennen, um den Beginn und das Ende zu ermitteln.
- Die Pausen sind zusammenhängende, nicht überlappende Zeiträume. Die Antwort gibt den Beginn und die Dauer jeder Pause an.
- TRAVEL und WAIT sind präemptiv und können während dieses Übergangs mehrmals unterbrochen werden. Kunden können davon ausgehen, dass die Fahrt „so bald 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 |
Fahrzeug, das die Route ausführt, das durch seinen Index in der Quelle |
vehicle_label |
Label des Fahrzeugs, das diese Route fährt. Entspricht |
vehicle_start_time |
Die Uhrzeit, zu der das Fahrzeug seine Route beginnt. |
vehicle_end_time |
Die Uhrzeit, zu der das Fahrzeug seine Route beendet. |
visits[] |
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 nicht genutzt. |
transitions[] |
Sortierte Liste der Übergänge für die Route. |
has_traffic_infeasibilities |
Wenn
Die Ankunft bei next_visit erfolgt wahrscheinlich später als im aktuellen Zeitfenster, da die geschätzte Fahrtzeit aufgrund der Verkehrslage um |
route_polyline |
Die codierte Polyliniendarstellung der Route. Dieses Feld wird nur ausgefüllt, wenn |
breaks[] |
Geplante Pausen für das Fahrzeug, das auf dieser Route unterwegs ist. Die Sequenz |
metrics |
Messwerte für Dauer, Entfernung und Last für diese Route. Die Felder von |
route_costs |
Kosten der Route, aufgeschlüsselt nach kostenbezogenen Anfragefeldern. Die Schlüssel sind Proto-Pfade, bezogen auf die Eingabe OptimizeToursRequest, z. B. „model.shipments.pickups.cost“. Die Werte sind die Gesamtkosten, die durch das entsprechende Kostenfeld generiert wurden, 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 von Kosten im Zusammenhang mit Übergangsattributen, die seit dem 01.01.2022 nur in aggregierter Form gemeldet werden. |
route_total_cost |
Gesamtkosten der Route. Die Summe aller Kosten in der Kostenliste. |
Pause
Daten zur Ausführung einer Pause.
Felder | |
---|---|
start_time |
Beginn einer Pause. |
duration |
Dauer einer Pause. |
EncodedPolyline
Die codierte Darstellung einer Polylinie. Weitere Informationen zur Codierung von Polylinien finden Sie hier: https://developers.google.com/maps/documentation/utilities/polylinealgorithm https://developers.google.com/maps/documentation/javascript/reference/geometry#encoding.
Felder | |
---|---|
points |
String, der codierte Punkte der Polylinie darstellt. |
Wechsel
Übergang zwischen zwei Ereignissen auf der Route. Weitere Informationen finden Sie in der Beschreibung von ShipmentRoute
.
Wenn das Fahrzeug keine start_location
und/oder end_location
hat, sind die entsprechenden Fahrtmesswerte 0.
Felder | |
---|---|
travel_duration |
Reisedauer während dieser Umstellung. |
travel_distance_meters |
Die beim Übergang zurückgelegte Strecke. |
traffic_info_unavailable |
Wenn Traffic über |
delay_duration |
Summe der Verzögerungszeiten, die auf diesen Übergang angewendet wurden. Falls vorhanden, beginnt die Verzögerung genau |
break_duration |
Summe der Dauer der Pausen, die während dieses Übergangs auftreten, falls vorhanden. Details zu Beginn und Dauer der einzelnen Pausen werden in |
wait_duration |
Wartezeit während dieser Umstellung. Die Wartezeit entspricht der Inaktivitätsdauer und schließt keine Pausen ein. Beachten Sie auch, dass diese Wartezeit in mehrere nicht aufeinanderfolgende Intervalle aufgeteilt werden kann. |
total_duration |
Gesamtdauer der Umstellung zur besseren Übersicht. Er ist gleich:
|
start_time |
Startzeit dieses Übergangs. |
route_polyline |
Die codierte Polyliniendarstellung der Route, der während des Übergangs gefolgt wird. Dieses Feld wird nur ausgefüllt, wenn |
vehicle_loads |
Fahrzeugladevorgänge während dieses Übergangs für jeden Typ, der entweder in der Die Lasten während der ersten Umstellung sind die Anfangslasten der Fahrzeugroute. Nach jedem Besuch werden die |
VehicleLoad
Meldet die tatsächliche Auslastung des Fahrzeugs an einem bestimmten Punkt der Route für einen bestimmten Typ (siehe Transition.vehicle_loads
).
Felder | |
---|---|
amount |
Die Belastung des Fahrzeugs für den jeweiligen Typ. Die Lasteinheit wird normalerweise durch den Typ angegeben. |
Aufrufen
Ein Besuch während einer Route. Dieser Besuch entspricht der Abholung oder Lieferung eines Shipment
.
Felder | |
---|---|
shipment_index |
Index des Felds |
is_pickup |
Falls wahr, entspricht der Besuch der Abholung eines |
visit_request_index |
Index von |
start_time |
Startzeit des Besuchs. Beachte, dass das Fahrzeug möglicherweise früher am Ort ankommt. Die Zeiten entsprechen den |
load_demands |
Der gesamte Besuchslastbedarf als Summe der Sendung und der Besuchsanfrage |
detour |
Zusätzliche Umleitungszeit aufgrund der Lieferungen, die vor dem Besuch auf der Route gefahren wurden, und der potenziellen Wartezeit, die sich aus Zeitfenstern ergibt. Wenn es sich beim Besuch um einen Lieferservice handelt, wird die Umleitung aus dem entsprechenden Abholtermin berechnet und ist gleich:
Andernfalls wird er anhand des Fahrzeugs
|
shipment_label |
Kopie des entsprechenden |
visit_label |
Kopie des entsprechenden |
ShipmentTypeIncompatibility
Gibt Inkompatibilitäten zwischen Sendungen in Abhängigkeit von ihrem „shipment_type“ an. Inkompatible Sendungen auf derselben Route sind aufgrund des Inkompatibilitätsmodus eingeschränkt.
Felder | |
---|---|
types[] |
Liste der inkompatiblen Typen. Zwei Sendungen mit unterschiedlichen |
incompatibility_mode |
Modus, der auf die Inkompatibilität angewendet wird. |
IncompatibilityMode
Mobilitätsformen, mit denen das Auftreten inkompatibler Sendungen auf derselben Route eingeschränkt werden.
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 nicht dasselbe Fahrzeug teilen. |
NOT_IN_SAME_VEHICLE_SIMULTANEOUSLY |
Für zwei Sendungen mit inkompatiblen Typen mit dem Inkompatibilitätsmodus
|
ShipmentTypeRequirement
Gibt Anforderungen zwischen Sendungen basierend auf ihrem „shipment_type“ an. Die Details der Anforderung werden durch den Anforderungsmodus definiert.
Felder | |
---|---|
required_shipment_type_alternatives[] |
Liste alternativer Versandtypen, die von der |
dependent_shipment_types[] |
Alle Sendungen eines Typs im Feld HINWEIS: Anforderungsketten, die davon abhängen, ein |
requirement_mode |
Modus wurde auf die Anforderung angewendet. |
RequirementMode
Mobilitätsformen, mit denen das Erscheinungsbild abhängiger Sendungen auf einer Route bestimmt wird.
Enums | |
---|---|
REQUIREMENT_MODE_UNSPECIFIED |
Nicht angegebener Anforderungsmodus. Dieser Wert sollte niemals verwendet werden. |
PERFORMED_BY_SAME_VEHICLE |
In diesem Modus sind alle "abhängigen" Sendungen müssen dasselbe Fahrzeug verwenden wie mindestens eines ihrer Lieferungen. |
IN_SAME_VEHICLE_AT_PICKUP_TIME |
Im Ein „abhängiges“ Die Abholung der Sendung muss daher Folgendes enthalten:
|
IN_SAME_VEHICLE_AT_DELIVERY_TIME |
Wie zuvor, mit Ausnahme von „Abhängigkeit“ Sendungen einen erforderlichen zum Zeitpunkt der Lieferung im Fahrzeug versendet wurde. |
SkippedShipment
Gibt Details zu nicht ausgeführten Sendungen in einer Lösung an. In einfachen Fällen und/oder wenn wir den Grund für das Überspringen ermitteln können, geben wir den Grund hier an.
Felder | |
---|---|
index |
Der Index entspricht dem Index der Sendung in der Quelle |
label |
Kopie des entsprechenden |
reasons[] |
Eine Liste mit Gründen, warum die Sendung übersprungen wurde. Siehe Kommentar oben: |
Grund
Falls wir erklären können, warum die Sendung übersprungen wurde, werden hier die Gründe aufgeführt. Wenn der Grund nicht für alle Fahrzeuge gleich ist, enthält reason
mehr als ein Element. Eine übersprungene Sendung darf keine doppelten Gründe haben, d.h. alle Felder mit Ausnahme von example_vehicle_index
müssen identisch sein. 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 mindestens ein Fahrzeug hat die Bezeichnung „Äpfel“ Kapazität überschritten würde (einschließlich Fahrzeug 1), mindestens ein Fahrzeug „Birnen“ Kapazität (einschließlich Fahrzeug 3) überschritten und die Distanzbeschränkung für mindestens ein Fahrzeug überschritten wird (einschließlich Fahrzeug 1).
Felder | |
---|---|
code |
Weitere Informationen finden Sie in den Kommentaren zum Code. |
example_exceeded_capacity_type |
Wenn der Grundcode |
example_vehicle_index |
Wenn der Grund mit einer Inkompatibilität zwischen Versand und Fahrzeug zusammenhängt, wird in diesem Feld der Index eines relevanten Fahrzeugs angegeben. |
Code
Code, der den Grundtyp identifiziert. Die Reihenfolge hier ist bedeutungslos. Insbesondere gibt sie keinen Hinweis darauf, ob ein bestimmter Grund in der Lösung vor einem anderen steht, wenn beide zutreffen.
Enums | |
---|---|
CODE_UNSPECIFIED |
Dies sollte niemals verwendet werden. |
NO_VEHICLE |
Das Modell enthält kein Fahrzeug, das Sendungen verhindert. |
DEMAND_EXCEEDS_VEHICLE_CAPACITY |
Die Anforderungen der Sendung übersteigen die Kapazität eines Fahrzeugs für einige Kapazitätstypen, darunter example_exceeded_capacity_type . |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DISTANCE_LIMIT |
Der Mindestabstand, der für diese Sendung erforderlich ist, d.h. vom Beachten Sie, dass wir für diese Berechnung die geodätischen Entfernungen verwenden. |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT |
Die für den Versand erforderliche Mindestzeit, einschließlich Reise-, Wartezeit und Servicezeit, überschreitet die Hinweis: Die Reisezeit wird im Best-Case-Szenario berechnet, nämlich als geodätische Entfernung x 36 m/s (ungefähr 130 km/h). |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TRAVEL_DURATION_LIMIT |
Wie oben, aber wir vergleichen nur die minimale Reisezeit und die travel_duration_limit des Fahrzeugs. |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TIME_WINDOWS |
Das Fahrzeug kann diese Sendung im Best-Case-Szenario (siehe CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT zur Zeitberechnung) nicht ausführen, wenn es zum frühesten Startzeitpunkt startet: Die Gesamtzeit würde das Fahrzeug nach der letzten Endzeit enden. |
VEHICLE_NOT_ALLOWED |
Das Feld „allowed_vehicle_indices “ der Sendung ist nicht leer und dieses Fahrzeug gehört nicht dazu. |
TimeWindow
Zeitfenster begrenzen die Zeit eines Ereignisses, z. B. die Ankunftszeit bei einem Besuch oder den Beginn und das Ende eines Fahrzeugs.
Die Grenzen des festen Zeitfensters (start_time
und end_time
) erzwingen die früheste und letzte Zeit des Ereignisses, z. B. start_time <= event_time <=
end_time
. Die Untergrenze des weichen Zeitfensters (soft_start_time
) drückt aus, dass das Ereignis am oder nach dem soft_start_time
eintreten soll, indem Kosten proportional zur Zeit vor dem Ereignis „soft_start_time“ anfallen. Die Obergrenze des weichen Zeitfensters soft_end_time
gibt an, dass das Ereignis am oder vor dem soft_end_time
eintreten soll, indem Kosten proportional zur Zeit nach soft_end_time
des Ereignisses anfallen. start_time
, end_time
, soft_start_time
und soft_end_time
müssen innerhalb der globalen Zeitlimits liegen (siehe ShipmentModel.global_start_time
und ShipmentModel.global_end_time
) und Folgendes einhalten:
0 <= `start_time` <= `end_time` and
0 <= `start_time` <= `soft_start_time` and
0 <= `soft_end_time` <= `end_time`.
Felder | |
---|---|
start_time |
Die Startzeit des schweren Zeitfensters. Wenn kein Wert angegeben ist, wird er auf |
end_time |
Das Ende des Zeitfensters. Wenn kein Wert angegeben ist, wird er auf |
soft_start_time |
Die Startzeit des Zeitfensters. |
soft_end_time |
Die weiche Endzeit des Zeitfensters. |
cost_per_hour_before_soft_start_time |
Kosten pro Stunde, die zu den anderen Kosten im Modell hinzugefügt werden, wenn das Ereignis vor soft_start_time eintritt. Der Wert wird wie folgt berechnet:
Diese Kosten müssen positiv sein. Das Feld kann nur festgelegt werden, wenn „soft_start_time“ festgelegt wurde. |
cost_per_hour_after_soft_end_time |
Kosten pro Stunde, die zu den anderen Kosten im Modell hinzugefügt werden, wenn das Ereignis nach dem
Diese Kosten müssen positiv sein und das Feld kann nur festgelegt werden, wenn |
TransitionAttributes
Gibt Attribute von Übergängen zwischen zwei aufeinanderfolgenden Besuchen auf einer Route an. Für denselben Übergang können mehrere TransitionAttributes
gelten: In diesem Fall summieren sich alle zusätzlichen Kosten und es gilt die strengste Einschränkung oder Grenze gemäß der natürlichen „AND“-Semantik.
Felder | |
---|---|
src_tag |
Tags, mit denen die Gruppe der (src->dst)-Übergänge definiert wird, für die diese Attribute gelten. Ein Quellbesuch oder Fahrzeugstart wird nur dann abgeglichen, wenn |
excluded_src_tag |
|
dst_tag |
Ein Zielbesuch oder ein Fahrzeugende stimmt überein, wenn |
excluded_dst_tag |
|
cost |
Gibt die Kosten für diese Umstellung an. Diese Einheit entspricht allen anderen Kosten im Modell und darf nicht negativ sein. Er wird zusätzlich zu allen anderen bestehenden Kosten angewendet. |
cost_per_kilometer |
Gibt die Kosten pro Kilometer an, die auf die beim Wechsel zurückgelegte Strecke angewendet werden. Die Summe ergibt alle |
distance_limit |
Gibt eine Grenze für die zurückgelegte Strecke an, die während dieses Übergangs zurückgelegt wird. Seit dem 06.06.2021 werden nur weiche Limits unterstützt. |
delay |
Gibt eine Verzögerung an, die beim Ausführen dieses Übergangs auftritt. Diese Verzögerung tritt immer nach dem Abschluss des Quellbesuchs und vor dem Start des Zielbesuchs auf. |
Fahrzeug
Modelliert ein Fahrzeug bei einem Versandproblem. Wenn du ein Versandproblem löst, wird für dieses Fahrzeug eine Route erstellt, die bei start_location
beginnt und um end_location
endet. Eine Route besteht aus einer Abfolge von Besuchen (siehe ShipmentRoute
).
Felder | |
---|---|
display_name |
Der benutzerdefinierte Anzeigename des Fahrzeugs. Er kann bis zu 63 Zeichen lang sein und UTF-8-Zeichen enthalten. |
travel_mode |
Die Mobilitätsform, die sich auf die vom Fahrzeug nutzbaren Straßen und seine Geschwindigkeit auswirkt. Siehe auch |
route_modifiers |
Eine Reihe von Bedingungen, die erfüllt sein müssen und sich auf die Berechnung von Routen für das betreffende Fahrzeug auswirken. |
start_location |
Geografische Position, an der das Fahrzeug startet, bevor es Sendungen abholt. Wenn nicht angegeben, beginnt das Fahrzeug bei der ersten Abholung. Wenn das Versandmodell Matrizen für Dauer und Entfernung enthält, darf |
start_waypoint |
Wegpunkt, der einen geografischen Standort darstellt, an dem das Fahrzeug startet, bevor eine Sendung abgeholt wird. Wenn weder |
end_location |
Der geografische Standort, an dem das Fahrzeug endet, nachdem es seine letzte |
end_waypoint |
Wegpunkt, der einen geografischen Standort darstellt, an dem das Fahrzeug endet, nachdem es seine letzte |
start_tags[] |
Gibt Tags an, die am Anfang der Route des Fahrzeugs angebracht sind. Leere oder doppelte Strings sind nicht zulässig. |
end_tags[] |
Gibt Tags an, die am Ende der Route des Fahrzeugs angehängt sind. Leere oder doppelte Strings sind nicht zulässig. |
start_time_windows[] |
Zeitfenster, in denen das Fahrzeug vom Startort losfahren kann. Sie müssen innerhalb der globalen Zeitbeschränkungen liegen (siehe Felder „ Zeitfenster, die zum selben wiederholten Feld gehören, müssen disjunkt sein, d. h., kein Zeitfenster darf sich mit einem anderen überschneiden oder aneinander liegen. Außerdem müssen sie in chronologischer Reihenfolge angegeben sein.
|
end_time_windows[] |
Zeitfenster, in denen das Fahrzeug am Endstandort ankommt. Sie müssen innerhalb der globalen Zeitbeschränkungen liegen (siehe Felder „ Zeitfenster, die zum selben wiederholten Feld gehören, müssen disjunkt sein, d. h., kein Zeitfenster darf sich mit einem anderen überschneiden oder aneinander liegen. Außerdem müssen sie in chronologischer Reihenfolge angegeben sein.
|
unloading_policy |
Die Richtlinie zum Entladen wird für das Fahrzeug erzwungen. |
load_limits |
Kapazität des Fahrzeugs (z. B. Gewicht, Volumen, Anzahl der Paletten). Die Schlüssel in der Zuordnung sind die IDs des Ladetyps, die mit den Schlüsseln im Feld |
cost_per_hour |
Fahrzeugkosten: Alle Kosten werden addiert und müssen in derselben Einheit wie Kosten pro Stunde der Fahrzeugroute. Diese Kosten werden auf die Gesamtzeit der Route angewendet und umfassen Fahrtzeit, Wartezeit und Besuchszeit. Die Verwendung von |
cost_per_traveled_hour |
Kosten pro Stunde der Fahrzeugroute. Diese Kosten werden nur auf die Reisezeit der Route angewendet (d. h. die in |
cost_per_kilometer |
Kosten pro Kilometer der Fahrzeugroute. Diese Kosten werden auf die in der |
fixed_cost |
Pauschalkosten, die anfallen, wenn dieses Fahrzeug für die Bearbeitung einer Sendung verwendet wird. |
used_if_route_is_empty |
Dieses Feld gilt nur für Fahrzeuge, deren Route keine Sendungen bedient. Gibt an, ob das Fahrzeug in diesem Fall als gebraucht gilt oder nicht. Falls wahr, bewegt sich das Fahrzeug vom Start bis zum Ziel, auch wenn es keine Sendungen bedient, sowie die aus dem Start entstehenden Zeit- und Entfernungskosten --> Endreise berücksichtigt werden. Andernfalls wird das Fahrzeug nicht vom Start- zum Zielort bewegt und für dieses Fahrzeug sind keine |
route_duration_limit |
Das Limit wird auf die Gesamtdauer der Route des Fahrzeugs angewendet. In einer bestimmten |
travel_duration_limit |
Die Beschränkung gilt für die Reisedauer der Route des Fahrzeugs. In einer bestimmten |
route_distance_limit |
Die Begrenzung wird auf die Gesamtstrecke der Fahrzeugroute angewendet. In einer bestimmten |
extra_visit_duration_for_visit_type |
Gibt eine Zuordnung von Visit_types-Strings zur Dauer an. Die Dauer ist zusätzlich zu Wenn eine Besuchsanfrage mehrere Typen aufweist, wird für jeden Typ in der Karte eine Dauer hinzugefügt. |
break_rule |
Beschreibt den Pausenzeitplan, der für dieses Fahrzeug erzwungen werden soll. Wenn das Feld leer ist, werden für dieses Fahrzeug keine Pausen geplant. |
label |
Gibt ein Label für dieses Fahrzeug an. Dieses Label wird in der Antwort als |
ignore |
Falls wahr, muss Wenn ein Versand von einem in Wenn eine Sendung von einem ignorierten Fahrzeug in |
travel_duration_multiple |
Gibt einen multiplikativen Faktor an, mit dem die Fahrtzeit dieses Fahrzeugs erhöht oder verringert werden kann. Wenn Sie diesen Wert beispielsweise auf 2,0 festlegen, ist dieses Fahrzeug langsamer und hat doppelt so hohe Fahrzeiten wie bei Standardfahrzeugen. Dieser Multiplikator wirkt sich nicht auf die Besuchsdauer aus. Es wirkt sich auf die Kosten aus, wenn WARNUNG: Die Fahrtzeiten werden auf die nächste Sekunde gerundet, nachdem dieses Vielfache angewendet wurde, aber vor der Durchführung numerischer Operationen. Daher kann ein kleines Vielfaches zu einem Genauigkeitsverlust führen. Siehe auch |
DurationLimit
Ein Limit, das die maximale Dauer der Route eines Fahrzeugs definiert. Er kann entweder hart oder weich sein.
Wenn ein Feld für weiches Limit definiert ist, müssen sowohl der Schwellenwert für das weiche Limit als auch die zugehörigen Kosten gemeinsam definiert werden.
Felder | |
---|---|
max_duration |
Ein festes Limit, das die Dauer auf maximal „max_duration“ beschränkt. |
soft_max_duration |
Bei einem weichen Limit, das keine maximale Dauer erzwingt, fallen bei einem Verstoß für die Route Kosten an. Diese Kosten werden mit anderen im Modell definierten Kosten mit derselben Einheit addiert. Falls definiert, darf |
quadratic_soft_max_duration |
Bei einem weichen Limit, das keine maximale Dauer erzwingt, fallen bei einem Verstoß für die Route Kosten mit quadratischer Dauer an. Diese Kosten summieren sich zu den anderen im Modell definierten Kosten mit derselben Einheit. Falls angegeben, darf
|
cost_per_hour_after_soft_max |
Kosten pro Stunde, wenn der Grenzwert
Die Kosten dürfen nicht negativ sein. |
cost_per_square_hour_after_quadratic_soft_max |
Die Kosten pro Quadratstunde, die beim Verstoß gegen den Grenzwert von Die zusätzlichen Kosten betragen 0, wenn die Dauer unter der Schwelle liegt. Andernfalls hängen die Kosten von der Dauer ab:
Die Kosten dürfen nicht negativ sein. |
LoadLimit
Definiert ein Lastlimit für ein Fahrzeug, z.B. „Der Lkw darf nur bis zu 3.500 kg tragen“. load_limits
ansehen.
Felder | |
---|---|
soft_max_load |
Ein weiches Limit der Last. |
cost_per_unit_above_soft_max |
Wenn die Last auf der Route dieses Fahrzeugs jemals |
start_load_interval |
Das akzeptable Ladeintervall des Fahrzeugs zu Beginn der Route. |
end_load_interval |
Das akzeptable Ladeintervall des Fahrzeugs am Ende der Route. |
max_load |
Die maximal zulässige Auslastung. |
Intervall
Intervall akzeptabler Lademengen.
Felder | |
---|---|
min |
Eine akzeptable Mindestlast. Muss ≥ 0 sein. Wenn beide angegeben sind, muss |
max |
Eine maximal zulässige Auslastung. Muss ≥ 0 sein. Wenn nicht angegeben, wird die maximale Last durch diese Nachricht nicht eingeschränkt. Wenn beide angegeben sind, muss |
TravelMode
Mobilitätsformen, die von Fahrzeugen genutzt werden können.
Diese sollten eine Teilmenge der Mobilitätsformen der Google Maps Platform Routes Preferred API sein, siehe https://developers.google.com/maps/documentation/routes_preferred/reference/rest/Shared.Types/RouteTravelMode.
Enums | |
---|---|
TRAVEL_MODE_UNSPECIFIED |
Mobilitätsform ohne Angabe, entspricht DRIVING . |
DRIVING |
Mobilitätsform, die der Route entspricht (Auto, ...). |
WALKING |
Mobilitätsform, die der Fußgängerroute entspricht. |
UnloadingPolicy
Richtlinie zum Entladen eines Fahrzeugs. Gilt nur für Sendungen mit Abholung und Lieferung.
Andere Lieferungen sind unabhängig von unloading_policy
überall auf der Route kostenlos.
Enums | |
---|---|
UNLOADING_POLICY_UNSPECIFIED |
Nicht spezifizierte Entladerichtlinie; Lieferungen müssen unmittelbar nach der entsprechenden Abholung erfolgen. |
LAST_IN_FIRST_OUT |
Lieferungen müssen in umgekehrter Reihenfolge der Abholung erfolgen. |
FIRST_IN_FIRST_OUT |
Die Lieferungen müssen in derselben Reihenfolge wie die Abholungen erfolgen. |
Zwischenstopp
Schließt einen Wegpunkt ein. Wegpunkte kennzeichnen die Ankunfts- und Abfahrtsorte von VisitRequests sowie Start- und Endpositionen von Fahrzeugen.
Felder | |
---|---|
side_of_road |
Optional. Gibt an, dass der Standort dieses Wegpunkts das Fahrzeug bevorzugt an einer bestimmten Straßenseite halten soll. Wenn Sie diesen Wert festlegen, verläuft die Route durch den Standort, sodass das Fahrzeug an der Straßenseite anhalten kann, zu der der Standort gewichtet ist. Diese Option funktioniert bei "WALKING" nicht Mobilitätsform. |
Union-Feld location_type . Verschiedene Möglichkeiten, einen Standort darzustellen. Für location_type ist nur einer der folgenden Werte zulässig: |
|
location |
Ein Punkt, der mithilfe geografischer Koordinaten angegeben wird, einschließlich einer optionalen Richtung. |
place_id |
Die mit dem Wegpunkt verknüpfte POI-Orts-ID. |