The Cost of Clustering in Route Optimization

Route optimization software quality is not only about the operating cost but also the visualization of the generated route plans. The way the route plans appear is crucial since your drivers will be navigating through them daily, and their feedback is significant. If you've been experiencing difficulties with route optimization software that produces complicated routes and has a low acceptance rate among drivers, LogisticsOS is here to assist you.

What is a good routing plan?

Do the routes generated by the route optimization software make sense for dispatchers and delivery drivers? Are they mathematically sound? Asking for opinions from drivers, fleet managers, and computers about the same route plan will result in varying answers. The route plan that appears visually pleasing may not necessarily be the most efficient in terms of mileage. To determine the difference in numbers, let's explore together using LogisticsOS route optimization API.

The numbers and the looks

We’ll begin by comparing different parameters using our route optimization API for a small-sized route optimization. The example consists of 500 orders to be delivered the next day, with 11 drivers in the fleet. The goal is to minimize the total travel time while dispatching all drivers. First, we solve the example with high_quality_cluster set to false. The result is as follows:

  "solver_time": "17981ms",
  "plan_summary": {
    "distance": 1018311.0,
    "total_time": 4224.533333333334,
    "travel_time": 1724.5333333333333,
    "wait_time": 0.0,
    "late_time": 0.0,
    "service_time": 2500.0,
    "num_routes": 11,
    "unassigned": 0,
    "assigned": 500,
    "assigned_pairs": 0,
    "average_speed": "35.42 km/h",
    "total_cost": 4224.533333333334
  }

After 13 seconds, the solver returned an optimized route plan that appears satisfactory and without any convoluted routes. However, the clustering is not flawless, as there are two instances of crossover between routes. While a fleet dispatcher might find this plan acceptable, we should ask ourselves if there is room for improvement. Let's now solve the same example with high_quality_cluster set to true. The resulting solution is as follows:

  "solver_time": "17772ms",
  "plan_summary": {
    "distance": 1075631.0,
    "total_time": 4276.116666666667,
    "travel_time": 1776.1166666666666,
    "wait_time": 0.0,
    "late_time": 0.0,
    "service_time": 2500.0,
    "num_routes": 11,
    "unassigned": 0,
    "assigned": 500,
    "assigned_pairs": 0,
    "average_speed": "36.33 km/h",
    "total_cost": 4276.116666666667
  }

Now the cross overs are gone, but the numbers goes up. 5.5% increased mileage and 3% increased travel time. The trade off is, the plan visually, looks more optimized. Interesting, isn’t it? Now if you ask a fleet manager which route plan, he/she prefers, the answer probably will be the latter since the drivers may like it better. But if you present this to the CEO or the owner of the company, the answer might be the former, since cost does matter to the company owner.

Let’s take another look at a middle-sized route optimization example. This example contains 3719 orders. The fleet has 50 vehicles in total. Goal is to minimize travel time while using minimal number of vehicles. We first set high_quality_cluster to false, and send the JSON request to our optimization API.

  "solver_time": "197189ms",
  "plan_summary": {
    "distance": 7011.168,
    "total_time": 12382.85,
    "travel_time": 8664.85,
    "wait_time": 0.0,
    "late_time": 0.0,
    "service_time": 3718.0,
    "num_routes": 44,
    "unassigned": 0,
    "assigned": 3718,
    "assigned_pairs": 0,
    "average_speed": "48.67 km/h",
    "total_cost": 12482.850000000002
  }

The solver took approximately 197 seconds to return an optimized result with high_quality_cluster set to false. It took slightly longer to optimize than the previous example, but the time is still reasonable. In this solution, the solver utilized 44 out of 50 vehicles, and there are more than a dozen instances of crossover between different routes. Now, the question is, what do we sacrifice by enabling the "magic button"? We can explore this by solving the same example again with high_quality_cluster set to true.

  "solver_time": "189975ms",
  "plan_summary": {
    "distance": 7186.1,
    "total_time": 12563.2,
    "travel_time": 8845.2,
    "wait_time": 0.0,
    "late_time": 0.0,
    "service_time": 3718.0,
    "num_routes": 44,
    "unassigned": 0,
    "assigned": 3718,
    "assigned_pairs": 0,
    "average_speed": "48.74 km/h",
    "total_cost": 12563.199999999999
  }

The solver returned the result in approximately 190 seconds, utilizing 44 vehicles when high_quality_cluster was set to true. Comparing this result with the previous one, we can observe an increase of 2.5% in total mileage and 2.0% in total travel time. However, the benefit of enabling high_quality_cluster is a cleaner and more visually appealing route plan, which may be advantageous for dispatchers.

(Before and after)

Summary

In this session, we have explored the tradeoffs of using the high_quality_cluster option with LogisticsOS route optimization API. Ultimately, the decision-makers will need to weigh the benefits of a visually appealing route plan against the increase in total mileage and travel time. LogisticsOS route optimization API offers various solver options, providing flexibility for dispatchers to plan their routes. Stay tuned to learn more about our platform and its capabilities.

About LogisticsOS

LogisticsOS is the most powerful route optimization system on the market. Our flexible, hosted route optimization and planning/replanning APIs require no knowledge of optimization techniques. High-quality results are returned within seconds— even at scale. From time reduction and vehicle capacity to depot automation and cost customization, our feature-rich software can create the efficiency and cost-savings that you need. Contact us today for a free product demo.