Problem Formulation Best Practices

This section describes the best practices for the tour planning problem formulation. This provides the key points and tips so that you can create the problem most effectively.

Do Not Add Pick-up Or Delivery Jobs At the Depot

In the most common delivery service scenarios, you will have one depot defined in a tour. A depot is the location from where all the jobs are picked up and where the vehicles' shifts start and end. In this case, the pick-up of the jobs from the depot is not required to be added. The solver considers the pick-ups to be executed at the depot by default, and solves the problem for the last mile delivery.

In the same way, if any pick-ups were set in the tour without deliveries, that will be considered by the solver as to be delivered to the depot in the end of the tour by default. So, there is no need to add those deliveries to the depot.

Even though, adding pick-ups or deliveries to the depot will not break the problem and it will be solved, but in terms of optimization it will have the following issues:

• The complexity of the problem will increase, which will take a longer time to solve.
• The number of jobs will increase, hence the number of locations/transactions will increase, which will increase the total cost of the problem solution.

However, there are some cases when you may need to add the pick-up jobs at the depot:

• You have multiple depots in the problem, and the vehicles can be shared across the depots.
• There are specific time windows for the pick-ups of the jobs at the depot.

Avoid Using Unnecessary Time Windows

In the most common last mile delivery scenarios, the delivery time windows are not necessary unless the customer needs to get the job done within a specific period of time. In such cases, avoid adding the time windows to the individual jobs. The vehicle's shift time window can be used to define the vehicle's time and all the jobs will be delivered during the vehicle's shift. Avoiding the time windows where it is possible, reduces the problem complexity and therefore more effective solutions can be generated quickly. Also, adding multiple time windows in case where a single time window will be enough, should be avoided as well to increase the overall performance.

Learn more about how to use time windows here.

When to Use Skills

Skills are one of the most powerful features which can be used to map particular vehicle types to particular jobs. Only vehicles with skills matching the job skills can execute those jobs. That's why skills should only be set for the vehicles when they are required for the job. The vehicle capacity and the job demand, as well as shift time should be considered when using skills. If no vehicle with matching skills has enough capacity or time left, jobs that require such skills will remain unassigned.

Learn more about how to use skills here.

How to Use Cost Parameters Effectively

The cost parameters play an important role in guiding the solver in terms of optimization. By default, the solver is designed to minimize the overall cost of all tours, not the overall tour duration or traveled distance alone. There are 3 cost parameters available for the vehicle:

• Time cost - cost per vehicle tour duration in seconds
• Distance cost - cost per vehicle tour distance in meters
• Fixed cost - the fixed cost for the vehicle per tour

The total cost of a solution is the linear combination of all 3 cost contributions above for all tours specified in the solution, i.e. all 3 cost contributions are taken into account and guide the optimization.

The cost factors are important weighting factors for the different cost contributions, guiding the optimization. They do not need to be identical to the actual real world costs. The tour object in the solution contains all statistics to calculate an estimate of the real world tour cost based on real world cost factors if this is desired.

The ratio of time cost and distance cost influences the order of stop points in individual tours served by the corresponding vehicle type. When setting for instance a high time cost and a low distance cost, roads which allow higher traveling speeds, e.g. motorways, may be preferred potentially at the expense of a higher total traveling distance, which in turn may influence the order of stop points.

When in contrast, setting a low time cost and a high distance cost, short tours will be preferred, potentially at the expense of a higher tour duration.

High fixed cost and a low time cost and distance cost, will lead to reducing the number of tours while the overall tours' distance or duration may grow instead.

Using Territories Effectively

Territories Optimization feature provides great flexibility and can be helpful in producing more practical tours with good vehicle utilization in terms of distributing the vehicles between the specific districts or areas.

Primary territory for the vehicle should be added at priority=1, and the nearby territories at a lower priority. That way, the vehicle will take the jobs from the nearby territories only if the capacity and time will allow.

If vehicles shall not be allowed to take jobs outside of their defined territories, use the strict flag set to true for the corresponding vehicle type. In this case, the vehicles will take jobs only from within the territories defined for them, even if they have remaining capacity.

Learn more about how to use Territories Optimization here.

Avoid Adding Unnecessary Fleet Profiles

Fleet profiles are used to define the routing data for the fleet. The multiple profiles should be added only if they differ from each other in the significant way. For example, you may need to add different profiles for:

• Different vehicle types (car, truck, scooter, bicycle, pedestrian, bus, privateBus)
• Specific parameters (avoid routes, options, exclude countries) for some vehicles
• Different departure time is to be defined for different vehicles for the traffic conditions

If the profiles are expected to be the same, do not duplicate them.

For example, instead of:

"profiles": [
     {
      "name": "c1",
      "type": "car"
     },
     {
      "name": "c2",
      "type": "car"
     }
 ]

Simply use:

"profiles": [
    {
      "name": "c1",
      "type": "car"
    }
 ]

The tour results will be the same, but the problem will look much more clear and the solver will perform better.

Also note that the number of profiles should be kept low because each fleet profile added in the constraints will increase the overall processing time.

Avoid Adding Unnecessary Vehicle Types

Different vehicle types should be specified only in cases when there are significant differences between them (e.g. different start and end times from the depot). In other cases, when two vehicle types are the same, it should be avoided to use two different vehicle types, and merge them into one by increasing the amount of vehicles to two. In this way, the complexity of the problem will decrease which may lead to better performance.

Relations

Since sequence and flexible relations do not validate against the constraints, you should make sure whenever possible to add jobs in those relations, that respect the constraints.

Learn more about using Relations for tour planning here.

Using Demand and Capacity

One of the basics of the effective building of the problems is using the jobs' demand and the vehicles' capacity. Those two parameters should always be considered, as all the jobs in the problem can only be assigned if their total demand does not exceed the total capacity of all vehicles.

Learn more about the capacity-demand interrelation here.

Traffic

By default, live traffic is enabled in Tour Planning whenever it is available. In some cases, this may have as a consequence that a job location is unreachable due to live traffic conditions (e.g. a road closure). In case a user would like to avoid that, there is an option to disable live traffic by setting "traffic": "historicalOnly" in the problem definition. As a result, this may lead into successful assigning of the jobs that could not be assigned with live traffic.

Unassigned Job Reasons

In some cases there may be more than one reason why a job was unassigned (e.g. unassigned due to both skill and capacity constraint). However, currently, only one possible reason for the unassigned job is shown in the solution. Also, in some cases, the reason of unassigned job may be different than the one that is actually shown. Therefore, you should try applying various fixes problem definition, not only fixing the reason that is shown, so as to assign the unassigned job.