Transport & logistics Usage scenario

Delivery route planning based on addresses, time windows and truck capacity

Computing the routes of a 12-truck fleet based on addresses, time slots and capacity, with OR-Tools and OpenStreetMap, and recomputing after a breakdown.

Describe your project See the solution

Project overview

This scenario illustrates what we build; it is not a client reference.

This scenario shows how a transporter who prepares its routes by hand every morning can have them computed by a tool. You enter the addresses, the delivery slots and the capacity of each truck; the tool proposes the routes. If a truck breaks down, you run the calculation again with the remaining trucks.

Client challenges & requirements

A transporter with 12 trucks delivers to around 40 customers a day between Conakry and its outskirts. Every morning the operations manager splits the deliveries between drivers from memory, with a notebook and his knowledge of the city. He takes into account what he can: customers who close at noon, the truck that cannot fit in a given street, the weight of the parcels.

When an urgent order arrives at 9 am or a truck breaks down, he redoes everything by phone. Two drivers cross paths in the same neighbourhood, a customer who expected a morning delivery is served at 4 pm, and nobody knows how many kilometres the fleet drives for nothing.

Main objectives

Compute the day's routes from the addresses, the time slots and the capacity of the trucks

Respect the time windows promised to customers and the maximum load of each vehicle

Recompute the routes during the day when a truck breaks down or an urgent order arrives

Let the operations manager adjust a route by hand before validating it

Project solution

We start with the data

Customer addresses are geocoded once on OpenStreetMap and corrected by hand where the map is incomplete, which is common in outlying neighbourhoods. An OSRM server computes travel times between all points. A Python engine with OR-Tools then solves the routing problem with the transporter's constraints: time windows, capacity in weight and volume, departure time from the depot, driver breaks.
The manager sees the proposed routes on a map, moves a delivery from one truck to another if he knows a reason the tool does not, then validates. If a truck breaks down, he removes it from the fleet and runs the calculation again: the remaining deliveries are spread over the other trucks. The tool relies on the deliveries already entered in the driver app and requires no double entry. The engagement starts with a workshop with the operations manager to list the real rules of the operation before writing a line of code.

Indicators to track

Kilometres driven per delivery
Share of deliveries made within the promised slot
Time spent each morning preparing the routes
Number of routes adjusted by hand after the calculation

Tech stack

Optimisation: Python Google OR-Tools
Données géographiques: OpenStreetMap OSRM PostGIS
API et interface: FastAPI Laravel Leaflet
Database: PostgreSQL
Exploitation: Docker Hébergeur choisi avec le client

Frequently asked questions

That is the first job. Known addresses are geocoded on OpenStreetMap; the others are pinned by hand once on the map, often with the help of the driver who knows them. A corrected delivery point is remembered for the following routes.

Yes. The tool proposes, the manager decides. He can move a delivery, assign a driver to a customer he knows well, or lock a route. His corrections are then used to adjust the rules of the calculation.

No, but the two work well together. Without the app, the computed routes are printed or sent to drivers by WhatsApp. With the app, they land directly on their phone and the real position of the trucks feeds the recalculation.