Basic Route Optimization
In this example we will play around with basic constraints offered in NextBillion.ai’s Route Optimization Flexible API. The constraints covered here are time windows of jobs, vehicle shift timings, skills needed to complete the tasks and capacities involved to carry out pickup/delivery type tasks. We specifically demonstrate how the time windows are used to determine the job sequence & assignment and if the time windows are such that they could not be honored then the task would be left unassigned. We will also see how the starting and ending stops for the vehicle are configured when they are assigned to depots versus when they are not assigned to depots.
Get Started
Readers would need a valid NextBillion API key to try this example out. If you don’t have one, please contact us to get your API key now!
Setup
Once you have a valid API Key, you can start setting up the components to be used in this example. Let’s take a look at them below.
Jobs & Shipments
We start by defining 5 jobs and 2 shipments. For these tasks we add:
- A unique identifier for each task
- Location indexes for each task
- Specify the schedule of tasks. This is done by adding time windows within which a task must be completed. We have added a 15 min time window for all tasks for the sake of simplicity, but the Route Optimization Flexible API is fully capable of handling much complex task schedules.
- Skills needed to perform each task
- Pickup and Delivery amounts for all jobs
- The actual time taken to complete the task once the driver/vehicle is at the task’s location i.e. the service time for each task. We have added a uniform
service time of 2 mins for all tasks, but the readers can use varying service times instead.
Let’s take a look at the jobs
JSON after the above properties are configured:
Depot
Next, we add a depot that we want to assign to one of the vehicles. The assigned vehicle would start from the depot’s location. We assign an ID and a location_index
to the depot:
Vehicles
Next, we add 2 vehicles that are responsible for fulfilling the tasks within the defined constraints. To describe the vehicles and their properties we add:
- A unique ID for each vehicle
- Vehicle shift time or the time window
- Capacity to denote the amount of load that the vehicle can take
- Vehicle’s depot, if any.
- Start_index to denote the point from where the vehicle would start. It is important to highlight here that we need to add a start point for all vehicles either by specifying the
start_index
or by assigning them to adepot
. In this example, we cover both cases and define astart_index
for one vehicle and assign adepot
to the other. - Skills of the driver or the vehicle
- We are not mentioning any cost for the vehicles. Please take a look at the Vehicle Cost example to know more about its usage.
Once the vehicle and their properties are defined, the resulting vehicles
JSON is:
Locations
And now, lastly we define the locations
object and add all the locations used in the problem along with a valid id
. The locations
object with all the points used in this example:
Optimization POST Request
Bringing all these components together to create the final POST request that we will submit to the optimizer.
Optimization POST Response
Once the request is made, we get a unique ID in the API response:
Optimization GET Request
We take the ID and use the Optimization GET request to retrieve the result. Here is the GET request:
Optimization GET Response
Following is the optimized route plan:
Following is a visual representation of the initial locations of tasks, vehicles and the routes suggested after optimization as per the given constraints
Analyzing the Solution
Looking at the result we can observe some interesting insights:
-
summary
section:- We get an overview of the overall result with a total distance of 33584 meters covered within a total duration of 4162 seconds of driving time to complete all the assigned tasks.
- There are 2 routes with a total cost of 4162. This cost is in seconds as we did not explicitly specify any
travel_cost
, so the solver went with the default setting ofduration
. - Other fields in summary tell us that there are 2 tasks (belonging to the shipment with ID 2) which remained unassigned, total service time of all the assigned tasks, total waiting_time for the assigned tasks and other details.
-
routes
section:- Gives step wise and route wise details of each route along with the vehicle which is going to cover each of them.
- For each route we get details of the steps involved, ID of the vehicle which is going to cover the route, cost of the route, distance of the route and duration needed to cover it, encoded geometry of the route, service and setup times, pickup/delivery amounts involved in the route among other details. Please note the
cost
value is based on thetravel_cost
value provided in the input request. In our example, the cost is calculated based on theduration
, hence all costs in the solution are in seconds. Consequently, we can see thatcost
andduration
of both routes are the same as no vehicle costs were involved. - For each step we get details like - step type, arrival time at the location of the step, service time, priority, setup time, location, ID of the job/shipment among others.
- We can see that vehicle 1 is taking care of job 1, 2 & 4 while vehicle 2 is assigned to fulfill jobs 3 & 5 along with the shipment 1 pickup and delivery. This is because of the skills needed to complete those jobs. Take a look at the skills specified for jobs and 1,2 and 4 and that specified for vehicle 1.
- The vehicle 1 starts from the provided start point but the vehicle 2 start from the depot location to which it was assigned to
- On analyzing the routes further we can see that vehicle 1 waited for more than 3 plus hours to complete jobs 1 & 4. This is because vehicle 1, after completing job 2, arrives at the location of job 1 almost an hour earlier than scheduled time to start job 1. The vehicle then waits for the start of the time window when job 1 can be completed. Same happens with job 4 for which the vehicle arrives almost two and half hours earlier than the scheduled start time of the job. If the high waiting time is a concern, we recommend you to look at the max_waiting_time example to understand how you can cut down on the vehicle’s waiting time.
unassigned
section gives the details of the tasks that remained unassigned along with the reason for it. We can observe that this task was scheduled outside thetime_window
of vehicle 2 and hence remained unassigned. The shift timing of the other vehicle did also not cover the task’s scheduled time, but please note that vehicle 1 could not have fulfilled the task anyway because of the missing skills.
As we witnessed, NextBillion.ai’s Route Optimization Flexible API closely adheres to the time windows, skill constraints of the tasks and returns the best possible routes while keeping other factors into consideration. We encourage you to go ahead and try out different configurations of locations, time windows, skills, number of tasks and explore the powerful Route Optimization Flexible API.
We hope this example was helpful. Check out some more use cases that Route Optimization Flexible API can handle for you!