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.
• Les envois représentent des tâches ou des envois réels qui incluent des VisitRequest de collecte et de livraison. Les envois disposent de paramètres et de 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 un niveau de précision 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 livraisons. Toutes les expéditions et transitions attribuées doivent être terminées avant cette date.

Propriétés de livraison

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

• pickups[] et deliveries[] indiquent où un colis peut être retiré ou abandonné. Les propriétés pickups[] et deliveries[] utilisent toutes deux 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 à la fois. 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. Lue davantage sur les coûts dans l'article Paramètres du modèle de coût.

Propriétés du véhicule

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

• 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 itinéraire. Cette propriété est facultative. Si aucune valeur n'est spécifiée, l'itinéraire du véhicule prend fin à l'emplacement sa dernière livraison attribuée.
• 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 exigences et les limites de chargement, consultez l'article Exigences et limites Limites.

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 l'exemple ci-dessus, mais de différentes manières. 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