Method: projects.locations.optimizeTours

string (Duration format)

Si ce délai est défini, le serveur renvoie une réponse avant l'expiration du délai ou avant que le délai du serveur pour les requêtes synchrones soit atteint, la première échéance étant retenue.

Pour les requêtes asynchrones, le serveur génère une solution (si possible) avant l'expiration du délai avant expiration.

Durée en secondes avec neuf chiffres au maximum après la virgule et se terminant par "s". Exemple : "3.5s"

object (ShipmentModel)

Modèle de livraison à résoudre.

enum (SolvingMode)

Par défaut, le mode de résolution est DEFAULT_SOLVE (0).

enum (SearchMode)

Mode de recherche utilisé pour résoudre la requête.

object (ShipmentRoute)

Guidez l'algorithme d'optimisation pour qu'il trouve une première solution semblable à une solution précédente.

Le modèle est soumis à des contraintes lors de la création de la première solution. Toutes les expéditions qui ne sont pas effectuées sur un itinéraire sont implicitement ignorées dans la première solution, mais peuvent l'être dans des solutions successives.

La solution doit répondre à certaines hypothèses de validité de base :

• Pour toutes les routes, vehicleIndex doit être à portée et ne doit pas être dupliqué.
• pour l'ensemble des visites, shipmentIndex et visitRequestIndex doivent être compris dans la plage.
• une expédition ne peut être référencée que sur un seul itinéraire.
• Le retrait d'un colis avec retrait et livraison doit être effectué avant la livraison.
• vous ne pouvez pas proposer plusieurs options de retrait ou de livraison pour une expédition.
• Pour tous les itinéraires, les horaires augmentent vehicleStartTime <= visits[0].start_time <= visits[1].start_time ... <= vehicleEndTime).
• une livraison ne peut être effectuée que sur un véhicule autorisé. Un véhicule est autorisé si Shipment.allowed_vehicle_indices est vide ou si son vehicleIndex est inclus dans Shipment.allowed_vehicle_indices.
• Si vous définissez avoidUTurns sur "true", injectedSolutionLocationToken doit être défini pour les visites pertinentes.

Si la solution injectée n'est pas réalisable, une erreur de validation n'est pas nécessairement renvoyée. Une erreur indiquant l'impossibilité de la solution peut être renvoyée à la place.

object (InjectedSolutionConstraint)

Contraignez l'algorithme d'optimisation à trouver une solution finale semblable à une solution précédente. Par exemple, vous pouvez les utiliser pour figer des portions de routes déjà terminées ou qui doivent l'être, mais qui ne doivent pas être modifiées.

Si la solution injectée n'est pas réalisable, une erreur de validation n'est pas nécessairement renvoyée. À la place, une erreur indiquant une irrégularité peut être renvoyée.

object (ShipmentRoute)

Si ce champ n'est pas renseigné, les itinéraires indiqués sont actualisés, sans modifier la séquence sous-jacente de visites ou de temps de trajet. Seuls les autres détails sont mis à jour. Cela ne résout pas le modèle.

Depuis 2020/11, seules les polylignes d'itinéraires non vides sont remplies et populatePolylines doit être défini sur "true".

Les champs routePolyline des itinéraires transmis peuvent ne pas correspondre à l'itinéraire transitions.

Ce champ ne doit pas être utilisé avec injectedFirstSolutionRoutes ou injectedSolutionConstraint.

Shipment.ignore et Vehicle.ignore n'ont aucun effet sur le comportement. Les polylignes sont toujours renseignées entre toutes les visites pour tous les itinéraires non vides, que les livraisons ou les véhicules associés soient ignorés ou non.

boolean

Si la condition est vraie :

• utilise ShipmentRoute.vehicle_label au lieu de vehicleIndex pour faire correspondre les itinéraires d'une solution injectée aux véhicules de la requête ; réutilise le mappage de l'ShipmentRoute.vehicle_index d'origine vers le nouvel ShipmentRoute.vehicle_index pour mettre à jour ConstraintRelaxation.vehicle_indices s'il n'est pas vide, mais le mappage doit être sans ambiguïté (c'est-à-dire que plusieurs ShipmentRoute ne doivent pas partager le même vehicleIndex d'origine).
• utilise ShipmentRoute.Visit.shipment_label au lieu de shipmentIndex pour mettre en correspondance les visites dans une solution injectée et les livraisons dans la requête ;
• utilise SkippedShipment.label au lieu de SkippedShipment.index pour faire correspondre les envois ignorés dans la solution injectée avec les envois de requête.

Cette interprétation s'applique aux champs injectedFirstSolutionRoutes, injectedSolutionConstraint et refreshDetailsRoutes. Vous pouvez l'utiliser lorsque les index des expéditions ou des véhicules de la requête ont changé depuis la création de la solution (par exemple, lorsque des expéditions ou des véhicules ont été supprimés ou ajoutés à la requête).

Si la valeur est "true", les libellés des catégories suivantes ne doivent apparaître qu'une seule fois dans leur catégorie :

• Vehicle.label dans la requête ;
• Shipment.label dans la requête ;
• ShipmentRoute.vehicle_label dans la solution injectée ;
• SkippedShipment.label et ShipmentRoute.Visit.shipment_label dans la solution injectée (à l'exception des paires de visites de retrait/livraison, dont shipmentLabel doit apparaître deux fois).

Si un vehicleLabel de la solution injectée ne correspond pas à un véhicule de la requête, le parcours correspondant est supprimé de la solution, ainsi que ses visites. Si un shipmentLabel dans la solution injectée ne correspond pas à une demande d'envoi, la visite correspondante est supprimée de la solution. Si un SkippedShipment.label de la solution injectée ne correspond pas à un envoi de requête, il est supprimé de la solution.

Supprimer des visites ou des itinéraires entiers d'une solution injectée peut avoir un effet sur les contraintes implicites, ce qui peut entraîner un changement de la solution, des erreurs de validation ou une impossibilité.

REMARQUE : L'appelant doit s'assurer que chaque Vehicle.label (resp. Shipment.label) identifie de manière unique une entité de véhicule (resp. d'envoi) utilisée dans les deux requêtes pertinentes : la requête précédente qui a généré le OptimizeToursResponse utilisé dans la solution injectée et la requête actuelle qui inclut la solution injectée. Les vérifications de l'unicité décrites ci-dessus ne suffisent pas à garantir cette exigence.

boolean

Tenez compte de l'estimation du trafic lors du calcul des champs ShipmentRoute Transition.travel_duration, Visit.start_time et vehicleEndTime, lors de la configuration du champ ShipmentRoute.has_traffic_infeasibilities et lors du calcul du champ OptimizeToursResponse.total_cost.

boolean

Si la valeur est "true", les polylignes sont renseignées dans les réponses ShipmentRoute.

boolean

Si la valeur est "true", les polylignes sont renseignées dans la réponse ShipmentRoute.transitions.

boolean

Si cet attribut est défini, la requête peut avoir un délai (voir https://grpc.io/blog/deadlines) de 60 minutes maximum. Sinon, le délai maximal n'est que de 30 minutes. Notez que les requêtes de longue durée présentent un risque d'interruption beaucoup plus élevé (mais toujours faible).

boolean

Si la valeur est "true", les distances de trajet seront calculées à l'aide de distances géodésiques au lieu de distances Google Maps, et les temps de trajet seront calculés à l'aide de distances géodésiques avec une vitesse définie par geodesicMetersPerSecond.

string

Libellé pouvant être utilisé pour identifier cette requête, indiqué dans OptimizeToursResponse.request_label.

number

Lorsque useGeodesicDistances est défini sur "true", ce champ doit être défini et définit la vitesse appliquée pour calculer les temps de trajet. Sa valeur doit être d'au moins 1,0 m/s.

integer

Tronque le nombre d'erreurs de validation renvoyées. Ces erreurs sont généralement associées à une charge utile d'erreur INVALID_ARGUMENT en tant que détails de l'erreur BadRequest (https://cloud.google.com/apis/design/errors#error_details), sauf si RésolutionMode=VALIDATE_ONLY: consultez le champ OptimizeToursResponse.validation_errors. La valeur par défaut est 100,mais elle est limitée à 10 000.