HOW TO prefer orders near the depot?

[Bernd Welter]

HI there,

these days a community member draw attention to the planning quality with default settings under the following conditions:

• The number of orders exceeds the available resources.
• Therefore xTour has to perform a selection of the orders to be prefered
• Obviously orders far away from the depot seem to be considered
• This selection produces a result with less orders to be scheduled that possible, the driving distances and periods are greater than wanted.

Orders far away from the depot are considered and this produces a bad performance in terms of efficiency.

There are at least the following two approaches given to increase the quality of the result:

• Use priorities: assign a higher prio to orders near the depot.
• Use BasicConstructionMethod="cBasicCMInsertion" in combination with TourOpt.INI section [DoBasicTourPlanning.Insertion]: … SeedCriteria.Strategy= Nearest.

After applying the NEAREST criteriy the quality seems to be better.

Attention: this approach is only meaningful for a single tour. In other cases it may cause results that are even poorer than with SeedCriteria.Strategy= FARTHEST.

Best regards Bernd

[Lauterfeld]

Hi Bernd,

we found a solution for us with the order priority. The changes in Touropt.Ini are too strict for us beause the user cannot change it from usecase to usecase.
We inserted a user definable table in our software where the user can define km-circles (as the crow flies) around the depot and the priority the orders will get in the request if they are located in such a circle.
Example: From 0 to 20km prio 8, from 20 to 60km prio 7, from 60 to 120km, prio 6 and so on.
Works as designed!

Regards,
Volker.

[Bernd Welter]

There you are right... Check the screenshot: bigger circle means higher prio...

[Bernd Welter]

I just discussed with a partner whether the usage of "costPerUnplannedCustomer" would resolve this at least for the "planOvernight" case.
How does this method react on the costs?

[kleffa]

OvernightParams comes with two cost parameters, costPerOvernightStay and costPerUnplannedCustomer. Together with the costs per km and h, they are used to compute the total costs for an overnight tour. The best (in terms of costs) overnight tour found is returned.

[Bernd Welter]

So in other words:

• planOvernight uses some of the parameters (e.g. maximumNumberOf OvernightStays = 1) to derive potential "scenarios" (e.g. scenario1=overnight on Monday, scenario 2=overnight on Tuesday...)
• It then performs some "temporary standard planning" with each one of the scenarios.
• At that stage the cost vector is not used to determine the temporary solutions
• Then the costs for each scenario are evaluated based on the solutions 1, 2, ...
• Finally the method returns the scenario which minimizes the costs.

So the cost parameter does NOT resolve the challenge. Sorry