Index
RouteOptimization(interface)AggregatedMetrics(message)BatchOptimizeToursMetadata(message)BatchOptimizeToursRequest(message)BatchOptimizeToursRequest.AsyncModelConfig(message)BatchOptimizeToursResponse(message)BreakRule(message)BreakRule.BreakRequest(message)BreakRule.FrequencyConstraint(message)DataFormat(enum)DistanceLimit(message)GcsDestination(message)GcsSource(message)InjectedSolutionConstraint(message)InjectedSolutionConstraint.ConstraintRelaxation(message)InjectedSolutionConstraint.ConstraintRelaxation.Relaxation(message)InjectedSolutionConstraint.ConstraintRelaxation.Relaxation.Level(enum)InputConfig(message)Location(message)OptimizeToursLongRunningMetadata(message)OptimizeToursRequest(message)OptimizeToursRequest.SearchMode(enum)OptimizeToursRequest.SolvingMode(enum)OptimizeToursResponse(message)OptimizeToursResponse.Metrics(message)OptimizeToursUriMetadata(message)OptimizeToursUriRequest(message)OptimizeToursUriResponse(message)OptimizeToursValidationError(message)OptimizeToursValidationError.FieldReference(message)OutputConfig(message)RouteModifiers(message)Shipment(message)Shipment.Load(message)Shipment.VisitRequest(message)ShipmentModel(message)ShipmentModel.DurationDistanceMatrix(message)ShipmentModel.DurationDistanceMatrix.Row(message)ShipmentModel.Objective(message)ShipmentModel.Objective.Type(enum)ShipmentModel.PrecedenceRule(message)ShipmentRoute(message)ShipmentRoute.Break(message)ShipmentRoute.EncodedPolyline(message)ShipmentRoute.Transition(message)ShipmentRoute.VehicleLoad(message)ShipmentRoute.Visit(message)ShipmentTypeIncompatibility(message)ShipmentTypeIncompatibility.IncompatibilityMode(enum)ShipmentTypeRequirement(message)ShipmentTypeRequirement.RequirementMode(enum)SkippedShipment(message)SkippedShipment.Reason(message)SkippedShipment.Reason.Code(enum)TimeWindow(message)TransitionAttributes(message)Uri(message)Vehicle(message)Vehicle.DurationLimit(message)Vehicle.LoadLimit(message)Vehicle.LoadLimit.Interval(message)Vehicle.LoadLimit.LoadCost(message)Vehicle.TravelMode(enum)Vehicle.UnloadingPolicy(enum)VehicleFullness(message)Waypoint(message)
RouteOptimization
Service permettant d'optimiser les tournées de véhicules.
Validité de certains types de champs :
google.protobuf.Timestamp- Les heures sont exprimées en heure Unix : secondes écoulées depuis le 1er janvier 1970 à 00:00:00+00:00.
- Les secondes doivent être comprises entre 0 et 253402300799, c'est-à-dire entre 1970-01-01T00:00:00+00:00 et 9999-12-31T23:59:59+00:00.
- Les nano-unités doivent être non définies ou définies sur 0.
google.protobuf.Duration- Les secondes doivent être comprises entre 0 et 253402300799, c'est-à-dire entre 1970-01-01T00:00:00+00:00 et 9999-12-31T23:59:59+00:00.
- Les nano-unités doivent être non définies ou définies sur 0.
google.type.LatLng- La latitude doit être comprise entre -90,0 et 90,0.
- La longitude doit être comprise entre -180,0 et 180,0.
- au moins l'une des valeurs de latitude et de longitude doit être non nulle.
| BatchOptimizeTours |
|---|
|
Optimise les tournées de véhicules pour un ou plusieurs messages Cette méthode est une opération de longue durée (LRO). Les entrées (messages L'utilisateur peut interroger Si le champ Si le champ
|
| OptimizeTours |
|---|
|
Envoie un Un modèle L'objectif est d'attribuer des
|
| OptimizeToursLongRunning |
|---|
|
Il s'agit d'une variante de la méthode Le Expérimental : pour en savoir plus, consultez https://developers.google.com/maps/tt/route-optimization/experimental/otlr/make-request.
|
| OptimizeToursUri |
|---|
|
Il s'agit d'une variante de la méthode Le client spécifie l'URI de Cette méthode doit être privilégiée par rapport à la méthode Le Expérimental : pour en savoir plus, consultez https://developers.google.com/maps/tt/route-optimization/experimental/otlr/make-request.
|
AggregatedMetrics
Métriques agrégées pour ShipmentRoute (ou pour OptimizeToursResponse sur tous les éléments Transition et/ou Visit (ou sur tous les éléments ShipmentRoute)).
| Champs | |
|---|---|
performed_shipment_count |
Nombre d'expéditions effectuées. Notez qu'une paire retrait et livraison n'est comptabilisée qu'une seule fois. |
travel_duration |
Durée totale du trajet pour un itinéraire ou une solution. |
wait_duration |
Durée d'attente totale pour un itinéraire ou une solution. |
delay_duration |
Durée totale du retard pour un itinéraire ou une solution. |
break_duration |
Durée totale de la pause pour un itinéraire ou une solution. |
visit_duration |
Durée totale de la visite pour un itinéraire ou une solution. |
total_duration |
La durée totale doit être égale à la somme de toutes les durées ci-dessus. Pour les itinéraires, cela correspond également à : |
travel_distance_meters |
Distance totale parcourue pour un itinéraire ou une solution. |
max_loads |
Charge maximale atteinte sur l'ensemble de l'itinéraire (ou de la solution), pour chacune des quantités de cet itinéraire (ou de cette solution), calculée comme le maximum sur tous les |
performed_mandatory_shipment_count |
Nombre d'expéditions obligatoires effectuées. Expérimental : le comportement ou l'existence de ce champ peuvent changer à l'avenir. |
performed_shipment_penalty_cost_sum |
Somme des Expérimental : le comportement ou l'existence de ce champ peuvent changer à l'avenir. |
BatchOptimizeToursMetadata
Ce type ne comporte aucun champ.
Métadonnées de l'opération pour les appels BatchOptimizeToursRequest.
BatchOptimizeToursRequest
Demande d'optimisation par lot des circuits en tant qu'opération asynchrone. Chaque fichier d'entrée doit contenir un OptimizeToursRequest, et chaque fichier de sortie doit contenir un OptimizeToursResponse. La requête contient des informations permettant de lire, d'écrire et d'analyser les fichiers. Tous les fichiers d'entrée et de sortie doivent se trouver dans le même projet.
| Champs | |
|---|---|
parent |
Obligatoire. Projet et emplacement cibles pour passer un appel. Format :
Si aucun emplacement n'est spécifié, une région est automatiquement sélectionnée. |
model_configs[] |
Obligatoire. Informations sur les entrées/sorties pour chaque modèle d'achat, telles que les chemins d'accès aux fichiers et les formats de données. |
AsyncModelConfig
Informations permettant de résoudre un modèle d'optimisation de manière asynchrone.
| Champs | |
|---|---|
display_name |
Facultatif. Nom de modèle défini par l'utilisateur. Les utilisateurs peuvent l'utiliser comme alias pour suivre les modèles. |
input_config |
Obligatoire. Informations sur le modèle d'entrée. |
output_config |
Obligatoire. Informations sur l'emplacement de sortie souhaité. |
BatchOptimizeToursResponse
Ce type ne comporte aucun champ.
Réponse à un BatchOptimizeToursRequest. Cette valeur est renvoyée dans l'opération de longue durée une fois l'opération terminée.
BreakRule
Règles permettant de générer des pauses pour un véhicule (par exemple, des pauses déjeuner). Une pause est une période continue pendant laquelle le véhicule reste à l'arrêt à sa position actuelle et ne peut effectuer aucune visite. Une pause peut se produire :
- pendant le trajet entre deux visites (y compris juste avant ou juste après une visite, mais pas au milieu d'une visite), auquel cas il prolonge le temps de trajet correspondant entre les visites.
- ou avant le démarrage du véhicule (le véhicule peut ne pas démarrer au milieu d'une pause), auquel cas cela n'affecte pas l'heure de démarrage du véhicule.
- ou après la fin de la période de location du véhicule (idem, avec l'heure de fin de la période de location du véhicule).
| Champs | |
|---|---|
break_requests[] |
Séquence de pauses. Consultez le message |
frequency_constraints[] |
Plusieurs |
BreakRequest
La séquence de pauses (c'est-à-dire leur nombre et leur ordre) qui s'applique à chaque véhicule doit être connue à l'avance. Les BreakRequest répétés définissent cette séquence, dans l'ordre dans lequel ils doivent se produire. Leurs plages horaires (earliest_start_time / latest_start_time) peuvent se chevaucher, mais elles doivent être compatibles avec l'ordre (cette compatibilité est vérifiée).
| Champs | |
|---|---|
earliest_start_time |
Obligatoire. Limite inférieure (incluse) du début de la pause. |
latest_start_time |
Obligatoire. Limite supérieure (incluse) du début de la pause. |
min_duration |
Obligatoire. Durée minimale de la pause. Doit être positive. |
FrequencyConstraint
Il est possible de limiter davantage la fréquence et la durée des pauses spécifiées ci-dessus en imposant une fréquence de pause minimale, par exemple "Il doit y avoir une pause d'au moins une heure toutes les 12 heures". En partant du principe que cela peut être interprété comme "Dans n'importe quelle fenêtre temporelle glissante de 12 heures, il doit y avoir au moins une pause d'au moins une heure", cet exemple se traduirait par le FrequencyConstraint suivant :
{
min_break_duration { seconds: 3600 } # 1 hour.
max_inter_break_duration { seconds: 39600 } # 11 hours (12 - 1 = 11).
}
La durée et le moment des pauses dans la solution respecteront toutes ces contraintes, en plus des créneaux horaires et des durées minimales déjà spécifiés dans BreakRequest.
En pratique, un FrequencyConstraint peut s'appliquer à des pauses non consécutives. Par exemple, la planification suivante respecte l'exemple "1h toutes les 12h" :
04:00 vehicle start
.. performing travel and visits ..
09:00 1 hour break
10:00 end of the break
.. performing travel and visits ..
12:00 20-min lunch break
12:20 end of the break
.. performing travel and visits ..
21:00 1 hour break
22:00 end of the break
.. performing travel and visits ..
23:59 vehicle end
| Champs | |
|---|---|
min_break_duration |
Obligatoire. Durée minimale de la pause pour cette contrainte. Non négatif. Lisez la description de |
max_inter_break_duration |
Obligatoire. Durée maximale autorisée pour tout intervalle de temps de l'itinéraire qui n'inclut pas au moins partiellement une pause de |
DataFormat
Formats de données pour les fichiers d'entrée et de sortie.
| Enums | |
|---|---|
DATA_FORMAT_UNSPECIFIED |
Valeur non valide. Le format ne doit pas être "UNSPECIFIED". |
JSON |
JavaScript Object Notation. |
PROTO_TEXT |
Format texte Protocol Buffers. Consultez https://protobuf.dev/reference/protobuf/textformat-spec/. |
DistanceLimit
Limite définissant une distance maximale pouvant être parcourue. Il peut s'agir d'une erreur bloquante ou non bloquante.
Si une limite flexible est définie, soft_max_meters et cost_per_kilometer_above_soft_max doivent être définis et non négatifs.
| Champs | |
|---|---|
max_meters |
Limite stricte qui contraint la distance à être au maximum égale à max_meters. La limite ne doit pas être négative. |
soft_max_meters |
Il s'agit d'une limite flexible qui n'impose pas de distance maximale, mais qui, en cas de non-respect, entraîne un coût qui s'ajoute aux autres coûts définis dans le modèle, avec la même unité. Si soft_max_meters est défini, il doit être inférieur à max_meters et non négatif. |
cost_per_kilometer_below_soft_max |
Le coût par kilomètre encouru, qui peut atteindre Ce coût n'est pas accepté dans |
cost_per_kilometer_above_soft_max |
Coût par kilomètre encouru si la distance dépasse la limite de Le coût ne doit pas être négatif. |
GcsDestination
Emplacement Google Cloud Storage sur lequel le ou les fichiers de sortie seront écrits.
| Champs | |
|---|---|
uri |
Obligatoire. URI Google Cloud Storage. |
GcsSource
Emplacement Google Cloud Storage à partir duquel le fichier d'entrée sera lu.
| Champs | |
|---|---|
uri |
Obligatoire. URI d'un objet Google Cloud Storage au format |
InjectedSolutionConstraint
Solution injectée dans la requête, y compris des informations sur les visites qui doivent être contraintes et sur la manière dont elles doivent l'être.
| Champs | |
|---|---|
routes[] |
Routes de la solution à injecter. Il est possible que certains itinéraires soient omis de la solution d'origine. Les itinéraires et les livraisons ignorées doivent respecter les hypothèses de validité de base listées pour |
skipped_shipments[] |
Livraisons ignorées de la solution à injecter. Il est possible que certains soient omis de la solution d'origine. Consultez le champ |
constraint_relaxations[] |
Pour zéro ou plusieurs groupes de véhicules, spécifie quand et dans quelle mesure assouplir les contraintes. Si ce champ est vide, toutes les routes de véhicules non vides sont entièrement contraintes. |
ConstraintRelaxation
Pour un groupe de véhicules, spécifie à quel seuil les contraintes sur les visites seront assouplies et à quel niveau. Les livraisons listées dans le champ skipped_shipment sont contraintes d'être ignorées, c'est-à-dire qu'elles ne peuvent pas être effectuées.
| Champs | |
|---|---|
relaxations[] |
Toutes les assouplissements de contraintes de visite qui s'appliqueront aux visites sur les itinéraires avec des véhicules dans |
vehicle_indices[] |
Spécifie les indices de véhicules auxquels s'applique la contrainte de visite Un index de véhicule est mappé de la même manière que |
Relaxation
Si relaxations est vide, l'heure de début et la séquence de toutes les visites sur routes sont entièrement contraintes, et aucune nouvelle visite ne peut être insérée ni ajoutée à ces itinéraires. De plus, l'heure de début et de fin d'un véhicule dans routes est entièrement contrainte, sauf si le véhicule est vide (c'est-à-dire qu'il n'a pas de visites et que used_if_route_is_empty est défini sur "false" dans le modèle).
relaxations(i).level spécifie le niveau de relâchement des contraintes appliqué à une visite #j qui satisfait à la condition suivante :
route.visits(j).start_time >= relaxations(i).threshold_timeETj + 1 >= relaxations(i).threshold_visit_count
De même, le démarrage du véhicule est relâché à relaxations(i).level s'il satisfait à la condition suivante :
vehicle_start_time >= relaxations(i).threshold_timeETrelaxations(i).threshold_visit_count == 0et la fin du véhicule est relâchée àrelaxations(i).levelsi elle satisfait :vehicle_end_time >= relaxations(i).threshold_timeETroute.visits_size() + 1 >= relaxations(i).threshold_visit_count
Pour appliquer un niveau de tolérance si une visite répond à threshold_visit_count OU à threshold_time, ajoutez deux relaxations avec le même level : l'un avec threshold_visit_count uniquement et l'autre avec threshold_time uniquement. Si une visite remplit les conditions de plusieurs relaxations, le niveau le moins restrictif s'applique. Par conséquent, du début du véhicule à la fin du véhicule en passant par les visites d'itinéraire dans l'ordre, le niveau de relaxation devient plus souple : c'est-à-dire que le niveau de relaxation ne diminue pas au fur et à mesure que l'itinéraire progresse.
Le calendrier et la séquence des visites d'itinéraire qui ne satisfont pas aux conditions de seuil d'un relaxations sont entièrement contraints et aucune visite ne peut être insérée dans ces séquences. De plus, si le début ou la fin d'un véhicule ne répond à aucune condition de relaxation, l'heure est fixe, sauf si le véhicule est vide.
| Champs | |
|---|---|
level |
Niveau de relâchement des contraintes qui s'applique lorsque les conditions à |
threshold_time |
Heure à partir de laquelle l'assouplissement |
threshold_visit_count |
Nombre de visites à partir duquel la relaxation Si la valeur est |
Niveau
Exprime les différents niveaux de relaxation des contraintes, qui sont appliqués pour une visite et celles qui suivent lorsqu'elle satisfait aux conditions de seuil.
L'énumération ci-dessous est classée par ordre de relaxation croissante.
| Enums | |
|---|---|
LEVEL_UNSPECIFIED |
Niveau de relaxation par défaut implicite : aucune contrainte n'est relâchée, c'est-à-dire que toutes les visites sont entièrement contraintes. Cette valeur ne doit pas être utilisée explicitement dans |
RELAX_VISIT_TIMES_AFTER_THRESHOLD |
Les heures de début des visites et les heures de début/fin des véhicules seront plus flexibles, mais chaque visite restera associée au même véhicule et l'ordre des visites devra être respecté : aucune visite ne pourra être insérée entre elles ni avant elles. |
RELAX_VISIT_TIMES_AND_SEQUENCE_AFTER_THRESHOLD |
Identique à RELAX_VISIT_TIMES_AFTER_THRESHOLD, mais la séquence de visites est également assouplie : les visites ne peuvent être effectuées que par ce véhicule, mais peuvent potentiellement ne pas être effectuées. |
RELAX_ALL_AFTER_THRESHOLD |
Identique à RELAX_VISIT_TIMES_AND_SEQUENCE_AFTER_THRESHOLD, mais le véhicule est également détendu : les visites sont entièrement sans frais à partir du seuil de temps et peuvent potentiellement ne pas être effectuées. |
InputConfig
Spécifiez une entrée pour [BatchOptimizeTours][google.maps.routeoptimization.v1.RouteOptimizationService.BatchOptimizeTours].
| Champs | |
|---|---|
data_format |
Obligatoire. Format des données d'entrée. |
Champ d'union source. Obligatoire. source ne peut être qu'un des éléments suivants : |
|
gcs_source |
Emplacement Google Cloud Storage. Il doit s'agir d'un seul objet (fichier). |
Emplacement
Encapsule un emplacement (un point géographique et un cap facultatif).
| Champs | |
|---|---|
lat_lng |
Coordonnées géographiques du point de repère. |
heading |
Direction indiquée par la boussole et associée au sens du trafic. Cette valeur permet de spécifier le côté de la route à utiliser pour la prise en charge et la dépose. Les valeurs de cap peuvent être comprises entre 0 et 360, où 0 indique un cap plein nord, 90 un cap plein est, etc. |
OptimizeToursLongRunningMetadata
Ce type ne comporte aucun champ.
Métadonnées de l'opération pour les appels OptimizeToursLongRunning.
OptimizeToursRequest
Demande à envoyer à un solveur d'optimisation de tournées. Elle définit le modèle d'expédition à résoudre ainsi que les paramètres d'optimisation.
| Champs | |
|---|---|
parent |
Obligatoire. Projet ou emplacement cibles pour passer un appel. Format :
Si aucun emplacement n'est spécifié, une région est automatiquement sélectionnée. |
timeout |
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. |
model |
Modèle d'expédition à résoudre. |
solving_mode |
Par défaut, le mode de résolution est |
search_mode |
Mode Recherche utilisé pour répondre à la requête. |
injected_first_solution_routes[] |
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 :
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. |
injected_solution_constraint |
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. |
refresh_details_routes[] |
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 Les champs Ce champ ne doit pas être utilisé avec
|
interpret_injected_solutions_using_labels |
Si la réponse est "True" :
Cette interprétation s'applique aux champs Si la valeur est "true", les libellés des catégories suivantes ne doivent apparaître qu'une seule fois dans leur catégorie :
Si un 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 |
consider_road_traffic |
Tenez compte de l'estimation du trafic pour calculer les champs |
populate_polylines |
Si la valeur est "true", les polylignes seront renseignées dans les |
populate_transition_polylines |
Si la valeur est "true", les polylignes et les jetons de route seront renseignés dans la réponse |
allow_large_deadline_despite_interruption_risk |
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). |
use_geodesic_distances |
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 |
label |
Libellé pouvant être utilisé pour identifier cette requête, renvoyé dans |
geodesic_meters_per_second |
Lorsque |
max_validation_errors |
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étail d'erreur BadRequest (https://cloud.google.com/apis/design/errors#error_details), sauf si solving_mode=VALIDATE_ONLY : consultez le champ |
SearchMode
Mode définissant le comportement de la recherche, en faisant un compromis entre la latence et la qualité de la solution. Dans tous les modes, le délai de demande global est appliqué.
| Enums | |
|---|---|
SEARCH_MODE_UNSPECIFIED |
Mode de recherche non spécifié, équivalent à RETURN_FAST. |
RETURN_FAST |
Arrêtez la recherche après avoir trouvé la première bonne solution. |
CONSUME_ALL_AVAILABLE_TIME |
Consacrez tout le temps disponible à la recherche de meilleures solutions. |
SolvingMode
Définit la façon dont le solveur doit gérer la requête. Dans tous les modes, sauf VALIDATE_ONLY, si la requête n'est pas valide, vous recevrez une erreur INVALID_REQUEST. Consultez max_validation_errors pour limiter le nombre d'erreurs renvoyées.
| Enums | |
|---|---|
DEFAULT_SOLVE |
Résolvez le modèle. Des avertissements peuvent être émis dans [OptimizeToursResponse.validation_errors][google.cloud.optimization.v1.OptimizeToursResponse.validation_errors]. |
VALIDATE_ONLY |
Valide uniquement le modèle sans le résoudre : remplit autant de OptimizeToursResponse.validation_errors que possible. |
DETECT_SOME_INFEASIBLE_SHIPMENTS |
Ne remplit que IMPORTANT : Toutes les livraisons irréalisables ne sont pas renvoyées ici, mais uniquement celles qui sont détectées comme irréalisables lors du prétraitement. |
TRANSFORM_AND_RETURN_REQUEST |
Ce mode ne fonctionne que si Expérimental : pour en savoir plus, consultez https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request. |
OptimizeToursResponse
Réponse après résolution d'un problème d'optimisation de tournée contenant les itinéraires suivis par chaque véhicule, les expéditions qui ont été ignorées et le coût global de la solution.
| Champs | |
|---|---|
routes[] |
Itinéraires calculés pour chaque véhicule. Le i-ème itinéraire correspond au i-ème véhicule du modèle. |
request_label |
Copie de |
skipped_shipments[] |
Liste de tous les envois ignorés. |
validation_errors[] |
Liste de toutes les erreurs de validation que nous avons pu détecter de manière indépendante. Consultez l'explication "MULTIPLE ERRORS" (ERREURS MULTIPLES) pour le message |
processed_request |
Dans certains cas, nous modifions la demande entrante avant de la résoudre (par exemple, en ajoutant des coûts). Si solving_mode == TRANSFORM_AND_RETURN_REQUEST, la requête modifiée est renvoyée ici. Expérimental : pour en savoir plus, consultez https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request. |
metrics |
Métriques de durée, de distance et d'utilisation pour cette solution. |
Métriques
Métriques globales, agrégées sur toutes les routes.
| Champs | |
|---|---|
aggregated_route_metrics |
Agrégé sur les routes. Chaque métrique correspond à la somme (ou au maximum, pour les charges) de tous les champs |
skipped_mandatory_shipment_count |
Nombre d'expéditions obligatoires ignorées. |
used_vehicle_count |
Nombre de véhicules utilisés. Remarque : Si un itinéraire de véhicule est vide et que |
earliest_vehicle_start_time |
Heure de début la plus ancienne pour un véhicule d'occasion, calculée comme le minimum de |
latest_vehicle_end_time |
Heure de fin la plus tardive pour un véhicule d'occasion, calculée comme le maximum de |
costs |
Coût de la solution, réparti par champs de demande liés aux coûts. Les clés sont des chemins proto, relatifs à l'OptimizeToursRequest d'entrée, par exemple "model.shipments.pickups.cost", et les valeurs sont le coût total généré par le champ de coût correspondant, agrégé sur l'ensemble de la solution. En d'autres termes, costs["model.shipments.pickups.cost"] correspond à la somme de tous les coûts d'enlèvement de la solution. Tous les coûts définis dans le modèle sont détaillés ici, à l'exception de ceux liés aux TransitionAttributes, qui ne sont agrégés qu'à partir du 01/01/2022. |
total_cost |
Coût total de la solution. Somme de toutes les valeurs de la carte des coûts. |
OptimizeToursUriMetadata
Ce type ne comporte aucun champ.
Métadonnées de l'opération pour les appels OptimizeToursUri.
OptimizeToursUriRequest
Requête utilisée par la méthode OptimizeToursUri.
| Champs | |
|---|---|
parent |
Obligatoire. Projet ou emplacement cibles pour passer un appel. Format :
Si aucun emplacement n'est spécifié, une région est automatiquement sélectionnée. |
input |
Obligatoire. URI de l'objet Cloud Storage contenant le |
output |
Obligatoire. URI de l'objet Cloud Storage qui contiendra le |
OptimizeToursUriResponse
Réponse renvoyée par la méthode OptimizeToursUri.
| Champs | |
|---|---|
output |
Facultatif. URI de l'objet Cloud Storage contenant le Le |
OptimizeToursValidationError
Décrit une erreur ou un avertissement rencontré lors de la validation d'un OptimizeToursRequest.
| Champs | |
|---|---|
code |
Une erreur de validation est définie par la paire ( Les champs qui suivent cette section fournissent plus de contexte sur l'erreur. ERREURS MULTIPLES : lorsque plusieurs erreurs sont détectées, le processus de validation tente d'en afficher plusieurs. Comme un compilateur, ce processus n'est pas parfait. Certaines erreurs de validation sont "fatales", ce qui signifie qu'elles interrompent l'ensemble du processus de validation. C'est le cas, entre autres, des erreurs STABILITÉ : |
display_name |
Nom à afficher de l'erreur. |
fields[] |
Un contexte d'erreur peut impliquer 0, 1 (la plupart du temps) ou plusieurs champs. Par exemple, vous pouvez faire référence à la première collecte du véhicule 4 et de l'envoi 2 comme suit : Notez toutefois que la cardinalité de |
error_message |
Chaîne de texte décrivant l'erreur. Il existe un mappage un-à-un entre STABILITÉ : non stable. Le message d'erreur associé à un |
offending_values |
Peut contenir la ou les valeurs du ou des champs. Cette option n'est pas toujours disponible. Vous ne devez absolument pas vous y fier et ne l'utiliser que pour le débogage manuel des modèles. |
FieldReference
Spécifie un contexte pour l'erreur de validation. Un FieldReference fait toujours référence à un champ donné de ce fichier et suit la même structure hiérarchique. Par exemple, nous pouvons spécifier l'élément 2 de start_time_windows du véhicule 5 à l'aide de :
name: "vehicles" index: 5 sub_field { name: "end_time_windows" index: 2 }
Toutefois, nous omettons les entités de premier niveau telles que OptimizeToursRequest ou ShipmentModel pour éviter d'encombrer le message.
| Champs | |
|---|---|
name |
Nom du champ (par exemple, "vehicles". |
sub_field |
Sous-champ imbriqué de manière récursive, si nécessaire. |
Champ d'union
|
|
index |
Index du champ s'il est répété. |
key |
Clé si le champ est une carte. |
OutputConfig
Spécifiez une destination pour les résultats de [BatchOptimizeTours][google.maps.routeoptimization.v1.RouteOptimizationService.BatchOptimizeTours].
| Champs | |
|---|---|
data_format |
Obligatoire. Format des données de sortie. |
Champ d'union destination. Obligatoire. destination ne peut être qu'un des éléments suivants : |
|
gcs_destination |
Emplacement Google Cloud Storage dans lequel écrire la sortie. |
RouteModifiers
Encapsule un ensemble de conditions facultatives à respecter lors du calcul des itinéraires de véhicules. Cela ressemble à RouteModifiers dans l'API Routes Preferred de Google Maps Platform. Pour en savoir plus, consultez https://developers.google.com/maps/documentation/routes/reference/rest/v2/RouteModifiers.
| Champs | |
|---|---|
avoid_tolls |
Indique s'il faut éviter les routes à péage lorsque cela est raisonnable. La préférence sera accordée aux itinéraires ne comportant pas de routes à péage. Ne s'applique qu'aux modes de déplacement motorisés. |
avoid_highways |
Indique s'il faut éviter les autoroutes lorsque cela est raisonnable. La préférence sera accordée aux itinéraires ne contenant pas d'autoroutes. Ne s'applique qu'aux modes de déplacement motorisés. |
avoid_ferries |
Indique s'il faut éviter les ferries lorsque cela est raisonnable. La priorité sera donnée aux itinéraires qui n'incluent pas de traversée en ferry. Ne s'applique qu'aux modes de déplacement motorisés. |
avoid_indoor |
Facultatif. Indique s'il faut éviter la navigation en intérieur lorsque cela est raisonnable. La préférence sera accordée aux itinéraires ne contenant pas de navigation en intérieur. Ne s'applique qu'au mode de déplacement |
Livraison
Envoi d'un seul article, d'un point de collecte à un point de livraison. Pour qu'une livraison soit considérée comme effectuée, un véhicule unique doit se rendre à l'un de ses lieux de prise en charge (et réduire ses capacités disponibles en conséquence), puis à l'un de ses lieux de livraison (et donc augmenter à nouveau ses capacités disponibles en conséquence).
| Champs | |
|---|---|
display_name |
Nom à afficher de l'envoi défini par l'utilisateur. Il peut comporter jusqu'à 63 caractères et utiliser des caractères UTF-8. |
pickups[] |
Ensemble d'alternatives de retrait associées à l'envoi. Si aucune heure n'est spécifiée, le véhicule n'a besoin de se rendre qu'à un lieu correspondant aux livraisons. |
deliveries[] |
Ensemble d'alternatives de livraison associées à l'expédition. Si aucune heure n'est spécifiée, le véhicule n'a besoin de se rendre qu'à un lieu correspondant aux points de collecte. |
load_demands |
Les exigences de chargement de l'envoi (par exemple, le poids, le volume, le nombre de palettes, etc.). Les clés du mappage doivent être des identifiants décrivant le type de charge correspondant, idéalement en incluant également les unités. Par exemple : "weight_kg", "volume_gallons", "pallet_count", etc. Si une clé donnée n'apparaît pas dans la carte, la charge correspondante est considérée comme nulle. |
allowed_vehicle_indices[] |
Ensemble des véhicules pouvant effectuer cette livraison. Si ce champ est vide, tous les véhicules peuvent effectuer la tâche. Les véhicules sont indiqués par leur index dans la liste |
costs_per_vehicle[] |
Spécifie le coût encouru lorsque cette livraison est effectuée par chaque véhicule. Si elle est spécifiée, elle doit comporter l'UNE des options suivantes :
Ces coûts doivent être exprimés dans la même unité que |
costs_per_vehicle_indices[] |
Indices des véhicules auxquels |
pickup_to_delivery_absolute_detour_limit |
Spécifie le temps de détour maximal absolu par rapport au chemin le plus court entre le point de prise en charge et le point de livraison. Si elle est spécifiée, elle doit être non négative et l'expédition doit contenir au moins un enlèvement et une livraison. Par exemple, soit t le temps le plus court pour aller directement de l'alternative de retrait sélectionnée à l'alternative de livraison sélectionnée. Le paramètre Si des limites relatives et absolues sont spécifiées pour le même envoi, la limite la plus contraignante est utilisée pour chaque paire d'enlèvement/de livraison possible. Depuis le 10/2017, les détours ne sont acceptés que lorsque les durées de trajet ne dépendent pas des véhicules. |
pickup_to_delivery_time_limit |
Spécifie la durée maximale entre le début de l'enlèvement et le début de la livraison d'un colis. Si elle est spécifiée, elle doit être non négative et l'expédition doit contenir au moins un enlèvement et une livraison. Cela ne dépend pas des alternatives sélectionnées pour le retrait et la livraison, ni de la vitesse du véhicule. Cette contrainte peut être spécifiée en même temps que les contraintes de détour maximal : la solution respectera les deux spécifications. |
shipment_type |
Chaîne non vide spécifiant un "type" pour cet envoi. Cette fonctionnalité peut être utilisée pour définir des incompatibilités ou des exigences entre Diffère de |
label |
Spécifie un libellé pour cette expédition. Ce libellé est indiqué dans la réponse, dans le |
ignore |
Si la valeur est "true", ignorez cet envoi, mais n'appliquez pas de Si vous ignorez une expédition alors que le modèle contient des Il est possible d'ignorer une expédition effectuée dans |
penalty_cost |
Si l'expédition n'est pas effectuée, cette pénalité est ajoutée au coût global des itinéraires. Une livraison est considérée comme terminée si l'une de ses alternatives de retrait et de livraison est visitée. Le coût peut être exprimé dans la même unité que celle utilisée pour tous les autres champs liés aux coûts dans le modèle et doit être positif. IMPORTANT : Si cette pénalité n'est pas spécifiée, elle est considérée comme infinie, c'est-à-dire que l'expédition doit être effectuée. |
pickup_to_delivery_relative_detour_limit |
Spécifie le temps de détour relatif maximal par rapport au chemin le plus court entre le point de prise en charge et le point de livraison. Si elle est spécifiée, elle doit être non négative et l'expédition doit contenir au moins un enlèvement et une livraison. Par exemple, soit t le temps le plus court pour aller directement de l'alternative de retrait sélectionnée à l'alternative de livraison sélectionnée. Le paramètre Si des limites relatives et absolues sont spécifiées pour le même envoi, la limite la plus contraignante est utilisée pour chaque paire d'enlèvement/de livraison possible. Depuis le 10/2017, les détours ne sont acceptés que lorsque les durées de trajet ne dépendent pas des véhicules. |
Charger
Lors d'une visite, une quantité prédéfinie peut être ajoutée à la charge du véhicule s'il s'agit d'un enlèvement, ou soustraite s'il s'agit d'une livraison. Ce message définit ce montant. Consultez les load_demands.
| Champs | |
|---|---|
amount |
La quantité de marchandises transportées par le véhicule effectuant la visite correspondante varie. Comme il s'agit d'un entier, nous conseillons aux utilisateurs de choisir une unité appropriée pour éviter toute perte de précision. Doit être ≥ 0. |
VisitRequest
Demande de visite pouvant être effectuée par un véhicule : elle comporte une ou deux géolocalisations (voir ci-dessous), des heures d'ouverture et de fermeture représentées par des plages horaires, et une durée de service (temps passé par le véhicule une fois arrivé pour récupérer ou déposer des marchandises).
| Champs | |
|---|---|
arrival_location |
Emplacement géographique où le véhicule arrive lors de l'exécution de cette |
arrival_waypoint |
Point de cheminement où le véhicule arrive lors de l'exécution de cette |
departure_location |
Emplacement géographique où le véhicule part après avoir terminé cette |
departure_waypoint |
Point de cheminement où le véhicule repart après avoir terminé cette |
tags[] |
Spécifie les tags associés à la demande de visite. Les chaînes vides ou en double ne sont pas autorisées. |
time_windows[] |
Périodes qui limitent l'heure d'arrivée à une visite. Notez qu'un véhicule peut partir en dehors de la période d'arrivée. En d'autres termes, l'heure d'arrivée et la durée ne doivent pas nécessairement se trouver dans une période. Cela peut entraîner un temps d'attente si le véhicule arrive avant L'absence de Les périodes doivent être disjointes, c'est-à-dire qu'aucune période ne doit chevaucher une autre ni être adjacente à une autre, et elles doivent être dans l'ordre croissant.
|
duration |
Durée de la visite, c'est-à-dire le temps passé par le véhicule entre son arrivée et son départ (à ajouter au temps d'attente possible ; voir |
cost |
Coût du traitement de cette demande de visite sur un itinéraire de véhicule. Vous pouvez l'utiliser pour payer différents coûts pour chaque alternative de retrait ou de livraison d'un colis. Ce coût doit être exprimé dans la même unité que |
load_demands |
Charge les demandes de cette demande de visite. Ce champ est identique au champ |
visit_types[] |
Spécifie les types de visites. Cela peut être utilisé pour allouer le temps supplémentaire nécessaire à un véhicule pour effectuer cette visite (voir Un type ne peut apparaître qu'une seule fois. |
label |
Spécifie un libellé pour cet élément |
avoid_u_turns |
Indique si les demi-tours doivent être évités sur les itinéraires en voiture à cet endroit. L'évitement des demi-tours est une fonctionnalité optimale, mais l'évitement complet n'est pas garanti. Il s'agit d'une fonctionnalité expérimentale. Son comportement est susceptible d'être modifié. Expérimental : pour en savoir plus, consultez https://developers.google.com/maps/tt/route-optimization/experimental/u-turn-avoidance/make-request. |
ShipmentModel
Un modèle d'expédition contient un ensemble d'expéditions qui doivent être effectuées par un ensemble de véhicules, tout en minimisant le coût global, qui est la somme des éléments suivants :
- le coût de l'itinéraire des véhicules (somme du coût par durée totale, du coût par durée de trajet et du coût fixe pour tous les véhicules).
- les pénalités pour les livraisons non effectuées.
- le coût de la durée globale des expéditions.
| Champs | |
|---|---|
shipments[] |
Ensemble d'expéditions qui doivent être effectuées dans le modèle. |
vehicles[] |
Ensemble de véhicules pouvant être utilisés pour effectuer des visites. |
objectives[] |
Ensemble d'objectifs pour ce modèle, que nous allons transformer en coûts. Si elle n'est pas vide, le modèle d'entrée doit être sans frais. Pour obtenir la requête modifiée, veuillez utiliser Expérimental : pour en savoir plus, consultez https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request. |
global_start_time |
Heures de début et de fin globales du modèle : aucune heure en dehors de cette plage ne peut être considérée comme valide. La période du modèle doit être inférieure à un an, c'est-à-dire que Lorsque vous utilisez des champs |
global_end_time |
Si elle n'est pas définie, la valeur par défaut est 00:00:00 UTC, le 1er janvier 1971 (c'est-à-dire secondes : 31536000, nanosecondes : 0). |
global_duration_cost_per_hour |
La "durée globale" du plan global correspond à la différence entre la date de début effective la plus ancienne et la date de fin effective la plus récente de tous les véhicules. Les utilisateurs peuvent attribuer un coût par heure à cette quantité pour essayer d'optimiser la date d'achèvement des tâches, par exemple. Ce coût doit être exprimé dans la même unité que |
duration_distance_matrices[] |
Spécifie les matrices de durée et de distance utilisées dans le modèle. Si ce champ est vide, les distances Google Maps ou géodésiques seront utilisées à la place, en fonction de la valeur du champ Exemples d'utilisation :
|
duration_distance_matrix_src_tags[] |
Balises définissant les sources des matrices de durée et de distance ; Les tags correspondent à |
duration_distance_matrix_dst_tags[] |
Tags définissant les destinations des matrices de durée et de distance : Les tags correspondent à |
transition_attributes[] |
Ajout d'attributs de transition au modèle. |
shipment_type_incompatibilities[] |
Ensembles de shipment_types incompatibles (voir |
shipment_type_requirements[] |
Ensembles d'exigences |
precedence_rules[] |
Ensemble de règles de priorité qui doivent être appliquées dans le modèle. IMPORTANT : L'utilisation de règles de précédence limite la taille du problème qui peut être optimisé. Les demandes utilisant des règles de priorité qui incluent de nombreuses expéditions peuvent être refusées. |
max_active_vehicles |
Limite le nombre maximal de véhicules actifs. Un véhicule est actif si son itinéraire effectue au moins une livraison. Cela peut être utilisé pour limiter le nombre d'itinéraires dans le cas où il y a moins de chauffeurs que de véhicules et que la flotte de véhicules est hétérogène. L'optimisation sélectionnera ensuite le meilleur sous-ensemble de véhicules à utiliser. Doit être strictement positif. |
DurationDistanceMatrix
Spécifie une matrice de durée et de distance entre les lieux de début et de fin des visites et des véhicules.
| Champs | |
|---|---|
rows[] |
Spécifie les lignes de la matrice de durée et de distance. Il doit comporter autant d'éléments que |
vehicle_start_tag |
Tag définissant les véhicules auxquels s'applique cette matrice de durée et de distance. Si ce champ est vide, cela s'applique à tous les véhicules et il ne peut y avoir qu'une seule matrice. Chaque heure de début de véhicule doit correspondre exactement à une matrice. Autrement dit, exactement un de ses champs Toutes les matrices doivent avoir un |
Ligne
Spécifie une ligne de la matrice de durée et de distance.
| Champs | |
|---|---|
durations[] |
Valeurs de durée pour une ligne donnée. Il doit comporter autant d'éléments que |
meters[] |
Valeurs de distance pour une ligne donnée. Si aucun coût ni aucune contrainte ne fait référence à des distances dans le modèle, ce champ peut être laissé vide. Sinon, il doit comporter autant d'éléments que |
Objectif
Les objectifs remplacent complètement le modèle de coût et sont donc incompatibles avec les coûts préexistants. Chaque objectif est associé à un certain nombre de coûts prédéfinis pour, par exemple, les véhicules, les expéditions ou les attributs de transition.
Expérimental : pour en savoir plus, consultez https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request.
| Champs | |
|---|---|
type |
Type d'objectif. |
weight |
Le poids de cet objectif par rapport aux autres. Il peut s'agir de n'importe quel nombre non négatif. Les pondérations ne doivent pas nécessairement être égales à 1. Les pondérations sont définies sur 1.0 par défaut. |
Type
Type d'objectif qui sera associé à un ensemble de coûts.
| Enums | |
|---|---|
DEFAULT |
Un ensemble de coûts par défaut sera utilisé pour garantir une solution raisonnable. Remarque : Cet objectif peut être utilisé seul, mais il sera également toujours ajouté avec un poids de 1.0, comme référence, aux objectifs spécifiés par l'utilisateur, s'il n'est pas déjà présent. |
MIN_DISTANCE |
Objectifs "MIN". Minimisez la distance totale parcourue. |
MIN_WORKING_TIME |
Minimisez le temps de travail total, cumulé pour tous les véhicules. |
MIN_TRAVEL_TIME |
Identique à ci-dessus, mais en se concentrant uniquement sur le temps de trajet. |
MIN_NUM_VEHICLES |
Limitez le nombre de véhicules utilisés. |
PrecedenceRule
Règle de précédence entre deux événements (chaque événement correspond à l'enlèvement ou à la livraison d'un colis) : le "second" événement doit commencer au moins offset_duration après le début du "premier".
Plusieurs précédences peuvent faire référence aux mêmes événements (ou à des événements associés), par exemple : "Retrait de B après la livraison de A" et "Retrait de C après le retrait de B".
De plus, les précédences ne s'appliquent que lorsque les deux expéditions sont effectuées. Dans le cas contraire, elles sont ignorées.
| Champs | |
|---|---|
first_is_delivery |
Indique si le premier événement est une livraison. |
second_is_delivery |
Indique si le deuxième événement est une livraison. |
offset_duration |
Décalage entre le premier et le deuxième événement. Elle peut être négative. |
first_index |
Index de l'expédition de l'événement "premier". Ce champ doit être spécifié. |
second_index |
Index de l'expédition de l'événement "second". Ce champ doit être spécifié. |
ShipmentRoute
L'itinéraire d'un véhicule peut être décomposé le long de l'axe temporel comme suit (nous supposons qu'il y a n visites) :
| | | | | T[2], | | |
| Transition | Visit #0 | | | V[2], | | |
| #0 | aka | T[1] | V[1] | ... | V[n-1] | T[n] |
| aka T[0] | V[0] | | | V[n-2],| | |
| | | | | T[n-1] | | |
^ ^ ^ ^ ^ ^ ^ ^
vehicle V[0].start V[0].end V[1]. V[1]. V[n]. V[n]. vehicle
start (arrival) (departure) start end start end end
Notez que nous faisons la distinction entre :
- "Événements ponctuels", tels que le début et la fin du trajet du véhicule, ainsi que le début et la fin de chaque visite (c'est-à-dire l'arrivée et le départ). Ils se produisent à un moment précis.
- "intervalles de temps", tels que les visites elles-mêmes et la transition entre les visites. Bien que les intervalles de temps puissent parfois avoir une durée nulle (c'est-à-dire commencer et se terminer à la même seconde), ils ont souvent une durée positive.
Règles invariantes :
- S'il y a n visites, il y a n+1 transitions.
- Une visite est toujours entourée d'une transition avant (même index) et d'une transition après (index + 1).
- Le démarrage du véhicule est toujours suivi de la transition 0.
- La fin du véhicule est toujours précédée de la transition #n.
Voici ce qui se passe lors d'une Transition et d'une Visit :
---+-------------------------------------+-----------------------------+-->
| TRANSITION[i] | VISIT[i] |
| | |
| * TRAVEL: the vehicle moves from | PERFORM the visit: |
| VISIT[i-1].departure_location to | |
| VISIT[i].arrival_location, which | * Spend some time: |
| takes a given travel duration | the "visit duration". |
| and distance | |
| | * Load or unload |
| * BREAKS: the driver may have | some quantities from the |
| breaks (e.g. lunch break). | vehicle: the "demand". |
| | |
| * WAIT: the driver/vehicle does | |
| nothing. This can happen for | |
| many reasons, for example when | |
| the vehicle reaches the next | |
| event's destination before the | |
| start of its time window | |
| | |
| * DELAY: *right before* the next | |
| arrival. E.g. the vehicle and/or | |
| driver spends time unloading. | |
| | |
---+-------------------------------------+-----------------------------+-->
^ ^ ^
V[i-1].end V[i].start V[i].end
Enfin, voici comment les états TRAVEL, BREAKS, DELAY et WAIT peuvent être organisés lors d'une transition.
- Elles ne se chevauchent pas.
- Le champ DELAY est unique et doit correspondre à une période continue juste avant la prochaine visite (ou la fin de l'utilisation du véhicule). Il suffit donc de connaître la durée du retard pour connaître son heure de début et de fin.
- Les PAUSES sont des périodes contiguës et non chevauchantes. La réponse spécifie l'heure de début et la durée de chaque pause.
- Les états TRAVEL et WAIT sont "préemptables" : ils peuvent être interrompus plusieurs fois pendant cette transition. Les clients peuvent supposer que le voyage a lieu "dès que possible" et que le temps restant est rempli par "attente".
Exemple (complexe) :
TRANSITION[i]
--++-----+-----------------------------------------------------------++-->
|| | | | | | | ||
|| T | B | T | | B | | D ||
|| r | r | r | W | r | W | e ||
|| a | e | a | a | e | a | l ||
|| v | a | v | i | a | i | a ||
|| e | k | e | t | k | t | y ||
|| l | | l | | | | ||
|| | | | | | | ||
--++-----------------------------------------------------------------++-->
| Champs | |
|---|---|
vehicle_index |
Véhicule effectuant l'itinéraire, identifié par son index dans la source |
vehicle_label |
Libellé du véhicule effectuant cet itinéraire, égal à |
vehicle_start_time |
Heure à laquelle le véhicule commence son trajet. |
vehicle_end_time |
Heure à laquelle le véhicule termine son trajet. |
visits[] |
Séquence ordonnée de visites représentant un itinéraire. visits[i] correspond à la i-ème visite de l'itinéraire. Si ce champ est vide, le véhicule est considéré comme inutilisé. |
transitions[] |
Liste ordonnée des transitions pour l'itinéraire. |
has_traffic_infeasibilities |
Lorsque L'arrivée à next_visit aura probablement lieu plus tard que la plage horaire actuelle en raison de l'augmentation du temps de trajet estimé |
route_polyline |
Représentation de l'itinéraire sous forme de polyligne encodée. Ce champ n'est renseigné que si |
breaks[] |
Pauses prévues pour le véhicule effectuant cet itinéraire. La séquence |
metrics |
Métriques de durée, de distance et de charge pour cet itinéraire. Les champs de |
vehicle_fullness |
Champ Expérimental : le comportement ou l'existence de ce champ peuvent changer à l'avenir. |
route_costs |
Coût de l'itinéraire, réparti par champs de requête liés aux coûts. Les clés sont des chemins proto, relatifs à l'OptimizeToursRequest d'entrée (par exemple, "model.shipments.pickups.cost"), et les valeurs sont le coût total généré par le champ de coût correspondant, agrégé sur l'ensemble de l'itinéraire. En d'autres termes, costs["model.shipments.pickups.cost"] correspond à la somme de tous les coûts d'enlèvement sur l'itinéraire. Tous les coûts définis dans le modèle sont détaillés ici, à l'exception de ceux liés aux TransitionAttributes, qui ne sont agrégés qu'à partir du 01/01/2022. |
route_total_cost |
Coût total de l'itinéraire. Somme de tous les coûts dans la carte des coûts. |
Pause
Données représentant l'exécution d'une pause.
| Champs | |
|---|---|
start_time |
Heure de début d'une pause. |
duration |
Durée d'une pause. |
EncodedPolyline
Représentation encodée d'une polyligne. Pour en savoir plus sur l'encodage des polylignes, consultez les pages suivantes : https://developers.google.com/maps/documentation/utilities/polylinealgorithm et https://developers.google.com/maps/documentation/javascript/reference/geometry#encoding.
| Champs | |
|---|---|
points |
Chaîne représentant les points encodés de la polyligne. |
Transition
Transition entre deux événements sur l'itinéraire. Consultez la description de ShipmentRoute.
Si le véhicule ne dispose pas de start_location et/ou de end_location, les métriques de trajet correspondantes sont égales à 0.
| Champs | |
|---|---|
travel_duration |
Durée du trajet pendant cette transition. |
travel_distance_meters |
Distance parcourue pendant la transition. |
traffic_info_unavailable |
Lorsque le trafic est demandé via |
delay_duration |
Somme des durées de retard appliquées à cette transition. Le cas échéant, le délai commence exactement |
break_duration |
Somme de la durée des pauses survenues pendant cette transition, le cas échéant. Les détails sur l'heure de début et la durée de chaque pause sont stockés dans |
wait_duration |
Temps passé à attendre pendant cette transition. La durée d'attente correspond au temps d'inactivité et n'inclut pas le temps de pause. Notez également que ce temps d'attente peut être divisé en plusieurs intervalles non contigus. |
total_duration |
Durée totale de la transition, fournie pour plus de commodité. Cela équivaut à :
|
start_time |
Heure de début de cette transition. |
route_polyline |
Représentation de la polyligne encodée de l'itinéraire suivi pendant la transition. Ce champ n'est renseigné que si |
route_token |
Uniquement en sortie. Jeton opaque pouvant être transmis au SDK Navigation pour reconstruire l'itinéraire pendant la navigation et, en cas de changement d'itinéraire, respecter l'intention initiale lors de la création de l'itinéraire. Traitez ce jeton comme un blob opaque. Ne comparez pas sa valeur entre les requêtes, car elle peut changer même si le service renvoie exactement le même itinéraire. Ce champ n'est renseigné que si |
vehicle_loads |
Charges du véhicule pendant cette transition, pour chaque type qui apparaît dans le Les chargements lors de la première transition sont les chargements de départ de l'itinéraire du véhicule. Ensuite, après chaque visite, les |
VehicleLoad
Indique la charge réelle du véhicule à un moment donné de l'itinéraire, pour un type donné (voir Transition.vehicle_loads).
| Champs | |
|---|---|
amount |
Quantité de charge sur le véhicule, pour le type donné. L'unité de charge est généralement indiquée par le type. Consultez les |
Consulter
Visite effectuée au cours d'un itinéraire. Cette visite correspond à un retrait ou à une livraison d'un Shipment.
| Champs | |
|---|---|
shipment_index |
Index du champ |
is_pickup |
Si la valeur est "true", la visite correspond à la récupération d'un |
visit_request_index |
Index de |
start_time |
Heure à laquelle la visite commence. Notez que le véhicule peut arriver plus tôt sur le lieu de la visite. Les heures sont cohérentes avec le |
load_demands |
La demande de charge de visite totale correspond à la somme de la demande de livraison et de la demande de visite |
detour |
Temps de détour supplémentaire dû aux livraisons visitées sur l'itinéraire avant la visite et au temps d'attente potentiel induit par les créneaux horaires. Si la visite est une livraison, le détour est calculé à partir de la visite de retrait correspondante et est égal à : Sinon, elle est calculée à partir de la |
shipment_label |
Copie du |
visit_label |
Copie du |
injected_solution_location_token |
Jeton opaque représentant des informations sur un lieu visité. Ce champ peut être renseigné dans les visites des itinéraires de résultats lorsque Expérimental : pour en savoir plus, consultez https://developers.google.com/maps/tt/route-optimization/experimental/u-turn-avoidance/make-request. |
ShipmentTypeIncompatibility
Spécifie les incompatibilités entre les expéditions en fonction de leur shipment_type. L'affichage des expéditions incompatibles sur un même itinéraire est limité en fonction du mode d'incompatibilité.
| Champs | |
|---|---|
types[] |
Liste des types incompatibles. Deux colis ayant des |
incompatibility_mode |
Mode appliqué à l'incompatibilité. |
IncompatibilityMode
Modes définissant la façon dont l'apparence des expéditions incompatibles est limitée sur le même itinéraire.
| Enums | |
|---|---|
INCOMPATIBILITY_MODE_UNSPECIFIED |
Mode d'incompatibilité non spécifié. Cette valeur ne doit jamais être utilisée. |
NOT_PERFORMED_BY_SAME_VEHICLE |
Dans ce mode, deux expéditions de types incompatibles ne peuvent jamais partager le même véhicule. |
NOT_IN_SAME_VEHICLE_SIMULTANEOUSLY |
Dans ce mode, deux expéditions de types incompatibles ne peuvent jamais se trouver dans le même véhicule en même temps :
|
ShipmentTypeRequirement
Spécifie les exigences entre les envois en fonction de leur shipment_type. Les spécificités de l'exigence sont définies par le mode d'exigence.
| Champs | |
|---|---|
required_shipment_type_alternatives[] |
Liste des types d'expédition alternatifs requis par |
dependent_shipment_types[] |
Tous les envois dont le champ REMARQUE : Les chaînes d'exigences telles qu'un |
requirement_mode |
Mode appliqué à l'exigence. |
RequirementMode
Modes définissant l'apparence des expéditions dépendantes sur un itinéraire.
| Enums | |
|---|---|
REQUIREMENT_MODE_UNSPECIFIED |
Mode de condition non spécifié. Cette valeur ne doit jamais être utilisée. |
PERFORMED_BY_SAME_VEHICLE |
Dans ce mode, tous les envois "dépendants" doivent partager le même véhicule qu'au moins l'un de leurs envois "requis". |
IN_SAME_VEHICLE_AT_PICKUP_TIME |
Avec le mode Par conséquent, un enlèvement d'expédition "dépendante" doit comporter :
|
IN_SAME_VEHICLE_AT_DELIVERY_TIME |
Comme avant, sauf que les expéditions "dépendantes" doivent avoir une expédition "requise" sur leur véhicule au moment de leur livraison. |
SkippedShipment
Spécifie les détails des expéditions non effectuées dans une solution. Pour les cas triviaux et/ou si nous sommes en mesure d'identifier la raison du saut, nous la signalons ici.
| Champs | |
|---|---|
index |
L'index correspond à l'index de l'envoi dans le |
label |
Copie du |
reasons[] |
Liste des raisons pour lesquelles l'envoi a été ignoré. Voir le commentaire ci-dessus |
penalty_cost |
Il s'agit d'une copie de Expérimental : le comportement ou l'existence de ce champ peuvent changer à l'avenir. |
estimated_incompatible_vehicle_ratio |
Ratio estimé de véhicules qui ne peuvent pas effectuer cette livraison pour au moins l'une des raisons ci-dessous. Remarque : Ce champ n'est rempli que lorsque les raisons concernent un véhicule. Expérimental : le comportement ou l'existence de ce champ peuvent changer à l'avenir. |
Motif
Si nous pouvons expliquer pourquoi l'envoi a été ignoré, les raisons seront indiquées ici. Si la raison n'est pas la même pour tous les véhicules, reason comportera plusieurs éléments. Une expédition ignorée ne peut pas avoir de raisons en double, c'est-à-dire lorsque tous les champs sont identiques, à l'exception de example_vehicle_index. Exemple :
reasons {
code: DEMAND_EXCEEDS_VEHICLE_CAPACITY
example_vehicle_index: 1
example_exceeded_capacity_type: "Apples"
}
reasons {
code: DEMAND_EXCEEDS_VEHICLE_CAPACITY
example_vehicle_index: 3
example_exceeded_capacity_type: "Pears"
}
reasons {
code: CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DISTANCE_LIMIT
example_vehicle_index: 1
}
L'expédition ignorée n'est compatible avec aucun véhicule. Les raisons peuvent être différentes pour tous les véhicules, mais la capacité en "pommes " d'au moins un véhicule (y compris le véhicule 1) serait dépassée, la capacité en "poires " d'au moins un véhicule (y compris le véhicule 3) serait dépassée et la limite de distance d'au moins un véhicule (y compris le véhicule 1) serait dépassée.
| Champs | |
|---|---|
code |
Reportez-vous aux commentaires du code. |
example_vehicle_indices[] |
Identique à Expérimental : le comportement ou l'existence de ce champ peuvent changer à l'avenir. |
example_exceeded_capacity_type |
Si le code de motif est |
example_vehicle_index |
Si le motif est lié à une incompatibilité entre l'expédition et le véhicule, ce champ indique l'index d'un véhicule concerné. |
Code
Code identifiant le type de motif. L'ordre n'a pas d'importance. En particulier, il n'indique pas si une raison donnée apparaîtra avant une autre dans la solution, si les deux s'appliquent.
| Enums | |
|---|---|
CODE_UNSPECIFIED |
Cette valeur ne doit jamais être utilisée. |
NO_VEHICLE |
Aucun véhicule du modèle ne rend toutes les expéditions impossibles. |
DEMAND_EXCEEDS_VEHICLE_CAPACITY |
La demande de l'envoi dépasse la capacité d'un véhicule pour certains types de capacité, dont example_exceeded_capacity_type. |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DISTANCE_LIMIT |
La distance minimale nécessaire pour effectuer cet envoi, c'est-à-dire de l' Notez que pour ce calcul, nous utilisons les distances géodésiques. |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT |
Le temps minimal nécessaire pour effectuer cette livraison, y compris le temps de trajet, le temps d'attente et le temps de service, dépasse la Remarque : Le temps de trajet est calculé dans le meilleur des cas, à savoir la distance géodésique x 36 m/s (environ 130 km/h). |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TRAVEL_DURATION_LIMIT |
Identique à l'exemple ci-dessus, mais nous ne comparons que la durée de trajet minimale et le travel_duration_limit du véhicule. |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TIME_WINDOWS |
Dans le meilleur des cas, le véhicule ne peut pas effectuer cette livraison (voir CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT pour le calcul du temps) s'il commence à son heure de début la plus tôt : la durée totale ferait que le véhicule terminerait après son heure de fin la plus tardive. |
VEHICLE_NOT_ALLOWED |
Le champ allowed_vehicle_indices de l'envoi n'est pas vide et ce véhicule ne lui appartient pas. |
VEHICLE_IGNORED |
Le champ Expérimental : le comportement ou l'existence de ce champ peuvent changer à l'avenir. |
SHIPMENT_IGNORED |
Le champ Expérimental : le comportement ou l'existence de ce champ peuvent changer à l'avenir. |
SKIPPED_IN_INJECTED_SOLUTION_CONSTRAINT |
La livraison est ignorée dans Expérimental : le comportement ou l'existence de ce champ peuvent changer à l'avenir. |
VEHICLE_ROUTE_IS_FULLY_SEQUENCE_CONSTRAINED |
Le relâchement de l'itinéraire du véhicule spécifié dans Expérimental : le comportement ou l'existence de ce champ peuvent changer à l'avenir. |
ZERO_PENALTY_COST |
L'expédition n'entraîne aucun coût de pénalité. Bien que cela puisse être utile en tant que choix de modélisation avancée, cela peut également expliquer a posteriori pourquoi une livraison a été ignorée. Expérimental : le comportement ou l'existence de ce champ peuvent changer à l'avenir. |
TimeWindow
Les plages horaires limitent la durée d'un événement, comme l'heure d'arrivée à une visite ou l'heure de début et de fin d'un véhicule.
Les limites de la période stricte, start_time et end_time, imposent les heures les plus tôt et les plus tard de l'événement, de sorte que start_time <= event_time <=
end_time. La limite inférieure de la période flexible, soft_start_time, exprime une préférence pour que l'événement se produise à soft_start_time ou après, en entraînant un coût proportionnel à la durée avant soft_start_time à laquelle l'événement se produit. La limite supérieure de la période flexible, soft_end_time, exprime une préférence pour que l'événement se produise à soft_end_time ou avant, en entraînant un coût proportionnel à la durée écoulée après soft_end_time. start_time, end_time, soft_start_time et soft_end_time doivent respecter les limites de temps globales (voir ShipmentModel.global_start_time et ShipmentModel.global_end_time) et les règles suivantes :
0 <= `start_time` <= `end_time` and
0 <= `start_time` <= `soft_start_time` and
0 <= `soft_end_time` <= `end_time`.
| Champs | |
|---|---|
start_time |
Heure de début de la période stricte. Si aucune valeur n'est spécifiée, elle est définie sur |
end_time |
Heure de fin de la période stricte. Si aucune valeur n'est spécifiée, elle est définie sur |
soft_start_time |
Heure de début de la période. |
soft_end_time |
Heure de fin flexible de la période. |
cost_per_hour_before_soft_start_time |
Coût par heure ajouté aux autres coûts du modèle si l'événement se produit avant soft_start_time, calculé comme suit : Ce coût doit être positif. Le champ ne peut être défini que si soft_start_time a été défini. |
cost_per_hour_after_soft_end_time |
Coût par heure ajouté aux autres coûts du modèle si l'événement se produit après Ce coût doit être positif. Le champ ne peut être défini que si |
TransitionAttributes
Spécifie les attributs des transitions entre deux visites consécutives sur un itinéraire. Plusieurs TransitionAttributes peuvent s'appliquer à la même transition. Dans ce cas, tous les coûts supplémentaires s'additionnent et la contrainte ou la limite la plus stricte s'applique (selon la sémantique naturelle "ET").
| Champs | |
|---|---|
src_tag |
Balises définissant l'ensemble des transitions (src->dst) auxquelles ces attributs s'appliquent. Une visite de source ou un démarrage de véhicule correspondent si leur |
excluded_src_tag |
Consultez les |
dst_tag |
Une visite de destination ou une fin de véhicule correspondent si leur |
excluded_dst_tag |
Consultez les |
cost |
Spécifie un coût pour effectuer cette transition. Cette valeur est exprimée dans la même unité que tous les autres coûts du modèle et ne doit pas être négative. Il s'ajoute à tous les autres coûts existants. |
cost_per_kilometer |
Spécifie un coût par kilomètre appliqué à la distance parcourue lors de cette transition. Il s'ajoute à tout |
distance_limit |
Spécifie une limite de distance parcourue lors de cette transition. Depuis le 06/2021, seules les limites flexibles sont acceptées. |
delay |
Spécifie un délai lors de l'exécution de cette transition. Ce délai se produit toujours après la fin de la visite source et avant le début de la visite de destination. |
URI
Identifiant de ressource universel qui pointe vers une ressource pouvant être lue et écrite par l'API Route Optimization.
| Champs | |
|---|---|
uri |
URI de la ressource. Il est possible que la ressource n'existe pas encore. Le contenu de la ressource est encodé au format JSON ou textproto. Seules les ressources Google Cloud Storage sont acceptées. Si la ressource est encodée au format JSON, le nom de la ressource doit être suffixé par |
Véhicule
Modélise un véhicule dans un problème de livraison. La résolution d'un problème de livraison créera un itinéraire commençant à start_location et se terminant à end_location pour ce véhicule. Un itinéraire est une séquence de visites (voir ShipmentRoute).
| Champs | |
|---|---|
display_name |
Nom à afficher du véhicule défini par l'utilisateur. Il peut comporter jusqu'à 63 caractères et utiliser des caractères UTF-8. |
travel_mode |
Mode de transport qui affecte les routes utilisables par le véhicule et sa vitesse. Voir aussi |
route_modifiers |
Ensemble de conditions à respecter qui affectent la façon dont les itinéraires sont calculés pour le véhicule donné. |
start_location |
Emplacement géographique où le véhicule commence son trajet avant de récupérer des colis. Si aucune heure n'est spécifiée, le véhicule commence son trajet à son premier point de retrait. Si le modèle d'expédition comporte des matrices de durée et de distance, |
start_waypoint |
Point de cheminement représentant un emplacement géographique où le véhicule démarre avant de récupérer des colis. Si vous ne spécifiez pas |
end_location |
Emplacement géographique où se trouve le véhicule après avoir effectué sa dernière |
end_waypoint |
Point de cheminement représentant un emplacement géographique où le véhicule se termine après avoir effectué son dernier |
start_tags[] |
Spécifie les tags associés au début de l'itinéraire du véhicule. Les chaînes vides ou en double ne sont pas autorisées. |
end_tags[] |
Spécifie les tags associés à la fin de l'itinéraire du véhicule. Les chaînes vides ou en double ne sont pas autorisées. |
start_time_windows[] |
Plages horaires pendant lesquelles le véhicule peut quitter son point de départ. Elles doivent respecter les limites de temps globales (voir les champs Les périodes appartenant au même champ répété doivent être disjointes, c'est-à-dire qu'aucune période ne peut chevaucher une autre ni être adjacente à une autre, et elles doivent être dans l'ordre chronologique.
|
end_time_windows[] |
Plages horaires pendant lesquelles le véhicule peut arriver à sa destination finale. Elles doivent respecter les limites de temps globales (voir les champs Les périodes appartenant au même champ répété doivent être disjointes, c'est-à-dire qu'aucune période ne peut chevaucher une autre ni être adjacente à une autre, et elles doivent être dans l'ordre chronologique.
|
unloading_policy |
Règle de déchargement appliquée au véhicule. |
load_limits |
Capacités du véhicule (poids, volume, nombre de palettes, par exemple). Les clés du mappage sont les identifiants du type de charge, qui correspondent aux clés du champ |
cost_per_hour |
Coûts du véhicule : tous les coûts s'additionnent et doivent être exprimés dans la même unité que Coût par heure de l'itinéraire du véhicule. Ce coût est appliqué à la durée totale de l'itinéraire et inclut le temps de trajet, le temps d'attente et le temps de visite. L'utilisation de |
cost_per_traveled_hour |
Coût par heure de trajet de l'itinéraire du véhicule. Ce coût ne s'applique qu'au temps de trajet de l'itinéraire (c'est-à-dire celui indiqué dans |
cost_per_kilometer |
Coût par kilomètre de l'itinéraire du véhicule. Ce coût s'applique à la distance indiquée dans |
fixed_cost |
Coût fixe appliqué si ce véhicule est utilisé pour gérer un envoi. |
used_if_route_is_empty |
Ce champ ne s'applique aux véhicules que lorsque leur itinéraire ne dessert aucune expédition. Indique si le véhicule doit être considéré comme d'occasion ou non dans ce cas. Si la valeur est "true", le véhicule se déplace de son point de départ à son point d'arrivée, même s'il ne livre aucun colis. Les coûts de temps et de distance résultant de ce trajet sont pris en compte. Sinon, il ne se déplace pas de son point de départ à son point d'arrivée, et aucun |
route_duration_limit |
Limite appliquée à la durée totale de l'itinéraire du véhicule. Dans un |
travel_duration_limit |
Limite appliquée à la durée du trajet de l'itinéraire du véhicule. Dans un |
route_distance_limit |
Limite appliquée à la distance totale de l'itinéraire du véhicule. Dans un |
extra_visit_duration_for_visit_type |
Spécifie un mappage des chaînes visit_types vers les durées. La durée correspond au temps supplémentaire à ajouter à Si une demande de visite comporte plusieurs types, une durée sera ajoutée pour chacun d'eux sur la carte. |
break_rule |
Décrit le programme de pause à appliquer à ce véhicule. Si ce champ est vide, aucune pause n'est prévue pour ce véhicule. |
label |
Spécifie un libellé pour ce véhicule. Ce libellé est indiqué dans la réponse en tant que |
ignore |
Si la valeur est "true", Si une livraison est effectuée par un véhicule ignoré dans Si une expédition est effectuée par un véhicule ignoré dans |
travel_duration_multiple |
Spécifie un facteur multiplicatif qui peut être utilisé pour augmenter ou diminuer les temps de trajet de ce véhicule. Par exemple, si vous définissez cette valeur sur 2.0, cela signifie que ce véhicule est plus lent et que ses temps de trajet sont deux fois plus longs que ceux des véhicules standards. Ce multiple n'a aucune incidence sur la durée des visites. Elle a une incidence sur le coût si AVERTISSEMENT : Les temps de trajet seront arrondis à la seconde la plus proche après l'application de ce multiple, mais avant toute opération numérique. Par conséquent, un petit multiple peut entraîner une perte de précision. Voir également |
DurationLimit
Limite définissant la durée maximale de l'itinéraire d'un véhicule. Il peut s'agir d'une erreur bloquante ou non bloquante.
Lorsqu'un champ de limite flexible est défini, le seuil maximal flexible et le coût associé doivent être définis ensemble.
| Champs | |
|---|---|
max_duration |
Limite stricte qui contraint la durée à être au maximum égale à max_duration. |
soft_max_duration |
Une limite flexible qui n'impose pas de durée maximale, mais qui, en cas de non-respect, entraîne un coût pour l'itinéraire. Ce coût s'ajoute aux autres coûts définis dans le modèle, avec la même unité. Si elle est définie, |
quadratic_soft_max_duration |
Une limite flexible qui n'impose pas de durée maximale, mais qui, en cas de non-respect, entraîne un coût pour l'itinéraire, quadratique par rapport à la durée. Ce coût s'ajoute aux autres coûts définis dans le modèle, avec la même unité. Si elle est définie,
|
cost_per_hour_after_soft_max |
Coût par heure encouru si le seuil Le coût ne doit pas être négatif. |
cost_per_square_hour_after_quadratic_soft_max |
Coût par heure carrée encouru si le seuil Le coût supplémentaire est de 0 si la durée est inférieure au seuil. Sinon, le coût dépend de la durée comme suit : Le coût ne doit pas être négatif. |
LoadLimit
Définit une limite de charge s'appliquant à un véhicule, par exemple "ce camion ne peut transporter que 3 500 kg maximum". Consultez les load_limits.
| Champs | |
|---|---|
soft_max_load |
Limite souple de la charge. Consultez les |
cost_per_unit_above_soft_max |
Si la charge dépasse |
start_load_interval |
Intervalle de charge acceptable du véhicule au début de l'itinéraire. |
end_load_interval |
Intervalle de chargement acceptable du véhicule à la fin du trajet. |
max_load |
Charge maximale acceptable. |
cost_per_kilometer |
Coût du déplacement d'une unité de charge sur un kilomètre pour ce véhicule. Cela peut être utilisé comme proxy pour la consommation de carburant : si la charge est un poids (en newtons), alors charge*kilomètre a la dimension d'une énergie. Expérimental : pour en savoir plus, consultez https://developers.google.com/maps/tt/route-optimization/experimental/load-cost/make-request. |
cost_per_traveled_hour |
Coût du transport d'une unité de charge pendant une heure pour ce véhicule. Expérimental : pour en savoir plus, consultez https://developers.google.com/maps/tt/route-optimization/experimental/load-cost/make-request. |
Intervalle
Intervalle de quantités de charge acceptables.
| Champs | |
|---|---|
min |
Une charge minimale acceptable. Doit être ≥ 0. Si les deux sont spécifiés, |
max |
Une charge maximale acceptable. Doit être ≥ 0. Si elle n'est pas spécifiée, la charge maximale n'est pas limitée par ce message. Si les deux sont spécifiés, |
LoadCost
Coût du déplacement d'une unité de charge pendant une Transition. Pour une charge donnée, le coût correspond à la somme de deux parties :
- min(charge,
load_threshold) *cost_per_unit_below_threshold - max(0, load -
load_threshold) *cost_per_unit_above_threshold
Avec ce coût, les solutions préfèrent répondre d'abord aux demandes élevées ou, de manière équivalente, les récupérer en dernier. Par exemple, si un véhicule est équipé
load_limit {
key: "weight"
value {
cost_per_kilometer {
load_threshold: 15
cost_per_unit_below_threshold: 2.0
cost_per_unit_above_threshold: 10.0
}
}
}
et son itinéraire est start,pickup,pickup,delivery,delivery,end avec les transitions suivantes :
transition { vehicle_load['weight'] { amount: 0 }
travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 20 }
travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 0 }
travel_distance_meters: 1000.0 }
Le coût engendré par cette LoadCost est alors (cost_below * load_below * kilometers + cost_above * load_above * kms)
- transition 0 : 0,0
- transition 1 : 2,0 * 10 * 1,0 + 10,0 * 0 * 1,0 = 20,0
- transition 2 : 2,0 * 15 * 1,0 + 10,0 * (20 - 15) * 1,0 = 80,0
- transition 3 : 2,0 * 10 * 1,0 + 10,0 * 0 * 1,0 = 20,0
- transition 4 : 0.0
La valeur LoadCost sur l'itinéraire est donc de 120,0.
Toutefois, si l'itinéraire est "start,pickup,delivery,pickup,delivery,end" (départ, retrait, livraison, retrait, livraison, arrivée) avec des transitions :
transition { vehicle_load['weight'] { amount: 0 }
travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 0 }
travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 0 }
travel_distance_meters: 1000.0 }
Le coût engendré par ce LoadCost est alors
- transition 0 : 0,0
- transition 1 : 2,0 * 10 * 1,0 + 10,0 * 0 * 1,0 = 20,0
- transition 2 : 0.0
- transition 3 : 2,0 * 10 * 1,0 + 10,0 * 0 * 1,0 = 20,0
- transition 4 : 0.0
Ici, la LoadCost sur l'itinéraire est de 40.0.
LoadCost rend les solutions avec des transitions très chargées plus coûteuses.
Expérimental : pour en savoir plus, consultez https://developers.google.com/maps/tt/route-optimization/experimental/load-cost/make-request.
| Champs | |
|---|---|
load_threshold |
Quantité de charge au-delà de laquelle le coût du déplacement d'une unité de charge passe de cost_per_unit_below_threshold à cost_per_unit_above_threshold. Doit être supérieur ou égal à 0. |
cost_per_unit_below_threshold |
Coût du déplacement d'une unité de charge, pour chaque unité comprise entre 0 et le seuil. Doit être une valeur finie et supérieure ou égale à 0. |
cost_per_unit_above_threshold |
Coût du déplacement d'une unité de charge, pour chaque unité au-dessus du seuil. Dans le cas particulier où le seuil est égal à 0, il s'agit d'un coût fixe par unité. Doit être une valeur finie et supérieure ou égale à 0. |
TravelMode
Modes de transport pouvant être utilisés par les véhicules.
Il doit s'agir d'un sous-ensemble des modes de déplacement de l'API Routes Google Maps Platform. Pour en savoir plus, consultez https://developers.google.com/maps/documentation/routes/reference/rest/v2/RouteTravelMode.
Remarque : Les itinéraires WALKING sont en version bêta et peuvent parfois ne pas inclure de trottoirs ou de voies piétonnes clairs. Vous devez afficher cet avertissement à l'utilisateur pour tous les itinéraires à pied que vous affichez dans votre application.
| Enums | |
|---|---|
TRAVEL_MODE_UNSPECIFIED |
Mode de transport non spécifié, équivalent à DRIVING. |
DRIVING |
Mode de transport correspondant aux itinéraires en voiture (voiture, etc.). |
WALKING |
Mode de transport correspondant aux itinéraires à pied. |
UnloadingPolicy
Règles concernant le déchargement d'un véhicule. Ne s'applique qu'aux expéditions avec retrait et livraison.
Les autres expéditions peuvent avoir lieu n'importe où sur l'itinéraire, indépendamment de unloading_policy.
| Enums | |
|---|---|
UNLOADING_POLICY_UNSPECIFIED |
Aucune règle de déchargement n'est spécifiée. Les livraisons doivent simplement avoir lieu après les collectes correspondantes. |
LAST_IN_FIRST_OUT |
Les livraisons doivent être effectuées dans l'ordre inverse des collectes. |
FIRST_IN_FIRST_OUT |
Les livraisons doivent avoir lieu dans le même ordre que les collectes. |
VehicleFullness
VehicleFullness est une métrique qui calcule le taux de remplissage d'un véhicule. Chaque champ VehicleFullness est compris entre 0 et 1. Il est calculé comme le ratio entre un champ de métrique plafonné (par exemple, AggregatedMetrics.travel_distance_meters) et sa limite de véhicule associée (par exemple, Vehicle.route_distance_limit), le cas échéant. Sinon, le ratio de remplissage reste non défini. Si la limite est définie sur 0, le champ est défini sur 1. Remarque : Lorsqu'un itinéraire est soumis à des problèmes de trafic, certains ratios de remplissage bruts peuvent dépasser 1,0 (par exemple, le véhicule peut dépasser sa limite de distance). Dans ce cas, nous limitons les valeurs de remplissage à 1,0.
| Champs | |
|---|---|
max_fullness |
Maximum de tous les autres champs de ce message. |
distance |
Ratio entre |
travel_duration |
Ratio entre [AggregatedMetrics.travel_duration_seconds][] et |
active_duration |
Ratio entre [AggregatedMetrics.total_duration_seconds][] et |
max_load |
Ratio maximal parmi tous les types de [AggregatedMetrics.max_load][] et leurs |
active_span |
Ratio (heure de fin du véhicule - heure de début du véhicule) / (heure de fin du véhicule la plus tardive - heure de début du véhicule la plus tôt) pour un véhicule donné. Si le dénominateur n'est pas présent, il utilise ( |
Repère
Encapsule un point de cheminement. Les points de cheminement indiquent les lieux d'arrivée et de départ des VisitRequests, ainsi que les lieux de départ et d'arrivée des véhicules.
| Champs | |
|---|---|
side_of_road |
Facultatif. Indique que le véhicule doit s'arrêter à un côté spécifique de la route à l'emplacement de ce point de cheminement. Lorsque vous définissez cette valeur, l'itinéraire passe par l'emplacement afin que le véhicule puisse s'arrêter du côté de la route vers lequel l'emplacement est orienté par rapport au centre de la route. Cette option ne fonctionne pas pour le mode de déplacement "À PIED". |
vehicle_stopover |
Indique que le point de cheminement est destiné à l'arrêt des véhicules, dans le but de prendre en charge ou de déposer des passagers. Cette option ne fonctionne que pour le mode de déplacement "DRIVING" et lorsque le "location_type" est défini sur "location". Expérimental : le comportement ou l'existence de ce champ peuvent changer à l'avenir. |
Champ d'union location_type. Différentes façons de représenter un lieu. location_type ne peut être qu'un des éléments suivants : |
|
location |
Point spécifié à l'aide de coordonnées géographiques, y compris un cap facultatif. |
place_id |
ID de lieu du point d'intérêt associé au point de repère. Lorsque vous utilisez un ID de lieu pour spécifier le lieu d'arrivée ou de départ d'une VisitRequest, utilisez un ID de lieu suffisamment précis pour déterminer un emplacement LatLng pour la navigation vers le lieu. Par exemple, un ID de lieu représentant un bâtiment convient, mais un ID de lieu représentant une route est déconseillé. |