Method: projects.locations.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 wird, je nachdem, was früher eintritt.

Bei asynchronen Anfragen generiert der Server (wenn möglich) vor Ablauf des Zeitlimits eine Lösung.

Die Dauer in Sekunden mit bis zu neun Nachkommastellen und am Ende mit "s". Beispiel: "3.5s".

object (ShipmentModel)

Zu lösendes Versandmodell.

enum (SolvingMode)

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

enum (SearchMode)

Der Suchmodus, der zur Lösung der Anfrage verwendet wurde.

object (ShipmentRoute)

Leiten Sie den Optimierungsalgorithmus an, um 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 vehicleIndex in Reichweite sein und darf nicht dupliziert werden.
• Für alle Besuche müssen shipmentIndex und visitRequestIndex im Bereich liegen.
• darf auf eine Sendung nur auf einer Route verwiesen werden.
• Die Abholung eines Versands mit Abhol- und Zustelloption muss vor der Zustellung erfolgen.
• Es darf nicht mehr als eine Abhol- oder Lieferalternative einer Sendung ausgeführt werden.
• für alle Routen werden die Zeiten verlängert (d. h., vehicleStartTime <= visits[0].start_time <= visits[1].start_time ... <= vehicleEndTime).
• Ein Versand darf nur mit einem zulässigen Fahrzeug durchgeführt werden. Ein Fahrzeug ist zulässig, wenn Shipment.allowed_vehicle_indices leer ist oder vehicleIndex in Shipment.allowed_vehicle_indices enthalten ist.

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.

object (InjectedSolutionConstraint)

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.

object (ShipmentRoute)

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. Damit ist das Modell nicht gelöst.

Seit dem 11. Dezember 2020 werden damit nur Polylinien nicht leerer Routen gefüllt und populatePolylines muss 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 in allen nicht leeren Routen eingefügt, unabhängig davon, ob die zugehörigen Sendungen oder Fahrzeuge ignoriert werden.

boolean

Wenn wahr:

• 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 zu einem neuen ShipmentRoute.vehicle_index wird wiederverwendet, um ConstraintRelaxation.vehicle_indices zu aktualisieren, falls das Feld nicht leer ist. Die Zuordnung muss jedoch eindeutig sein (d. h. mehrere ShipmentRoutes dürfen nicht dasselbe ursprüngliche vehicleIndex verwenden).
• verwendet ShipmentRoute.Visit.shipment_label anstelle von shipmentIndex, um Besuche in einer injizierten Lösung mit Sendungen in der Anfrage abzugleichen.
• verwendet SkippedShipment.label anstelle von SkippedShipment.index, um übersprungene Sendungen in der injizierten Lösung mit Sendungen abzugleichen.

Diese Interpretation gilt für die Felder injectedFirstSolutionRoutes, injectedSolutionConstraint und refreshDetailsRoutes. 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 hinzugefügt wurden.

Wenn diese Option aktiviert ist, 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 eingeschleusten Lösung (außer bei Abhol-/Lieferterminen, deren shipmentLabel zweimal vorkommen muss)

Wenn ein vehicleLabel in der eingespritzten Lösung keinem Anfragefahrzeug entspricht, wird die entsprechende Route zusammen mit ihren Besuchen aus der Lösung entfernt. Wenn ein shipmentLabel in der injizierten Lösung nicht mit einer Versandanfrage übereinstimmt, wird der entsprechende Besuch aus der Lösung entfernt. Wenn eine SkippedShipment.label in der injizierten Lösung nicht mit einer Versandanfrage übereinstimmt, wird die SkippedShipment aus der Lösung entfernt.

Wenn Sie Routenbesuche oder ganze Routen aus einer eingespritzten Lösung entfernen, kann sich das auf die impliziten Einschränkungen auswirken. Dies kann zu Änderungen an der Lösung, Validierungsfehlern oder Undurchführbarkeit führen.

HINWEIS: Der Aufrufer muss dafür sorgen, dass jede Vehicle.label (bzw. Shipment.label) identifiziert eindeutig ein Fahrzeug- bzw. Versandelement, das in den beiden relevanten Anfragen verwendet wird: die vorherige Anfrage, die die in der eingespritzten Lösung verwendete OptimizeToursResponse generiert hat, und die aktuelle Anfrage, die die eingespritzte Lösung enthält. Die oben beschriebenen Prüfungen auf Eindeutigkeit reichen nicht aus, um diese Anforderung zu garantieren.

boolean

Berücksichtigen Sie die Besucherzahlschätzung bei der Berechnung der ShipmentRoute-Felder 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

Falls wahr, werden Polylinien in Antwort-ShipmentRoutes ausgefüllt.

boolean

Falls wahr, werden Polylinien und Routentokens in der Antwort ShipmentRoute.transitions ausgefüllt.

boolean

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.

boolean

Falls wahr, werden die Entfernungen anhand von geodätischen Entfernungen und nicht anhand von Entfernungen aus Google Maps berechnet. Die Reisezeiten werden anhand von geodätischen Entfernungen berechnet, wobei die Geschwindigkeit durch geodesicMetersPerSecond definiert wird.

string

Label, das verwendet werden kann, um diese Anfrage zu identifizieren, die in der OptimizeToursResponse.request_label gemeldet wird.

number

Wenn useGeodesicDistances auf „wahr“ gesetzt ist, muss dieses Feld festgelegt werden. Es definiert die Geschwindigkeit, die für die Berechnung der Fahrtzeiten verwendet wird. Der Wert muss mindestens 1,0 Meter/Sekunden betragen.

integer

Die Anzahl der zurückgegebenen Validierungsfehler wird gekürzt. 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, solutionsMode=VALIDATE_ONLY: Siehe Feld OptimizeToursResponse.validation_errors. Der Standardwert ist 100 und ist auf 10.000 begrenzt.