Method: projects.optimizeTours

string (Duration format)

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 (falls möglich) eine Lösung, bevor das Zeitlimit abgelaufen ist.

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)

Suchmodus, der zum Lösen der Anfrage verwendet wird.

object (ShipmentRoute)

Den Optimierungsalgorithmus bei der Suche nach einer ersten Lösung unterstützen, die einer früheren Lösung ähnelt.

Das Modell wird beim Erstellen der ersten Lösung eingeschränkt. Alle Lieferungen, die nicht auf einer Route durchgeführt werden, werden in der ersten Lösung implizit übersprungen, können jedoch in aufeinanderfolgenden Lösungen durchgefü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.
• Eine Sendung darf nur auf einer Route referenziert werden.
• die Abholung einer Lieferung zur Abholung und Lieferung muss vor der Lieferung erfolgen.
• Es kann nur eine Abhol- oder Lieferalternative für eine Sendung ausgewählt 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 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.

object (InjectedSolutionConstraint)

Schränken Sie den Optimierungsalgorithmus ein, um eine endgültige Lösung zu finden, die einer vorherigen Lösung ähnelt. So können Sie beispielsweise Teile von Routen sperren, die bereits abgeschlossen sind oder noch abgeschlossen werden sollen, aber nicht geändert werden dürfen.

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.

object (ShipmentRoute)

Wenn die Liste nicht leer ist, werden die angegebenen Routen aktualisiert, ohne dass die zugrunde liegende Abfolge der Besuche oder Fahrtzeiten geändert wird. Nur andere Details werden aktualisiert. Das Modell wird dadurch nicht gelöst.

Seit dem 11. Dezember 2020 werden damit nur Polylinien nicht leerer Routen gefü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 zwischen allen Besuchen auf allen nicht leeren Routen immer noch ausgefüllt, unabhängig davon, ob die zugehörigen Sendungen oder Fahrzeuge ignoriert werden.

boolean

Falls wahr:

• verwendet ShipmentRoute.vehicle_label anstelle von vehicleIndex, um Routen in einer eingefügten Lösung mit Fahrzeugen in der Anfrage abzugleichen. Verwendet die Zuordnung des ursprünglichen ShipmentRoute.vehicle_index zum neuen ShipmentRoute.vehicle_index, um ConstraintRelaxation.vehicle_indices zu aktualisieren, falls dieses Feld nicht leer ist. Die Zuordnung muss jedoch eindeutig sein (d. h. mehrere ShipmentRoutes dürfen nicht dasselbe ursprüngliche vehicleIndex verwenden).
• ShipmentRoute.Visit.shipment_label anstelle von shipmentIndex verwendet, um Besuche in einer eingeschleusten 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 injizierten Lösung (außer Paare von Abhol- und Lieferbesuchen, bei denen shipmentLabel zweimal vorkommen muss).

Wenn eine vehicleLabel in der injizierten Lösung keinem Anfragefahrzeug entspricht, wird die entsprechende Route zusammen mit den zugehörigen Besuchen aus der Lösung entfernt. Wenn ein shipmentLabel in der eingespritzten Lösung nicht einer Anfragesendung entspricht, 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.

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 Vehicle.label (bzw. Shipment.label identifiziert eindeutig eine Fahrzeugentität (bzw. den Versandstatus), die für die beiden relevanten Anfragen verwendet wird: die letzte Anfrage, die die in der eingeschleusten Lösung verwendete OptimizeToursResponse generiert hat, und die aktuelle Anfrage, die die injizierte Lösung enthält. Die oben beschriebenen Eindeutigkeitsprüfungen reichen nicht aus, um diese Anforderung zu erfüllen.

boolean

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

boolean

Wenn „true“ festgelegt ist, werden Polylinien in Antwort-ShipmentRoutes eingefügt.

boolean

Wenn „wahr“ festgelegt ist, werden Polylinien und Routen-Tokens in Antwort ShipmentRoute.transitions eingefügt.

boolean

Wenn diese Option 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 langlebigen Anfragen das Risiko einer Unterbrechung deutlich höher (aber immer noch gering) ist.

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, deren 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/Sekunde betragen.

integer

Die Anzahl der zurückgegebenen Validierungsfehler wird gekürzt. Diese Fehler werden in der Regel als BadRequest-Fehlerdetails (https://cloud.google.com/apis/design/errors#error_details) an eine INVALID_ARGUMENT-Fehlernutzlast angehängt, es sei denn, solvingMode=VALIDATE_ONLY (siehe Feld OptimizeToursResponse.validation_errors). Der Standardwert ist 100 und ist auf 10.000 begrenzt.