Construire un message de requête

Comme décrit brièvement dans la Présentation de l'optimisation des routes, une requête de base se compose du modèle, des expéditions et des véhicules, qui sont les entités requises:

• Un modèle capture les paramètres et les contraintes de l'ensemble de la requête, Shipments et Vehicles inclus.
• Expéditions, qui correspondent aux tâches ou aux expéditions réelles qui incluent le retrait et de diffusion VisitRequest. Les expéditions ont des paramètres et des contraintes locaux.
• Les véhicules représentent des véhicules, des conducteurs ou du personnel. Les véhicules ont également des paramètres et 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. Des contraintes à l'échelle du modèle s'appliquent livraisons et véhicules, tandis que les contraintes et propriétés spécifiées sur les expéditions ou véhicules sont spécifiques à une expédition ou à un véhicule unique.

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

OptimizeToursRequest établissements

Certaines propriétés couramment utilisées du message OptimizeToursRequest de premier niveau (REST, gRPC) incluent les éléments suivants:

• searchMode indique s'il faut renvoyer la première solution qui satisfait aux critères des contraintes spécifiées ou de trouver la meilleure solution possible dans un les délais.
• 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 d'itinéraire sont renvoyées dans la réponse.

Propriétés du modèle

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

• globalStartTime représente l'heure de début la plus proche pour l'ensemble des itinéraires les véhicules et les livraisons. Aucun véhicule ne peut lancer ses premières transitions livraisons antérieures à cette date.
• 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

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

• 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ésentent la charge requise pour qu'un véhicule effectue une livraison. Véhicules le load_limits correspondant (REST, gRPC) représente la charge qu'un véhicule peut supporter en même temps. Pour en savoir plus sur le chargement, consultez l'article Demandes et limites de chargement.
• penalty_cost représente le coût facturé si une livraison 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 le point de départ d'un véhicule. Ce est facultative. Si aucune valeur n'est spécifiée, l'itinéraire du véhicule commence au l'emplacement de la première livraison qui lui a été attribuée.
• endLocation représente l'endroit où un véhicule doit terminer son itinéraire. Cette propriété est facultatif. 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[] représente le moment où un véhicule peut prendre son itinéraire. Ce est facultative.
• endTimeWindows[] représente les heures de début et de fin de son trajet pour un véhicule. Ces deux propriétés sont facultatives.
• loadLimits représente la capacité du véhicule disponible pour répondre aux exigences des expéditions de la charge de travail. 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 tels que dans l'exemple ci-dessus, mais de différentes manières. Avant d'effectuer une optimisation d'itinéraire il est important de comprendre la différence entre les deux méthodes:

Comparer OptimizeTours et BatchOptimizeTours