Method: projects.optimizeTours

string (Duration format)

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

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

object (ShipmentModel)

Das zu lösende Versandmodell.

enum (SolvingMode)

Der Standardmodus ist DEFAULT_SOLVE (0).

enum (SearchMode)

Der Suchmodus, der zum Beantworten der Anfrage verwendet wurde.

object (ShipmentRoute)

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

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

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

• Bei allen Routen muss vehicleIndex im Bereich liegen und darf nicht dupliziert werden.
• Bei allen Besuchen müssen shipmentIndex und visitRequestIndex im Bereich liegen.
• Auf eine Sendung darf nur in einer Route verwiesen werden.
• Die Abholung einer Sendung mit Abholung und Zustellung muss vor der Zustellung erfolgen.
• Es darf nur eine Abhol- oder Lieferalternative für eine Sendung durchgeführt werden.
• Bei allen Routen werden die Zeiten länger (d.h. vehicleStartTime <= visits[0].start_time <= visits[1].start_time ... <= vehicleEndTime).
• Eine Sendung darf nur mit einem zugelassenen Fahrzeug transportiert werden. Ein Fahrzeug ist zulässig, wenn Shipment.allowed_vehicle_indices leer ist oder sein vehicleIndex in Shipment.allowed_vehicle_indices enthalten ist.

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

object (InjectedSolutionConstraint)

Den Optimierungsalgorithmus so einschränken, dass eine Endlösung gefunden wird, die einer früheren Lösung ähnelt. Dies kann beispielsweise verwendet werden, um Abschnitte von Routen zu fixieren, die bereits abgeschlossen wurden oder die abgeschlossen werden sollen, aber nicht geändert werden dürfen.

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

object (ShipmentRoute)

Wenn nicht leer, werden die angegebenen Routen aktualisiert, ohne dass die zugrunde liegende Reihenfolge der Besuche oder die Reisezeiten 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 populatePolylines auf „true“ gesetzt sein.

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

Dieses Feld darf nicht zusammen mit injectedFirstSolutionRoutes oder injectedSolutionConstraint verwendet werden.

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

boolean

Falls zutreffend:

• Verwendet ShipmentRoute.vehicle_label anstelle von vehicleIndex, um Routen in einer eingefügten Lösung mit Fahrzeugen in der Anfrage abzugleichen. Die Zuordnung des ursprünglichen ShipmentRoute.vehicle_index zum neuen ShipmentRoute.vehicle_index wird wiederverwendet, um ConstraintRelaxation.vehicle_indices zu aktualisieren, falls es nicht leer ist. Die Zuordnung muss jedoch eindeutig sein. Das bedeutet, dass mehrere ShipmentRoutes nicht dasselbe ursprüngliche vehicleIndex haben dürfen.
• ShipmentRoute.Visit.shipment_label anstelle von shipmentIndex verwendet, um Besuche in einer eingefügten Lösung mit Sendungen in der Anfrage abzugleichen;
• SkippedShipment.label anstelle von SkippedShipment.index verwendet, um übersprungene Sendungen in der eingefügten Lösung mit Anforderungssendungen abzugleichen.

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

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

• 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 (mit Ausnahme von Abhol-/Lieferbesuchspaaren, deren shipmentLabel zweimal vorkommen muss).

Wenn ein vehicleLabel in der eingefügten Lösung nicht mit einem angeforderten Fahrzeug übereinstimmt, wird die entsprechende Route zusammen mit den zugehörigen Besuchen aus der Lösung entfernt. Wenn ein shipmentLabel in der eingefügten Lösung nicht mit einer Anfrageübergabe übereinstimmt, wird der entsprechende Besuch aus der Lösung entfernt. Wenn ein SkippedShipment.label in der eingefügten Lösung nicht mit einer Anfrageübersendung übereinstimmt, wird das SkippedShipment aus der Lösung entfernt.

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

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

boolean

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

boolean

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

boolean

Wenn „true“, werden Polylinien und Routentokens in der Antwort ShipmentRoute.transitions ausgegeben.

boolean

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

boolean

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

string

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

number

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

integer

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