Backhaul calculation / Freight exchange

[Bernd Welter]

Hi there,

I've been asked for some recommendation for a nice little usecase - as I created another testclient for this let me share my results with you.
Here's the story:

• Imagine you are returning from a long distance trip with an empty vehicle. At that stage you already know the distance and traveltime of the blue relation based on a distance matrix or 1:1 route. Let's call these KPIs the "reference" for the next steps.

  

• Now within your horizon there's a bunch of potential pickup-delivery orders you could go for.

  

  FTL somewhere around you

Question: which one can you add to your empty return trip with the least efforts?

• First I created a dummy input tour with the blue relation and enforced the pickup location to be FIRST_CUSTOMER_STOP and the delivery as LAST_CUSTOMER_STOP. Then I performed a FindChangeToursProposalsRequest for each pickup delivery candidate:

  Code: Select all

  FindChangeToursProposalsRequest findChangeToursProposalsRequest = new FindChangeToursProposalsRequest
  {
        proposalsOptions = new ChangeToursProposalsOptions { },
        proposalsQuery = new InsertionPositionsForOrdersQuery
        {
           targetVehicleIds = new string[] { "vehicle" },
           orderIds = new string[] { 
           orderId
        },
        storedRequestId = toursResponse.storedRequestId
     }
  };

  The output of these calls gives me the decision criteria to compare the impact of the potential "changeToursActions" compared to the "reference" KPIs.

  

  All potential inserts

• I then used the confirmed changeToursActions to compute the complete insertion moves.

  

  A specific selection

• This approach gives a very good result in terms of quality but it also "wastes" number of transactions with a square complexity. This is why I evaluated an alternative approach below.

• For the alternative approach I didn't use the xTour module but a linear growing process based on three contributing factors per candidate:
  • The leg from the global starting location to a candidates pickup
  • the leg from the candidates pickup to the candidates delivery
  • the leg from the candidates delivery to the global delivery.
  So more or less this is based on 3 rectangular matrices:
  • [1:N] : from the global pickup to all candidates pickups
  • N-times [1:1] : from each candidates pickup to its own delivery (this info is supposed to be available once such a candidate is inserted into the global pool!)
  • finally a [N:1] matric from each candidates delivery to the global delivery
  . The output looks pretty much the same compared to the approach above but there's a downsight: you can't apply break- and restrules

  

  Instead of the complete distance matrix based "tour optimization" you can go for a linear growing approach

• NO matter what approach you want to go for: it probably makes sense to define some simple filter criteria to not consider changeTours which exceed some threshold value, e.g. based on a relative "increase" of traveltime or distance caused by the detour.

  

  Client filter based on relative distance... threshold 75%

• Last but not least you could evaluate to define some other criteria in advance which reduces the input candidates for that little process, e.g. based on corridor searches / reachable areas.

  

  The corridor of 100km along the reoute - helpful for some quick prefiltering "before" the candidates are forwarded to the "expensive" process.

PS: Of course I already calculated all the underlying info based on a xDima2.CreateDistanceMatrix request...