Construire un message de requête

Comme décrit brièvement dans la section Présentation de l'optimisation des itinéraires, une requête de base comprend les entités Modèle, Expéditions et Véhicules comme entités obligatoires:

• Model capture les paramètres et les contraintes de l'ensemble de la requête, y compris Shipments et Vehicles.
• Expéditions représentent les tâches ou les expéditions réelles qui incluent des VisitRequest pour le retrait et la livraison. Les expéditions ont des paramètres et des contraintes locaux.
• Véhicules : représente les véhicules, les conducteurs ou le personnel. Les véhicules disposent également de paramètres et de contraintes locaux.

Les propriétés de chaque entité décrivent une partie d'un problème d'optimisation à un niveau de granularité particulier. Les contraintes au niveau du modèle s'appliquent à tous les envois et véhicules, tandis que les contraintes et les propriétés spécifiées sur les envois ou les véhicules sont spécifiques à un seul envoi ou véhicule.

Pour obtenir une documentation complète sur chaque type de message, consultez la documentation de référence pour les messages ShipmentModel (REST, gRPC), Shipment (REST, gRPC) et Vehicle (REST, gRPC).

OptimizeToursRequest établissements

Voici quelques propriétés couramment utilisées du message OptimizeToursRequest de niveau supérieur (REST, gRPC) :

• searchMode indique si la première solution qui répond aux contraintes spécifiées doit être renvoyée ou si la meilleure solution possible doit être trouvée dans un délai défini.
• considerRoadTraffic détermine si le trafic en temps réel est utilisé ou non pour l'itinéraire et l'estimation de l'heure d'arrivée prévue.
• populateTransitionPolylines détermine si les polylignes de parcours et les jetons de parcours sont renvoyés ou non dans la réponse.

Propriétés du modèle

Voici quelques propriétés couramment utilisées du message ShipmentModel (REST, gRPC) :

• globalStartTime représente l'heure de début la plus précoce des itinéraires pour tous les véhicules et envois. Aucun véhicule ne peut commencer ses premières transitions et expéditions avant cette heure.
• globalEndTime représente la dernière heure de fin des itinéraires pour tous les véhicules et tous les envois. Toutes les expéditions et transitions attribuées doivent être terminées avant cette date.

Propriétés de l'envoi

Voici quelques propriétés couramment utilisées du message Shipment (REST, gRPC) :

• pickups[] et deliveries[] indiquent l'endroit où un colis peut être retiré ou déposé. Les propriétés pickups[] et deliveries[] utilisent toutes deux le message VisitRequest (REST, gRPC).
• loadDemands représente la charge requise pour qu'un véhicule effectue une livraison. La propriété load_limits (REST, gRPC) correspondante des véhicules représente la charge qu'un véhicule peut supporter simultanément. Pour en savoir plus sur la charge, consultez la section Demandes et limites de charge.
• penalty_cost représente le coût encouru si une expédition est ignorée. Pour en savoir plus sur les coûts, consultez la page Paramètres du modèle de coût.

Propriétés du véhicule

Voici quelques propriétés couramment utilisées du message Vehicle (REST, gRPC) :

• startLocation représente l'emplacement où un véhicule doit commencer son itinéraire. Cette propriété est facultative. Si cette valeur n'est pas spécifiée, l'itinéraire du véhicule commence à l'emplacement de son premier envoi attribué.
• endLocation représente l'endroit où un véhicule doit terminer son trajet. Cette propriété est facultative. Si ce champ n'est pas spécifié, l'itinéraire du véhicule se termine à l'emplacement de son dernier envoi attribué.
• startTimeWindows[] indique le moment où un véhicule peut commencer son trajet. Cette propriété est facultative.
• endTimeWindows[] indique le moment où un véhicule peut commencer et terminer son trajet. Ces deux propriétés sont facultatives.
• loadLimits représente la capacité du véhicule disponible pour répondre aux demandes de charge des envois. Pour en savoir plus sur les demandes et les limites de charge, consultez Demandes et limites de charge.

Voici un exemple de requête complète au format JSON:

{
  "model": {
    "shipments": [
      {
        "pickups": [
          {
            "arrivalLocation": {
              "latitude": 37.73881799999999,
              "longitude": -122.4161
            }
          }
        ],
        "deliveries": [
          {
            "arrivalLocation": {
              "latitude": 37.79581,
              "longitude": -122.4218856
            }
          }
        ]
      }
    ],
    "vehicles": [
      {
        "startLocation": {
          "latitude": 37.73881799999999,
          "longitude": -122.4161
        },
        "endLocation": {
          "latitude": 37.73881799999999,
          "longitude": -122.4161
        },
        "costPerKilometer": 1.0
      }
    ],
   "globalStartTime": "2024-02-13T00:00:00.000Z",
   "globalEndTime": "2024-02-14T06:00:00.000Z"
  }
}

OptimizeTours et BatchOptimizeTours consomment tous deux des messages de requête comme dans l'exemple ci-dessus, mais de manière différente. Avant d'envoyer une requête d'optimisation de l'itinéraire, il est important de comprendre la différence entre les deux méthodes:

Comparaison de OptimizeTours et BatchOptimizeTours