Method: projects.locations.optimizeTours

string (Duration format)

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

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

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 d'expédition à résoudre.

enum (SolvingMode)

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

enum (SearchMode)

Mode Recherche utilisé pour répondre à 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 contraint lorsque la première solution est créée. Les livraisons non effectuées sur un itinéraire sont implicitement ignorées dans la première solution, mais elles peuvent être effectuées dans les solutions suivantes.

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

• Pour tous les itinéraires, vehicleIndex doit être dans la plage et ne pas être dupliqué.
• Pour toutes les visites, shipmentIndex et visitRequestIndex doivent être dans la plage.
• Une expédition ne peut être référencée que sur un seul itinéraire.
• La prise en charge d'un colis à récupérer et à livrer doit être effectuée avant la livraison.
• Il ne peut y avoir qu'une seule alternative de retrait ou de livraison pour un envoi.
• pour toutes les routes, les temps augmentent (c'est-à-dire vehicleStartTime <= visits[0].start_time <= visits[1].start_time ... <= vehicleEndTime).
• Une expédition 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 la solution injectée n'est pas réalisable, une erreur de validation n'est pas nécessairement renvoyée. Une erreur indiquant l'irréalisabilité peut être renvoyée à la place.

object (InjectedSolutionConstraint)

Limitez l'algorithme d'optimisation pour trouver une solution finale semblable à une solution précédente. Par exemple, cela peut être utilisé pour figer des portions d'itinéraires déjà effectuées ou à effectuer, 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. Une erreur indiquant l'irréalisabilité peut être renvoyée à la place.

object (ShipmentRoute)

Si elle n'est pas vide, les itinéraires indiqués seront actualisés, sans que leur séquence de visites ou leurs temps de trajet sous-jacents soient modifiés. Seuls les autres détails seront mis à jour. Cela ne résout pas le modèle.

Depuis le 11/2020, cela ne remplit que les polylignes des itinéraires non vides et nécessite que populatePolylines soit défini sur "true".

Les champs routePolyline des routes transmises peuvent être incohérents avec la route transitions.

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

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

boolean

Si la réponse est "True" :

• 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 ShipmentRoute.vehicle_index d'origine vers le nouveau ShipmentRoute.vehicle_index pour mettre à jour ConstraintRelaxation.vehicle_indices s'il n'est pas vide, mais le mappage doit être non ambigu (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 faire correspondre les visites dans une solution injectée avec les expéditions dans la demande ;
• utilise SkippedShipment.label au lieu de SkippedShipment.index pour faire correspondre les expéditions ignorées dans la solution injectée avec les expéditions de la demande.

Cette interprétation s'applique aux champs injectedFirstSolutionRoutes, injectedSolutionConstraint et refreshDetailsRoutes. Vous pouvez l'utiliser lorsque les index de véhicules ou d'expéditions de la requête ont changé depuis la création de la solution, par exemple parce que des expéditions ou des véhicules ont été ajoutés ou supprimés de 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 (sauf pour les paires de visites de retrait/livraison, dont shipmentLabel doit apparaître deux fois).

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

La suppression de visites ou d'itinéraires entiers d'une solution injectée peut avoir une incidence sur les contraintes implicites, ce qui peut entraîner une modification de la solution, des erreurs de validation ou une infaisabilité.

REMARQUE : L'appelant doit s'assurer que chaque Vehicle.label (resp. Shipment.label) identifie de manière unique une entité de véhicule (ou d'expédition) utilisée dans les deux requêtes concernées : la requête passée qui a produit le OptimizeToursResponse utilisé dans la solution injectée et la requête actuelle qui inclut la solution injectée. Les vérifications d'unicité décrites ci-dessus ne suffisent pas à garantir cette exigence.

boolean

Tenez compte de l'estimation du trafic pour calculer les champs ShipmentRoute Transition.travel_duration, Visit.start_time et vehicleEndTime, pour définir le champ ShipmentRoute.has_traffic_infeasibilities et pour calculer le champ OptimizeToursResponse.total_cost.

boolean

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

boolean

Si la valeur est "true", les polylignes et les jetons de route seront renseignés dans la réponse ShipmentRoute.transitions.

boolean

Si cette valeur est définie, la requête peut avoir un délai (voir https://grpc.io/blog/deadlines) allant jusqu'à 60 minutes. Sinon, le délai maximal est 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, renvoyé dans OptimizeToursResponse.request_label.

number

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

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 qu'information détaillée sur l'erreur BadRequest (https://cloud.google.com/apis/design/errors#error_details), sauf si solvingMode=VALIDATE_ONLY : consultez le champ OptimizeToursResponse.validation_errors. La valeur par défaut est de 100 et la limite est de 10 000.