Prioriser les visites à proximité avec les attributs de transition

Cet exemple montre comment utiliser les attributs de transition pour hiérarchiser les itinéraires où les collectes et les livraisons à proximité sont effectuées par le même véhicule dans un même bloc temporel. Pour en savoir plus sur les attributs de transition, consultez Modéliser la logique métier avec des attributs de transition.

Dans cet exemple :

• Les livraisons des envois A, B et C sont proches les unes des autres sur la même route.
• D'autres livraisons sont plus loin sur la route.
• Aucun délai de livraison n'est spécifié pour les livraisons.
• Quel que soit l'itinéraire, le véhicule doit emprunter cette route deux fois : une fois le matin en partant du dépôt et une fois le soir au retour.
• La distance totale parcourue et la durée de l'itinéraire sont toujours les mêmes, quel que soit le moment où A, B et C sont effectués.

Dans ce cas, et pour une requête qui n'utilise que le coût par heure et le coût par kilomètre, l'itinéraire optimisé peut gérer A et B le matin, et C le soir. Le coût de la solution est le même que si les trois sont gérés en même temps.

Coût par kilomètre avec un seuil

Pour regrouper les visites à proximité, vous devez d'abord sélectionner une distance seuil. Il s'agit de la distance maximale entre deux visites que vous considérez comme étant à proximité. Cet exemple utilise un seuil de 100 mètres, ce qui correspond à peu près à un pâté de maisons dans une zone urbaine. Vous pouvez augmenter ou diminuer le seuil en fonction des besoins de votre entreprise et des préférences de vos chauffeurs.

Pour regrouper les visites à proximité à moins de 100 mètres les unes des autres, vous définissez un coût élevé pour les 100 premiers mètres de chaque transition et un coût inférieur pour les mètres supplémentaires de la transition. Étant donné que les 100 premiers mètres sont les plus chers, l'optimiseur réalise les plus grandes économies en utilisant des transitions inférieures au seuil de 100 mètres, même si cela signifie allonger la longueur totale de l'itinéraire.

Pour configurer les coûts, ajoutez une entrée à ShipmentModel.transition_attributes avec les propriétés suivantes :

• Pour correspondre à toutes les transitions possibles, choisissez un tag qui n'est utilisé nulle part dans le modèle, par exemple UNUSED_TAG. Définissez TransitionAttributes.excluded_src_tag et TransitionAttributes.excluded_dst_tag sur ce tag.
• Configurez TransitionAttributes.distance_limit avec la distance seuil et les coûts :
  • Définissez DistanceLimit.soft_max_meters sur le seuil sélectionné.
  • Définissez DistanceLimit.cost_per_kilometer_below_soft_max sur le coût par kilomètre en dessous du seuil.
  • Définissez DistanceLimit.cost_per_kilometer_above_soft_max sur le coût par kilomètre au-dessus du seuil.

{
  "model": {
    "transitionAttributes": [
      {
        "excluded_dst_tag": "UNUSED_TAG",
        "excluded_src_tag": "UNUSED_TAG",
        "distanceLimit": {
          "softMaxMeters": 100,
          "costPerKilometerBelowSoftMax": 50,
          "costPerKilometerAboveSoftMax": 1,
        }
      }
    ]
  }
}

Le tag #unused_tag# ne doit être utilisé par aucun envoi ni véhicule pour correspondre à toutes les transitions possibles. Pour en savoir plus, consultez Comment faire correspondre toutes les demandes de visite.

Fonctionnement d'un coût élevé en dessous du seuil

Cette section explique comment le coût en dessous et au-dessus du seuil affecte le coût global des différentes solutions du scénario d'exemple.

Solution 1 : Effectuer A et B à l'aller, et C au retour

Dans cette solution, les envois sont divisés en deux traversées de cette route. Deux d'entre eux sont livrés lors de la première traversée, et le dernier lors de la deuxième. Il existe cinq transitions :

Le coût global est calculé comme la somme des deux coûts par kilomètre :

• le coût par kilomètre en dessous du seuil (50) multiplié par la distance totale parcourue en dessous du seuil (450 m = 0,45 km) ;
• le coût par kilomètre au-dessus du seuil (1) multiplié par la distance totale parcourue au-dessus du seuil (3 710 m = 3,71 km).

Le coût global est donc de 0,45 * 50 + 3,71 * 1 = 22,5 + 3,71 = 26,21.

Solution 2 : Effectuer A, B et C à l'aller, et rien au retour

Dans cette solution, contrairement à la solution 1, les trois envois sont livrés "en groupe" lors d'une traversée de la route. Lors de l'autre traversée, le véhicule ne s'arrête pas du tout. Là encore, il existe cinq transitions, mais leurs longueurs et leurs compositions sont différentes :

En utilisant le même calcul que dans la solution 1, le coût global est de 0,38 * 50 + 3,78 * 1 = 19 + 3,78 = 22,78. Effectuer toutes les visites dans un même bloc temporel coûte moins cher que de les effectuer en deux groupes. Vous pouvez renforcer cet effet en augmentant DistanceLimit.cost_per_kilometer_below_soft_max.

Pourquoi un faible coût par kilomètre en dessous du seuil ne fonctionne pas

Étant donné que vous souhaitez privilégier les transitions courtes par rapport aux transitions longues, vous pouvez être tenté d'attribuer un coût par kilomètre élevé aux transitions longues et de conserver le faible coût par kilomètre pour les transitions courtes. Mais cela a en fait un effet inverse : étant donné que les 100 premiers mètres de la transition sont les moins chers, l'optimiseur utilise ces mètres "bon marché" au maximum en privilégiant les transitions qui sont proches ou supérieures à 100 mètres.

Vous pouvez constater cet effet sur les deux solutions d'exemple. Si vous échangez le coût par kilomètre en dessous et au-dessus du seuil, les coûts de l'itinéraire changent :

Pour chaque version, le plus faible des coûts totaux des deux solutions est mis en évidence en gras. Vous pouvez constater que lorsque vous utilisez un coût élevé au-dessus du seuil, le coût total de l'itinéraire est désormais plus élevé pour l'itinéraire où les visites sont regroupées, ce qui est le contraire de ce que vous vouliez obtenir.