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)OptimizeToursRequest
(message)OptimizeToursRequest.SearchMode
(enum)OptimizeToursRequest.SolvingMode
(enum)OptimizeToursResponse
(message)OptimizeToursResponse.Metrics
(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.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)Vehicle
(message)Vehicle.DurationLimit
(message)Vehicle.LoadLimit
(message)Vehicle.LoadLimit.Interval
(message)Vehicle.TravelMode
(enum)Vehicle.UnloadingPolicy
(enum)Waypoint
(message)
RouteOptimization
Service permettant d'optimiser les trajets en véhicule.
Validité de certains types de champs:
google.protobuf.Timestamp
- Les heures sont exprimées en temps Unix: secondes écoulées depuis le 1er janvier 1970 à 00:00:00+00:00.
- Les secondes doivent être comprises entre 0 et 2 53402300799, 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 définies sur "unset" ou sur "0".
google.protobuf.Duration
- Les secondes doivent être comprises entre 0 et 2 53402300799, 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 définies sur "unset" ou sur "0".
google.type.LatLng
- La latitude doit être comprise dans la plage [-90,0, 90,0].
- La longitude doit être comprise dans la plage [-180,0, +180,0].
- au moins l'une des valeurs de latitude et de longitude doit être différente de zéro.
BatchOptimizeTours |
---|
Optimise les parcours des véhicules pour un ou plusieurs messages Cette méthode est une opération de longue durée (LRO). Les entrées d'optimisation (messages L'utilisateur peut interroger Si le champ Si le champ
|
OptimizeTours |
---|
Envoie un Un modèle L'objectif est d'attribuer des
|
AggregatedMetrics
Métriques agrégées pour ShipmentRoute
(resp. pour OptimizeToursResponse
pour tous les éléments Transition
et/ou Visit
(resp. pour tous les éléments ShipmentRoute
)).
Champs | |
---|---|
performed_ |
Nombre d'expéditions effectuées. Notez qu'une paire de collecte et de livraison ne compte qu'une seule fois. |
travel_ |
Durée totale du trajet pour un itinéraire ou une solution. |
wait_ |
Durée totale d'attente pour un itinéraire ou une solution. |
delay_ |
Durée totale du retard pour un itinéraire ou une solution. |
break_ |
Durée totale de la pause pour un itinéraire ou une solution. |
visit_ |
Durée totale de la visite pour un itinéraire ou une solution. |
total_ |
La durée totale doit être égale à la somme de toutes les durées ci-dessus. Pour les itinéraires, il correspond également à:
|
travel_ |
Distance totale parcourue pour un itinéraire ou une solution. |
max_ |
Charge maximale atteinte sur l'ensemble du parcours (resp. de la solution), pour chacune des quantités de ce parcours (resp. de cette solution), calculée comme la valeur maximale pour tous les |
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 trajets en tant qu'opération asynchrone. Chaque fichier d'entrée doit contenir un OptimizeToursRequest
, et chaque fichier de sortie un OptimizeToursResponse
. La requête contient des informations permettant de lire/écrire et d'analyser les fichiers. Tous les fichiers d'entrée et de sortie doivent appartenir au 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_ |
Obligatoire. Informations d'entrée/sortie 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_ |
Facultatif. Nom du modèle défini par l'utilisateur, qui peut être utilisé comme alias pour suivre les modèles. |
input_ |
Obligatoire. Informations sur le modèle d'entrée. |
output_ |
Obligatoire. Informations sur l'emplacement de sortie souhaité. |
BatchOptimizeToursResponse
Ce type ne comporte aucun champ.
Réponse à un BatchOptimizeToursRequest
. Il est renvoyé 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, pauses déjeuner). Une pause est une période continue pendant laquelle le véhicule reste inactif à son emplacement actuel et ne peut effectuer aucune visite. Une coupure peut se produire:
- pendant le trajet entre deux visites (ce qui inclut le temps 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 ne peut pas démarrer au milieu d'une pause), auquel cas il n'a aucune incidence sur l'heure de démarrage du véhicule.
- ou après la fin du véhicule (idem, avec l'heure de fin du véhicule).
Champs | |
---|---|
break_ |
Séquence de pauses. Le message |
frequency_ |
Plusieurs |
BreakRequest
La séquence des 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 elles doivent se produire. Leurs périodes (earliest_start_time
/ latest_start_time
) peuvent se chevaucher, mais elles doivent être compatibles avec la commande (ce point est vérifié).
Champs | |
---|---|
earliest_ |
Obligatoire. Seuil inférieur (inclusif) au début de la pause. |
latest_ |
Obligatoire. Limite supérieure (inclusive) du début de la coupure. |
min_ |
Obligatoire. Durée minimale de la coupure. Doit être positive. |
FrequencyConstraint
Vous pouvez également limiter davantage la fréquence et la durée des pauses spécifiées ci-dessus en appliquant une fréquence minimale de pause, par exemple "Il doit y avoir une pause d'au moins une heure toutes les 12 heures". En supposant que cette règle puisse être interprétée comme "Dans chaque période glissante de 12 heures, il doit y avoir au moins une pause d'au moins une heure", cet exemple se traduirait par la FrequencyConstraint
suivante:
{
min_break_duration { seconds: 3600 } # 1 hour.
max_inter_break_duration { seconds: 39600 } # 11 hours (12 - 1 = 11).
}
Le moment et la durée des pauses dans la solution respecteront toutes ces contraintes, en plus des périodes et des durées minimales déjà spécifiées dans le BreakRequest
.
En pratique, un FrequencyConstraint
peut s'appliquer à des pauses non consécutives. Par exemple, l'exemple suivant respecte l'exemple "1 heure toutes les 12 heures" :
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_ |
Obligatoire. Durée minimale de la coupure pour cette contrainte. Non négatif. Consultez la description de |
max_ |
Obligatoire. Plage maximale autorisée pour tout intervalle de temps de l'itinéraire qui n'inclut pas, au moins partiellement, une coupure 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 (Notation d'objet JavaScript) |
PROTO_TEXT |
Format de texte Protocol Buffers. Voir https://protobuf.dev/reference/protobuf/textformat-spec/ |
DistanceLimit
Limite définissant la distance maximale pouvant être parcourue. Il peut être dur ou mou.
Si une limite souple est définie, soft_max_meters
et cost_per_kilometer_above_soft_max
doivent être définis et ne pas être négatifs.
Champs | |
---|---|
max_ |
Limite stricte qui limite la distance à max_mètres maximum. La limite ne doit pas être négative. |
soft_ |
Limite souple qui n'applique pas de limite 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 défini, soft_max_meters doit être inférieur à max_meters et non négatif. |
cost_ |
Coût par kilomètre, pouvant atteindre
Ce coût n'est pas accepté dans |
cost_ |
Frais par kilomètre facturés si la distance dépasse la limite de
Le coût ne doit pas être négatif. |
GcsDestination
Emplacement Google Cloud Storage dans 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 limitées et comment elles doivent l'être.
Champs | |
---|---|
routes[] |
Itinéraires de la solution à injecter. Il est possible que certains itinéraires soient omis de la solution d'origine. Les itinéraires et les envois ignorés doivent respecter les hypothèses de validité de base indiquées pour |
skipped_ |
Envois ignorés de la solution à injecter. Certains peuvent être omis de la solution d'origine. Consultez le champ |
constraint_ |
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éhicule non vides sont entièrement contraintes. |
ConstraintRelaxation
Pour un groupe de véhicules, spécifie à partir de quel ou quels seuils les contraintes liées aux visites seront assouplies et à quel niveau. Les envois listés dans le champ skipped_shipment
doivent être ignorés, c'est-à-dire qu'ils ne peuvent pas être effectués.
Champs | |
---|---|
relaxations[] |
Toutes les assouplissements des contraintes de visite qui s'appliqueront aux visites sur les itinéraires avec des véhicules dans |
vehicle_ |
Spécifie les indices de véhicule auxquels la contrainte de visite Un indice 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, les heures de début et de fin d'un véhicule dans routes
sont entièrement contraintes, 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 de la contrainte appliqué à une visite #j qui répond aux conditions suivantes:
route.visits(j).start_time >= relaxations(i).threshold_time
ETj + 1 >= relaxations(i).threshold_visit_count
De même, le démarrage du véhicule est limité à relaxations(i).level
s'il répond aux conditions suivantes:
vehicle_start_time >= relaxations(i).threshold_time
ETrelaxations(i).threshold_visit_count == 0
et l'extrémité du véhicule est relâchée surrelaxations(i).level
si elle répond aux conditions suivantes:vehicle_end_time >= relaxations(i).threshold_time
ETroute.visits_size() + 1 >= relaxations(i).threshold_visit_count
Pour appliquer un niveau de relaxation si une visite répond aux critères threshold_visit_count
OU threshold_time
, ajoutez deux relaxations
avec le même level
: l'un avec uniquement threshold_visit_count
défini et l'autre avec uniquement threshold_time
défini. Si une visite remplit les conditions de plusieurs relaxations
, le niveau le plus souple s'applique. Par conséquent, du début du trajet du véhicule jusqu'à la fin, le niveau de relaxation augmente, c'est-à-dire qu'il ne diminue pas au fur et à mesure du trajet.
Le calendrier et la séquence des visites de l'itinéraire qui ne répondent pas aux conditions de seuil de n'importe quel 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 remplit pas les conditions 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 à partir de |
threshold_ |
Heure à laquelle la relaxation |
threshold_ |
Nombre de visites à partir duquel la relaxation S'il s'agit de |
Niveau
Indique les différents niveaux de relâchement des contraintes appliqués à une visite et aux suivantes lorsqu'elle répond aux conditions de seuil.
L'énumération ci-dessous est organisée par ordre d'apaisement croissant.
Enums | |
---|---|
LEVEL_UNSPECIFIED |
Niveau de relaxation par défaut implicite: aucune contrainte n'est levé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 et de fin des visites et des véhicules seront moins strictes, mais chaque visite reste associée au même véhicule et la séquence des visites doit être respectée: aucune visite ne peut être insérée entre elles ou avant elles. |
RELAX_VISIT_TIMES_AND_SEQUENCE_AFTER_THRESHOLD |
Comme pour RELAX_VISIT_TIMES_AFTER_THRESHOLD , mais la séquence de visite 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 |
Comme RELAX_VISIT_TIMES_AND_SEQUENCE_AFTER_THRESHOLD , mais le véhicule est également détendu: les visites sont totalement sans frais à partir de l'heure limite et peuvent potentiellement ne pas être effectuées. |
InputConfig
Spécifiez une entrée pour [BatchOptimizeTours][google.maps.routeoptimization.v1.RouteOptimizationService.BatchOptimizeTours].
Champs | |
---|---|
data_ |
Obligatoire. Format des données d'entrée. |
Champ d'union source . Obligatoire. source ne peut être qu'un des éléments suivants : |
|
gcs_ |
Emplacement Google Cloud Storage. Il doit s'agir d'un seul objet (fichier). |
Lieu
Encapsule un emplacement (un point géographique et un angle facultatif).
Champs | |
---|---|
lat_ |
Coordonnées géographiques du point de cheminement. |
heading |
Direction indiquée par la boussole associée au sens du trafic. Cette valeur permet de spécifier le côté de la route à emprunter pour le ramassage et le dépôt. Les valeurs de cap peuvent varier de 0 à 360, où 0 indique un cap au nord, 90 un cap à l'est, etc. |
OptimizeToursRequest
Requête à transmettre à un outil d'optimisation de tournées qui 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 avant expiration ou avant l'expiration du délai avant expiration du serveur pour les requêtes synchrones, selon la première éventualité. Pour les requêtes asynchrones, le serveur génère une solution (si possible) avant l'expiration du délai avant expiration. |
model |
Modèle d'expédition à résoudre. |
solving_ |
Par défaut, le mode de résolution est |
search_ |
Mode de recherche utilisé pour résoudre la requête. |
injected_ |
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 expéditions qui ne sont pas effectuées sur un itinéraire sont implicitement ignorées dans la première solution, mais elles peuvent être effectuées dans des solutions successives. 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'impossibilité de la solution peut être renvoyée à la place. |
injected_ |
Contraignez l'algorithme d'optimisation à trouver une solution finale semblable à une solution précédente. Par exemple, vous pouvez utiliser cette fonctionnalité pour congeler des parties de parcours 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. Une erreur indiquant l'impossibilité de la solution peut être renvoyée à la place. |
refresh_ |
Si ce n'est pas le cas, les itinéraires donnés seront actualisés, sans modifier leur séquence de visites sous-jacente ni les temps de trajet. Seuls d'autres détails seront mis à jour. Cela ne résout pas le modèle. Depuis le 11/11/2020, cette valeur ne renseigne que les polylignes des itinéraires non vides et nécessite que Les champs Ce champ ne doit pas être utilisé avec
|
interpret_ |
Si la condition est vraie:
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 Supprimer des visites de parcours ou des parcours entiers d'une solution injectée peut avoir un impact sur les contraintes implicites, ce qui peut entraîner un changement de la solution, des erreurs de validation ou une infeasibility. REMARQUE: L'appelant doit s'assurer que chaque |
consider_ |
Tenez compte de l'estimation du trafic lors du calcul des champs |
populate_ |
Si la valeur est "true", les polylignes sont renseignées dans les |
populate_ |
Si la valeur est "true", les polylignes et les jetons de parcours sont renseignés dans la réponse |
allow_ |
Si cette valeur est définie, la requête peut avoir un délai (voir https://grpc.io/blog/deadlines) maximal de 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 nettement plus élevé (mais toujours faible). |
use_ |
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, indiqué dans |
geodesic_ |
Lorsque |
max_ |
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 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 latence et qualité de la solution. Dans tous les modes, la date limite de la requête globale est appliquée.
Enums | |
---|---|
SEARCH_MODE_UNSPECIFIED |
Mode de recherche non spécifié, équivalent à RETURN_FAST . |
RETURN_FAST |
Arrêtez la recherche une fois que vous avez trouvé la première bonne solution. |
CONSUME_ALL_AVAILABLE_TIME |
Passez tout le temps disponible à rechercher de meilleures solutions. |
SolvingMode
Définit la manière 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 recevez 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: renseigne autant de OptimizeToursResponse.validation_errors que possible. |
DETECT_SOME_INFEASIBLE_SHIPMENTS |
Ne renseigne que IMPORTANT: Toutes les expéditions impossibles ne sont pas renvoyées ici, mais uniquement celles qui sont détectées comme telles lors du prétraitement. |
OptimizeToursResponse
Réponse après avoir résolu un problème d'optimisation de tournée contenant les itinéraires suivis par chaque véhicule, les envois ignorés et le coût global de la solution.
Champs | |
---|---|
routes[] |
Itinéraires calculés pour chaque véhicule. L'itinéraire i correspond au véhicule i du modèle. |
request_ |
Copie de l' |
skipped_ |
Liste de tous les envois ignorés. |
validation_ |
Liste de toutes les erreurs de validation que nous avons pu détecter indépendamment. Consultez l'explication "MULTIPLE ERRORS" (ERREURS MULTIPLES) pour le message |
metrics |
Métriques de durée, de distance et d'utilisation de cette solution. |
Métriques
Métriques globales, agrégées pour tous les itinéraires.
Champs | |
---|---|
aggregated_ |
Agrégation sur les itinéraires. Chaque métrique correspond à la somme (ou à la valeur maximale, pour les charges) de tous les champs |
skipped_ |
Nombre d'envois obligatoires ignorés. |
used_ |
Nombre de véhicules utilisés. Remarque: Si un itinéraire de véhicule est vide et que |
earliest_ |
Heure de début la plus précoce pour un véhicule d'occasion, calculée comme la valeur minimale pour tous les véhicules d'occasion de |
latest_ |
Heure de fin la plus tardive pour un véhicule d'occasion, calculée comme la valeur maximale de |
costs |
Coût de la solution, réparti par champ de requête lié aux coûts. Les clés sont des chemins proto, par rapport à la requête OptimizeToursRequest d'entrée (par exemple, "model.shipments.pickups.cost"), et les valeurs correspondent au coût total généré par le champ de coût correspondant, agrégées pour l'ensemble de la solution. En d'autres termes, costs["model.shipments.pickups.cost"] correspond à la somme de tous les coûts de ramassage pour la solution. Tous les coûts définis dans le modèle sont indiqués ici en détail, à l'exception des coûts liés à TransitionAttributes, qui ne sont indiqués de manière agrégée qu'à partir de janvier 2022. |
total_ |
Coût total de la solution. Somme de toutes les valeurs de la carte des coûts. |
OptimizeToursValidationError
Décrit une erreur ou un avertissement rencontrés 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. MULTIPLE ERRORS: en cas de plusieurs erreurs, le processus de validation tente d'en afficher plusieurs. Tout comme un compilateur, il s'agit d'un processus imparfait. Certaines erreurs de validation sont "fatales", ce qui signifie qu'elles arrêtent l'ensemble du processus de validation. C'est le cas, entre autres, des erreurs STABILITÉ: |
display_ |
Nom à afficher de l'erreur. |
fields[] |
Un contexte d'erreur peut impliquer zéro, un (la plupart du temps) ou plusieurs champs. Par exemple, pour faire référence au véhicule 4 et à la première collecte de l'envoi 2, vous pouvez procéder comme suit:
Notez toutefois que la cardinalité de |
error_ |
Chaîne de texte décrivant l'erreur. Il existe un mappage 1:1 entre STABILITÉ: non stable: le message d'erreur associé à un |
offending_ |
Peut contenir la ou les valeurs du ou des champs. Ce n'est pas toujours possible. Vous ne devez absolument pas vous y fier et ne l'utiliser que pour le débogage manuel du modèle. |
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 }
Nous omettons toutefois les entités de niveau supérieur telles que OptimizeToursRequest
ou ShipmentModel
pour éviter de surcharger le message.
Champs | |
---|---|
name |
Nom du champ (par exemple, "vehicles". |
sub_ |
Sous-champ imbriqué de manière récursive, si nécessaire. |
Champ d'union
|
|
index |
Index du champ en cas de répétition. |
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_ |
Obligatoire. Format des données de sortie. |
Champ d'union destination . Obligatoire. destination ne peut être qu'un des éléments suivants : |
|
gcs_ |
Emplacement Google Cloud Storage dans lequel écrire la sortie. |
RouteModifiers
Encapsule un ensemble de conditions facultatives à respecter lors du calcul des itinéraires des véhicules. Cela ressemble à RouteModifiers
dans l'API Google Maps Platform Routes Preferred (Itinéraires préférés) : consultez https://developers.google.com/maps/documentation/routes/reference/rest/v2/RouteModifiers.
Champs | |
---|---|
avoid_ |
Indique si les routes à péage doivent être évitées dans la mesure du possible. Les itinéraires ne comportant pas de routes à péage seront privilégiés. Ne s'applique qu'aux modes de transport motorisés. |
avoid_ |
Indique si les autoroutes doivent être évitées dans la mesure du possible. Les itinéraires ne comportant pas d'autoroutes seront privilégiés. Ne s'applique qu'aux modes de transport motorisés. |
avoid_ |
Indique si les ferries doivent être évités dans la mesure du possible. Les itinéraires ne comportant pas de trajets en ferry seront privilégiés. Ne s'applique qu'aux modes de transport motorisés. |
avoid_ |
Facultatif. Indique si la navigation en intérieur doit être évitée dans la mesure du possible. Les itinéraires ne comportant pas de navigation intérieure seront privilégiés. Ne s'applique qu'au mode de déplacement |
Livraison
Expédition d'un seul article, de l'un de ses enlèvements à l'un de ses envois. Pour que la livraison soit considérée comme effectuée, un véhicule unique doit se rendre à l'un de ses points de collecte (et réduire ses capacités de réserve en conséquence), puis à l'un de ses points de livraison par la suite (et donc augmenter à nouveau ses capacités de réserve en conséquence).
Champs | |
---|---|
display_ |
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'options de retrait associées à l'envoi. Si ce n'est pas le cas, le véhicule n'a besoin de se rendre que dans un lieu correspondant aux livraisons. |
deliveries[] |
Ensemble d'options de livraison associées à l'envoi. Si ce n'est pas le cas, le véhicule n'a besoin de se rendre que dans un lieu correspondant aux enlèvements. |
load_ |
Exigences de chargement de l'envoi (par exemple, poids, volume, nombre de palettes, etc.). Les clés de la carte doivent être des identifiants décrivant le type de charge correspondant, en incluant idéalement les unités. Par exemple: "weight_kg", "volume_gallons", "pallet_count", etc. Si une clé donnée n'apparaît pas dans la mappe, la charge correspondante est considérée comme nulle. |
allowed_ |
Ensemble des véhicules pouvant effectuer cette livraison. Si ce champ est vide, tous les véhicules peuvent l'effectuer. Les véhicules sont indiqués par leur indice dans la liste |
costs_ |
Indique le coût encouru lorsque cette livraison est effectuée par chaque véhicule. S'il est spécifié, il doit avoir:
Ces coûts doivent être exprimés dans les mêmes unités que |
costs_ |
Indices des véhicules auxquels |
pickup_ |
Indique la durée maximale du détour absolu par rapport au chemin le plus court entre le point de collecte et la livraison. Si elle est spécifiée, elle doit être non négative, et l'envoi doit contenir au moins un retrait et une livraison. Par exemple, prenons t comme temps le plus court pour aller directement de l'option de retrait sélectionnée à l'option 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 de ramassage/livraison possible. Depuis octobre 2017, les détours ne sont acceptés que lorsque les durées de trajet ne dépendent pas des véhicules. |
pickup_ |
Spécifie la durée maximale entre le début de la collecte et le début de la livraison d'un envoi. Si elle est spécifiée, elle doit être non négative, et l'envoi doit contenir au moins un retrait et une livraison. Cela ne dépend pas des options sélectionnées pour le retrait et la livraison, ni de la vitesse du véhicule. Vous pouvez le spécifier avec des contraintes de déviation maximales: la solution respectera les deux spécifications. |
shipment_ |
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 les Diffère de |
label |
Indique un libellé pour cette expédition. Ce libellé est indiqué dans la réponse dans le |
ignore |
Si la valeur est "true", ignorez cette expédition, mais n'appliquez pas de Ignorer un envoi génère une erreur de validation lorsqu'il existe des Vous pouvez ignorer une livraison effectuée en |
penalty_ |
Si l'envoi n'est pas effectué, cette pénalité est ajoutée au coût global des itinéraires. Un envoi est considéré comme terminé si l'une des options de retrait et de livraison est utilisée. Le coût peut être exprimé dans les mêmes unités que celles utilisées pour tous les autres champs liés aux coûts du 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'envoi doit être effectué. |
pickup_ |
Indique le temps de déviation maximal par rapport au chemin le plus court entre le point de collecte et la livraison. Si elle est spécifiée, elle doit être non négative, et l'envoi doit contenir au moins un retrait et une livraison. Par exemple, prenons t comme temps le plus court pour passer directement de l'option de retrait sélectionnée à l'option 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 de ramassage/livraison possible. Depuis octobre 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'une collecte ou soustraite s'il s'agit d'une livraison. Ce message définit ce montant. Consultez les load_demands
.
Champs | |
---|---|
amount |
La charge du véhicule effectuant la visite correspondante varie. Étant donné qu'il s'agit d'un entier, nous recommandons 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 géolocalisation (ou deux, voir ci-dessous), des heures d'ouverture et de fermeture représentées par des plages horaires, ainsi qu'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_ |
Position géographique où le véhicule arrive lors de l'exécution de cette |
arrival_ |
Point de repère où le véhicule arrive lors de l'exécution de cette |
departure_ |
Position géographique du véhicule à son départ après avoir terminé cette |
departure_ |
Point d'intérêt à partir duquel le véhicule part après avoir terminé cette |
tags[] |
Spécifie les balises associées à la requête de visite. Les chaînes vides ou en double ne sont pas autorisées. |
time_ |
Fenêtres temporelles qui limitent l'heure d'arrivée lors d'une visite. Notez qu'un véhicule peut partir en dehors de la période d'arrivée, c'est-à-dire que l'heure d'arrivée + la durée ne doivent pas 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 ne doit se chevaucher ni être adjacente à une autre. Elles doivent également être triées par ordre croissant.
|
duration |
Durée de la visite, c'est-à-dire temps passé par le véhicule entre l'arrivée et le départ (à ajouter au temps d'attente possible, voir |
cost |
Coût de traitement de cette demande de visite sur un itinéraire de véhicule. Vous pouvez ainsi payer des frais différents pour chaque mode de retrait ou de livraison alternatif d'un colis. Ce coût doit être exprimé dans les mêmes unités que |
load_ |
Chargez les demandes de cette requête de visite. Il s'agit du même champ |
visit_ |
Indique 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 |
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 correspond à la somme des éléments suivants:
- le coût du calcul d'itinéraire des véhicules (somme du coût par temps total, du coût par temps de trajet et du coût fixe pour tous les véhicules).
- les pénalités liées aux envois non effectués.
- le coût de la durée globale des envois ;
Champs | |
---|---|
shipments[] |
Ensemble d'envois qui doivent être effectués dans le modèle. |
vehicles[] |
Ensemble de véhicules pouvant être utilisés pour effectuer des visites. |
global_ |
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 l' Lorsque vous utilisez des champs |
global_ |
Si cette valeur n'est pas définie, la valeur par défaut est 00:00:00 UTC, 1er janvier 1971 (c'est-à-dire secondes: 31536000, nanos: 0). |
global_ |
La "durée globale" du plan global correspond à la différence entre la première heure de début effective et la dernière heure de fin effective de tous les véhicules. Les utilisateurs peuvent attribuer un coût par heure à cette quantité pour essayer d'optimiser la réalisation de la tâche le plus rapidement possible, par exemple. Ce coût doit être exprimé dans les mêmes unités que |
duration_ |
Spécifie les matrices de durée et de distance utilisées dans le modèle. Si ce champ est vide, Google Maps ou les distances géodésiques sont utilisées à la place, en fonction de la valeur du champ Exemples d'utilisation :
|
duration_ |
Balises définissant les sources des matrices de durée et de distance ; Les balises correspondent à |
duration_ |
Balises définissant les destinations des matrices de durée et de distance : Les balises correspondent à |
transition_ |
Attributs de transition ajoutés au modèle. |
shipment_ |
Ensembles de types de livraison incompatibles (voir |
shipment_ |
Ensembles d'exigences |
precedence_ |
Ensemble de règles de priorité qui doivent être appliquées dans le modèle. |
max_ |
Limite le nombre maximal de véhicules actifs. Un véhicule est considéré comme actif si son itinéraire effectue au moins une livraison. Vous pouvez l'utiliser pour limiter le nombre d'itinéraires dans le cas où il y a moins de conducteurs 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épart et d'arrivée 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_ |
Tag définissant les véhicules auxquels cette matrice de durée et de distance s'applique. Si elle est vide, elle s'applique à tous les véhicules, et il ne peut y avoir qu'une seule matrice. Chaque démarrage de véhicule doit correspondre à une seule matrice, c'est-à-dire qu'un seul 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 contenir autant d'éléments que |
PrecedenceRule
Règle de priorité entre deux événements (chaque événement correspond à la collecte ou à la livraison d'un envoi): le "deuxième" événement doit commencer au moins offset_duration
après le début du "premier".
Plusieurs priorités peuvent faire référence aux mêmes événements (ou à des événements associés), par exemple : "Le retrait de B a lieu après la livraison de A" et "Le retrait de C a lieu après le retrait de B".
De plus, les priorités ne s'appliquent que lorsque les deux envois sont effectués, et sont ignorées dans le cas contraire.
Champs | |
---|---|
first_ |
Indique si l'événement "premier" est une diffusion. |
second_ |
Indique si l'événement "second" est une diffusion. |
offset_ |
Décalage entre le premier et le deuxième événement. Il peut être négatif. |
first_ |
Indice d'expédition du premier événement. Ce champ doit être spécifié. |
second_ |
Indice d'expédition de l'événement "second". Ce champ doit être spécifié. |
ShipmentRoute
Le trajet 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 (arrivée et départ). Ils se produisent à un instant donné.
- "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 précédée d'une transition (même indice) et suivie d'une transition (indice + 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.
En zoomant, 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 éléments 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 contiguë juste avant la prochaine visite (ou la fin du véhicule). Il suffit donc de connaître la durée du délai pour connaître son heure de début et de fin.
- Les PAUSES sont des périodes de temps contiguës et non se chevauchant. La réponse spécifie l'heure de début et la durée de chaque pause.
- TRAVEL et WAIT sont "préemptables": ils peuvent être interrompus plusieurs fois pendant cette transition. Les clients peuvent supposer que le trajet se fait "dès que possible" et que l'attente occupe le temps restant.
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_ |
Véhicule effectuant le trajet, identifié par son indice dans la source |
vehicle_ |
Libellé du véhicule effectuant ce trajet, égal à |
vehicle_ |
Heure à laquelle le véhicule commence son trajet. |
vehicle_ |
Heure à laquelle le véhicule termine son itinéraire. |
visits[] |
Séquence ordonnée de visites représentant un itinéraire. visits[i] correspond à la i e visite de l'itinéraire. Si ce champ est vide, le véhicule est considéré comme inutilisé. |
transitions[] |
Liste triée des transitions pour le parcours. |
has_ |
Lorsque
L'arrivée à next_visit aura probablement lieu plus tard que la période actuelle en raison de l'augmentation de l'estimation du temps de trajet |
route_ |
Représentation de l'itinéraire sous forme de polyligne encodée. Ce champ n'est renseigné que si |
breaks[] |
Pauses planifiées 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 |
route_ |
Coût du trajet, réparti par champ de requête lié aux coûts. Les clés sont des chemins proto, par rapport à la requête OptimizeToursRequest d'entrée (par exemple, "model.shipments.pickups.cost"), et les valeurs correspondent au coût total généré par le champ de coût correspondant, agrégées sur l'ensemble du parcours. En d'autres termes, costs["model.shipments.pickups.cost"] correspond à la somme de tous les coûts de prise en charge sur l'itinéraire. Tous les coûts définis dans le modèle sont indiqués ici en détail, à l'exception des coûts liés à TransitionAttributes, qui ne sont indiqués de manière agrégée qu'à partir de janvier 2022. |
route_ |
Coût total de l'itinéraire. Somme de tous les coûts de la carte des coûts. |
Pause
Données représentant l'exécution d'une pause.
Champs | |
---|---|
start_ |
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 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 le parcours. 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_ |
Durée du trajet pendant cette transition. |
travel_ |
Distance parcourue pendant la transition. |
traffic_ |
Lorsque le trafic est demandé via |
delay_ |
Somme des durées de retard appliquées à cette transition. Le délai, le cas échéant, commence exactement |
break_ |
Somme de la durée des pauses qui se produisent pendant cette transition, le cas échéant. Les informations sur l'heure de début et la durée de chaque pause sont stockées dans |
wait_ |
Durée d'attente 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_ |
Durée totale de la transition, fournie à titre indicatif. Il est égal à:
|
start_ |
Heure de début de cette transition. |
route_ |
Représentation de la polyligne encodée de l'itinéraire suivi pendant la transition. Ce champ n'est renseigné que si |
route_ |
Uniquement en sortie. Jeton opaque pouvant être transmis au SDK Navigation pour reconstruire l'itinéraire pendant la navigation et, en cas de recalcul 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_ |
Chargements du véhicule pendant cette transition, pour chaque type qui apparaît dans la Les charges lors de la première transition correspondent aux charges de départ du trajet 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 |
Charge du véhicule pour le type donné. L'unité de charge est généralement indiquée par le type. Consultez les |
Accéder à la page
Visite effectuée lors d'un parcours. Cette visite correspond à un retrait ou à une livraison d'un Shipment
.
Champs | |
---|---|
shipment_ |
Indice du champ |
is_ |
Si la valeur est "true", la visite correspond à la récupération d'un |
visit_ |
Indice de |
start_ |
Heure de début de la visite. Notez que le véhicule peut arriver plus tôt sur le lieu de la visite. Les heures sont cohérentes avec le |
load_ |
Demande de charge de visite totale en tant que somme de l'envoi et de la demande de visite |
detour |
Temps de déviation supplémentaire en raison des envois visités sur l'itinéraire avant la visite et du temps d'attente potentiel induit par les délais. 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 l'
|
shipment_ |
Copie de l' |
visit_ |
Copie de l' |
ShipmentTypeIncompatibility
Indique les incompatibilités entre les envois en fonction de leur type d'envoi. L'affichage des envois incompatibles sur le même itinéraire est limité en fonction du mode d'incompatibilité.
Champs | |
---|---|
types[] |
Liste des types incompatibles. Deux envois ayant un |
incompatibility_ |
Mode appliqué à l'incompatibilité. |
IncompatibilityMode
Modes définissant la façon dont l'affichage des envois incompatibles est limité 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 envois de types incompatibles ne peuvent jamais partager le même véhicule. |
NOT_IN_SAME_VEHICLE_SIMULTANEOUSLY |
Pour deux envois de types incompatibles avec le mode d'incompatibilité
|
ShipmentTypeRequirement
Spécifie les exigences entre les expéditions en fonction de leur type d'expédition. Les spécificités de l'exigence sont définies par le mode d'exigence.
Champs | |
---|---|
required_ |
Liste des autres types d'expédition requis par |
dependent_ |
Pour tous les envois dont le type est indiqué dans le champ REMARQUE: Les chaînes d'exigences telles qu'un |
requirement_ |
Mode appliqué à l'exigence. |
RequirementMode
Modes définissant l'apparence des envois dépendants sur un itinéraire.
Enums | |
---|---|
REQUIREMENT_MODE_UNSPECIFIED |
Mode d'exigence non spécifié. Cette valeur ne doit jamais être utilisée. |
PERFORMED_BY_SAME_VEHICLE |
Dans ce mode, toutes les livraisons "dépendantes" doivent partager le même véhicule qu'au moins l'une de leurs livraisons "obligatoires". |
IN_SAME_VEHICLE_AT_PICKUP_TIME |
Avec le mode Un retrait d'envoi "dépendant" doit donc avoir:
|
IN_SAME_VEHICLE_AT_DELIVERY_TIME |
Comme précédemment, sauf que les envois "dépendants" doivent être associés à un envoi "obligatoire" sur le véhicule au moment de la livraison. |
SkippedShipment
Spécifie les détails des expéditions non effectuées dans une solution. Dans les cas simples et/ou si nous sommes en mesure d'identifier la cause du saut, nous indiquons la raison ici.
Champs | |
---|---|
index |
L'index correspond à l'index de l'envoi dans le |
label |
Copie de l' |
reasons[] |
Liste des raisons pour lesquelles l'envoi a été ignoré. Voir le commentaire au-dessus de |
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
contiendra plus d'un élément. Les raisons d'une livraison ignorée ne doivent pas être en double, c'est-à-dire que tous les champs doivent être 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'envoi ignoré n'est pas compatible avec tous les véhicules. Les raisons peuvent être différentes pour tous les véhicules, mais la capacité "Pommes " d'au moins un véhicule serait dépassée (y compris le véhicule 1), la capacité "Poires " d'au moins un véhicule serait dépassée (y compris le véhicule 3) et la limite de distance d'au moins un véhicule serait dépassée (y compris le véhicule 1).
Champs | |
---|---|
code |
Reportez-vous aux commentaires du code. |
example_ |
Si le code de motif est |
example_ |
Si le motif est lié à une incompatibilité entre l'envoi et le véhicule, ce champ indique l'indice d'un véhicule pertinent. |
Code
Code identifiant le type de motif. L'ordre ici n'a aucune signification. 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 méthode ne doit jamais être utilisée. |
NO_VEHICLE |
Aucun véhicule n'est disponible dans le modèle, ce qui rend toutes les livraisons 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, c'est-à-dire en tant que distance géodésique x 36 m/s (environ 130 km/h). |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TRAVEL_DURATION_LIMIT |
Comme ci-dessus, mais nous ne comparons que le temps de trajet minimal et l'travel_duration_limit du véhicule. |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TIME_WINDOWS |
Le véhicule ne peut pas effectuer cette livraison dans le meilleur des cas (voir CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT pour le calcul du temps) s'il commence à son heure de début la plus précoce: la durée totale ferait que le véhicule se 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 n'y est pas associé. |
TimeWindow
Les périodes de temps limitent l'heure d'un événement, comme l'heure d'arrivée d'une visite ou les heures de début et de fin d'un véhicule.
Les limites de la période d'exécution stricte, start_time
et end_time
, définissent la date et l'heure de début et de fin de l'événement, de sorte que start_time <= event_time <=
end_time
. La limite inférieure de la période de démarrage souple, soft_start_time
, indique que l'événement doit se produire à partir de soft_start_time
. Un coût proportionnel au délai avant le début du démarrage souple est alors appliqué. La limite supérieure de la fenêtre temporelle souple, soft_end_time
, indique une préférence pour que l'événement se produise à soft_end_time
ou avant, en générant un coût proportionnel au temps écoulé 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 éléments suivants:
0 <= `start_time` <= `end_time` and
0 <= `start_time` <= `soft_start_time` and
0 <= `soft_end_time` <= `end_time`.
Champs | |
---|---|
start_ |
Heure de début de la période de temps fixe. Si aucune valeur n'est spécifiée, elle est définie sur |
end_ |
Heure de fin de la période fixe. Si aucune valeur n'est spécifiée, elle est définie sur |
soft_ |
Heure de début de la période. |
soft_ |
Heure de fin flexible de la période. |
cost_ |
Coût par heure ajouté aux autres coûts du modèle si l'événement se produit avant l'heure de démarrage souple, calculé comme suit:
Ce coût doit être positif, et le champ ne peut être défini que si "soft_start_time" a été défini. |
cost_ |
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, et 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_ |
Balises définissant l'ensemble de transitions (src->dst) auxquelles ces attributs s'appliquent. Une visite de la source ou un démarrage du véhicule correspondent si et seulement si |
excluded_ |
Consultez les |
dst_ |
Une visite de destination ou une fin de trajet correspondent si et seulement si |
excluded_ |
Consultez les |
cost |
Indique le coût de 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'applique en plus de tous les autres coûts existants. |
cost_ |
Indique un coût par kilomètre appliqué à la distance parcourue lors de cette transition. Il s'ajoute à tous les |
distance_ |
Spécifie une limite de distance parcourue lors de cette transition. Depuis juin 2021, seules les limites souples sont acceptées. |
delay |
Indique un délai induit 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. |
Véhicule
Modélise un véhicule en cas de problème de livraison. Si vous résolvez un problème d'expédition, un itinéraire commençant à start_location
et se terminant à end_location
sera créé pour ce véhicule. Un itinéraire est une séquence de visites (voir ShipmentRoute
).
Champs | |
---|---|
display_ |
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 de déplacement qui affecte les routes utilisables par le véhicule et sa vitesse. Consultez également |
route_ |
Ensemble de conditions à respecter qui affectent la façon dont les itinéraires sont calculés pour le véhicule donné. |
start_ |
Emplacement géographique où le véhicule commence avant de récupérer des envois. Si cette valeur n'est pas spécifiée, le véhicule démarre à son premier retrait. Si le modèle d'expédition comporte des matrices de durée et de distance, |
start_ |
Point de repère représentant un emplacement géographique où le véhicule commence avant de récupérer des envois. Si vous ne spécifiez pas |
end_ |
Emplacement géographique où le véhicule se termine après avoir terminé sa dernière |
end_ |
Point de cheminement représentant l'emplacement géographique où le véhicule se termine après avoir terminé sa dernière |
start_ |
Spécifie les balises associées au début du trajet du véhicule. Les chaînes vides ou en double ne sont pas autorisées. |
end_ |
Spécifie les balises ajoutées à la fin de l'itinéraire du véhicule. Les chaînes vides ou en double ne sont pas autorisées. |
start_ |
Intervalles de temps pendant lesquels 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 se chevaucher ni être adjacente à une autre. Elles doivent également être présentées dans l'ordre chronologique.
|
end_ |
Périodes pendant lesquelles le véhicule peut arriver à sa destination. 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 se chevaucher ni être adjacente à une autre. Elles doivent également être présentées dans l'ordre chronologique.
|
unloading_ |
Règle de déchargement appliquée au véhicule. |
load_ |
Capacités du véhicule (poids, volume, nombre de palettes, par exemple) Les clés du mappage sont les identifiants du type de charge, conformément aux clés du champ |
cost_ |
Coûts du véhicule: tous les coûts doivent être additionnés et être exprimés dans la même unité que Coût par heure du trajet du véhicule. Ce coût est appliqué au temps total de l'itinéraire, et comprend le temps de trajet, le temps d'attente et le temps de visite. L'utilisation de |
cost_ |
Coût par heure parcourue sur 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_ |
Coût par kilomètre du trajet du véhicule. Ce coût s'applique à la distance indiquée dans le |
fixed_ |
Coût fixe appliqué si ce véhicule est utilisé pour gérer un envoi. |
used_ |
Ce champ ne s'applique qu'aux véhicules dont l'itinéraire ne dessert aucune livraison. Indique si le véhicule doit être considéré comme d'occasion ou non dans ce cas. Si cette valeur est définie sur "true", le véhicule se déplace de son point de départ à son point d'arrivée, même s'il ne dessert aucun envoi. Les coûts de temps et de distance résultant de son trajet de départ à destination 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_ |
Limite appliquée à la durée totale du trajet du véhicule. Dans un |
travel_ |
Limite appliquée à la durée du trajet sur l'itinéraire du véhicule. Dans un |
route_ |
Limite appliquée à la distance totale du trajet du véhicule. Dans un |
extra_ |
Spécifie un mappage des chaînes "visit_types" aux durées. La durée correspond au temps supplémentaire à prendre en plus de Si une demande de visite comporte plusieurs types, une durée est ajoutée pour chaque type dans la carte. |
break_ |
Décrit le calendrier des pauses à appliquer à ce véhicule. Si ce champ est vide, aucune pause ne sera planifiée pour ce véhicule. |
label |
Spécifie un libellé pour ce véhicule. Ce libellé est indiqué dans la réponse sous la forme |
ignore |
Si la valeur est "true", Si une livraison est effectuée par un véhicule ignoré dans Si une livraison est effectuée par un véhicule ignoré dans |
travel_ |
Spécifie un facteur multiplicateur 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, ce véhicule est plus lent et 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 les coûts si AVERTISSEMENT: Les temps de trajet seront arrondis à la seconde la plus proche après l'application de ce multiple, mais avant l'exécution d'opérations numériques. Par conséquent, un multiple faible 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 être dur ou mou.
Lorsqu'un champ de limite souple est défini, le seuil de limite souple et le coût associé doivent être définis ensemble.
Champs | |
---|---|
max_ |
Limite stricte qui limite la durée à max_duration. |
soft_ |
Limite souple qui n'applique pas de limite de durée maximale, mais qui entraîne des frais si elle est dépassé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, |
quadratic_ |
Limite souple qui n'applique pas de limite de durée maximale, mais qui entraîne un coût proportionnel au carré de la durée en cas de non-respect. 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_ |
Coût par heure en cas de dépassement du seuil
Le coût ne doit pas être négatif. |
cost_ |
Coût par heure carrée en cas de dépassement du seuil Le coût supplémentaire est nul si la durée est inférieure au seuil. Sinon, il dépend de la durée comme suit:
Le coût ne doit pas être négatif. |
LoadLimit
Définit une limite de charge applicable à un véhicule (par exemple, "ce camion ne peut transporter que 3 500 kg"). Consultez les load_limits
.
Champs | |
---|---|
soft_ |
Limite flexible de la charge. Consultez les |
cost_ |
Si la charge dépasse |
start_ |
Intervalle de charge acceptable du véhicule au début du trajet. |
end_ |
Intervalle de charge acceptable du véhicule à la fin du trajet. |
max_ |
Charge maximale acceptable. |
Intervalle
Intervalle de charges acceptables.
Champs | |
---|---|
min |
Charge minimale acceptable. Doit être ≥ 0. Si les deux sont spécifiés, |
max |
Charge maximale acceptable. Doit être ≥ 0. Si cette valeur n'est pas spécifiée, la charge maximale n'est pas limitée par ce message. Si les deux sont spécifiés, |
TravelMode
Modes de transport pouvant être utilisés par les véhicules.
Il doit s'agir d'un sous-ensemble des modes de transport de l'API Routes Preferred de Google Maps Platform. Pour en savoir plus, consultez la page https://developers.google.com/maps/documentation/routes_preferred/reference/rest/Shared.Types/RouteTravelMode.
Enums | |
---|---|
TRAVEL_MODE_UNSPECIFIED |
Mode de transport non spécifié, équivalent à DRIVING . |
DRIVING |
Mode de transport correspondant aux itinéraires routiers (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 envois comportant à la fois un retrait et une livraison.
Les autres envois peuvent se produire n'importe où sur le parcours, indépendamment de unloading_policy
.
Enums | |
---|---|
UNLOADING_POLICY_UNSPECIFIED |
Règle de déchargement non spécifiée : les livraisons doivent simplement avoir lieu après les collectes correspondantes. |
LAST_IN_FIRST_OUT |
Les livraisons doivent avoir lieu dans l'ordre inverse des collectes. |
FIRST_IN_FIRST_OUT |
Les livraisons doivent avoir lieu dans le même ordre que les collectes. |
Repère
Encapsule un point de cheminement. Les points de cheminement indiquent les lieux d'arrivée et de départ des demandes de visite, ainsi que les lieux de départ et d'arrivée des véhicules.
Champs | |
---|---|
side_ |
Facultatif. Indique que l'emplacement de ce point de cheminement est destiné à indiquer au véhicule de s'arrêter d'un côté particulier de la route. 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 avec le mode de déplacement "À PIED". |
Champ d'union location_type . Différentes façons de représenter un emplacement. location_type ne peut être qu'un des éléments suivants : |
|
location |
Point spécifié à l'aide de coordonnées géographiques, y compris d'un angle de visée facultatif. |
place_ |
ID de lieu du POI associé au point de cheminement. |