These docs are for v1.7.0. Click to read the latest docs for v1.11.

Tweak the engine

The options object belongs in the main request body and allows you to tweak how the Routing Engine runs.

"options": {
   "traffic": "slow",
   "min_visits_per_vehicle": 5,
   "balance": true,
   "min_vehicles": true,
   "shortest_distance": true,
   "squash_durations": 1,
   "max_vehicle_overtime": 30,
   "max_visit_lateness": 15,
   "polylines": true
}

PROPERTY

VALUE

traffic

String (faster(default), fast, normal, slow, very slow)

min_visits_per_vehicle

Number

balance

Boolean (beta)

min_vehicles

Boolean (defaults false)

shortest_distance

Boolean (defaults false)

squash_durations

Number

max_vehicle_overtime

Number

max_visit_lateness

Number

polylines

Boolean (defaults false)

traffic: It's usually a good idea to simulate slower traffic to ensure you will never be late for a delivery. Estimated driving times tend to be more optimistic than in reality, and using this parameter will slow down driving speed. The default value is faster. Each step slows down the speed by 25%, so fast would be 25% slower from default, while very slow would be twice as slow.

min_visits_per_vehicle: Routific will optimize your routes by finding the minimum total travel time. This may lead to some vehicles being assigned only a few visits or not being assigned at all. This may not always be desired because some businesses prefer to spread out visits/orders across all drivers. This parameter allows you to specify a minimum number of visits for each vehicle. Note that we expect an integer value greater than 0.

balance (beta): If assigning equal number of orders across your vehicles is not enough and you want them to also have balanced driving shifts across your fleet, you can use this parameter. It should only be used in conjunction with min_visits_per_vehicle. This parameter will instruct the algorithm to keep the variance across driver shift times as small as possible.

min_vehicles: Use this parameter if you are interested to minimize the number of vehicles you'd like to use to get all the jobs done. This allows you to figure out how many drivers you should call in. When using this parameter, make sure you provide ample vehicles in the input, so all the orders can be served. The idle vehicles will be empty in the solution.

shortest_distance: By default we optimize by minimizing the total driving time and working hours. In some cases – due to time-windows – your drivers might have idle-time as it waits for the next time-window. By default we take this into account, which potentially could result in more miles driven, as we'd send the drive to another location first and coming back later. If you'd rather optimize purely on shortest distance, set this parameter to true.

squash_durations: Useful when you have many stops at the same location, which could be an apartment complex. Normally, each stop has a duration value of let's say 10 minutes, which accounts for parking and finding the entrance. If you had 6 stops assigned to a driver at the same time, it doesn't take an hour in total! Use this parameter to squash the durations of each subsequent delivery at the same address. If you set it to 1, it will squash it to 1 minute, so the total duration for the above 6 stops would be 15 minutes.

polylines: When setting this option to true Routific will respond with an encoded polyline representing each vehicle's route. For more information on decoding the polylines refer to this help article

👍

Allow lateness and overtime (new)

Sometimes you want to be a little flexible with your time-window constraints. Normally, when you set time-window constraints, the Routific algorithm will consider them as hard requirements. Even if Routific thinks you'll be 1 minute late, it will return it in the unserved object.

If you need to schedule all your stops, and cannot afford any unserved – even if it means being late or working your drivers overtime – then you can use these two options parameters:

max_vehicle_overtime: This sets the maximum number of minutes a driver is allowed to work overtime. Note that if all stops can be served within a normal shift, that will always be preferred.

max_visit_lateness: This sets the maximum number of minutes you can be late for any of your stops. We only schedule something late if it is going to be unserved otherwise. Also note that the algorithm will minimize and spread out lateness as much as possible; the algorithm favors 5 orders being late by 2 minutes over 1 order being late by 10 minutes.

When you use these options, the output in the response will include new fields:

{
  ...,
  "total_visit_lateness": <minutes>,
  "num_late_visits": <number>,
  "total_overtime": <minutes>,
  "vehicle_overtime": {
    "vehicle1": <minutes>,
    "vehicle2": <minutes>
  },
  "solution": {
    "vehicle1": [
      ...
      {
        "location_id": "visit1",
        "too_late": true,
        "late_by": <minutes>
      },
      ...,
      }
    ]
  }
}

There are 4 new fields in the response:

  • total_visit_lateness indicates the actual total number of minutes the solution is violating the time-windows
  • num_late_visits is the count of visits that have been scheduled late
  • total_overtime is the total number of minutes your drivers are working overtime
  • vehicle_overtime is an object that shows a break-down of the number of minutes each driver is working overtime
  • In the actual solution object, on the stops that are late, we'll return the number of minutes it was late_by.