The travel-time matrix: the input that decides the plan

A travel-time matrix is a table with one row and one column per location, holding the driving duration from each place to every other. It is what a routing solver actually optimises against. The road network, the traffic model and the map provider all disappear into it before the search begins, so anything wrong in the table is wrong in the plan and invisible afterwards.

Most implementations build one matrix per plan and treat it as a property of the map. It is not. It is a photograph of the network taken at one departure time, in one direction, for one vehicle class.

Every pair, both directions, and what that costs

A depot plus 400 stops is 401 nodes, which is 160,801 cells. Double the day to 800 stops and it is 641,601. The growth is quadratic, so matrix construction, not the search, is usually what makes a morning solve late. If the plan is not ready when the vans are loaded, look at the build before blaming the optimiser — the split is set out in the plan is not ready when the depot opens, and the strategies for making a daily rebuild affordable belong to caching a matrix without burning the quota.

Why A to B is not B to A

Symmetric matrices are an assumption inherited from textbook problems, and in a city they are wrong by minutes on short legs. One-way systems, central reservations that force a loop to turn round, banned right turns, gradients on a loaded vehicle and single-direction tolls all make the return trip a different journey.

A matrix is also specific to one vehicle class, because the graph itself changes with the vehicle: a heavy vehicle is barred from edges a van uses freely, which is the argument in vehicle profiles, height, weight and turn bans. A mixed fleet needs more than one matrix, and reusing the van matrix for the rigids is not a conservative approximation.

Which clock your matrix was built at

The practical question is not which is best but which one yours used, and at what departure time. Time-dependence means the honest object is a set of matrices, one per departure band, and most engines approximate it with two or three: a morning build, a midday build, an evening build. Whether you rebuild at all is part of the trade in daily optimisation versus fixed master routes.

Calibrating against what the fleet actually drove

You already own the ground truth. Every completed route is a set of observed leg durations, and the correction is worth more than a better provider because it captures your vehicles, your loads and your drivers.

1. Take arrival and departure timestamps per stop from the tracking feed. Entry and exit events give you both ends of a leg — see geofence triggers: entry, exit and dwell.
2. Subtract the time at the kerb. Observed departure minus observed arrival is service, not travel, and mixing them inflates the matrix at exactly the stops with a queue — the decomposition is in service time, the number nobody measures.
3. Bucket the residuals by corridor and hour, not by vehicle. A ratio of observed to predicted per corridor and hour band is stable enough to apply; a per-driver ratio is noise.
4. Apply the correction as a multiplier and re-measure the next week. Corridors where the multiplier exceeds about 1.3 are usually a restriction or an access problem, not traffic.

The solver is not optimising your city. It is optimising a table somebody generated at nine in the morning and nobody has checked since.

This calibration loop is a small, permanent piece of software rather than a one-off analysis, and it is the part most worth owning outright when planning sits inside a wider product build. It belongs with the rest of the routing, dispatch and optimisation plumbing in the logistics systems it feeds.

• route optimisation
• travel time
• traffic data
• dispatch