Vehicle profile: why a car route and a truck route are different networks
In short
A vehicle profile is the set of physical and legal attributes — height, width, length, gross weight, axle weight, goods class — that a routing engine applies to the road graph before it searches. Edges failing the filter are removed or made expensive. That is why a car route is not a conservative version of a truck route: it is a path through a network the truck cannot legally use.
Key takeaways
- A profile filters the graph before the search. It is not a warning layer drawn on top of a finished route.
- Whether restrictions are honoured is a data-coverage question, not an algorithm question.
- Gross weight and axle weight are separate limits. Passing one and failing the other is common on old structures.
- Restriction coverage is thin in many markets, so the local knowledge in drivers' heads is an asset worth capturing.
- One matrix per profile. Reusing the van's travel times for a rigid understates every leg it cannot drive.
A vehicle profile is a description of the vehicle that a routing engine turns into a filter on the road network: how tall, how wide, how long, how heavy in total and per axle, and what it is carrying. Edges that fail any test are removed from the graph, or given a cost high enough that the search avoids them. The route is then found in what remains.
That ordering is the whole point. The filter runs before the search, not after it, so a profile is not a set of warnings painted onto a finished route. If a system offers restriction alerts on a route it already computed, it does not have a profile; it has a checklist that arrives too late to change anything.
Six attributes, and what each one deletes
| Attribute | What it removes | Failure when it is missing |
|---|---|---|
| Height | Low bridges, tunnels, canopies, height barriers | A bridge strike, a closed road and a queue behind the vehicle |
| Gross weight | Weight-limited bridges and streets under weight orders | A breach the driver carries personally, discovered at the sign |
| Axle weight | Structures rated per axle rather than per vehicle | Passes the gross-weight test and still cannot legally cross |
| Length and turning circle | Turn bans, tight junctions, dead-end approaches | A route that is legal and physically undriveable at one corner |
| Width | Narrow lanes, width restrictors, bollarded streets | A vehicle that fits the map and not the street furniture |
| Goods class carried | Tunnels and zones closed to specified goods | A refusal at the portal and a long unplanned diversion |
Because the graph differs per profile, the durations differ too. A mixed fleet needs one travel-time table per profile, and reusing the van's numbers for the rigids quietly understates every leg where the rigid must go the long way — the property described in the travel-time matrix under every route.
Restriction data is a coverage problem, not an algorithm problem
Every serious engine can filter a graph. What separates them is whether the graph carries the restrictions in the first place, and that varies enormously by country and even by city. Commercial truck-routing datasets are well populated across much of North America and Western Europe. Elsewhere the coverage thins fast, and open map data carries height and weight tags only where a mapper has entered them, which is disproportionately on trunk roads and disproportionately not on the residential street with a 3-metre railway arch.
India is the clearest case. Goods-vehicle access in most large Indian cities is governed by local, time-of-day entry restrictions issued and revised by city traffic authorities. Those orders are published locally, change with events and construction, and are not in any map layer you can license. Confirm the current rules for a city against the issuing authority rather than against the routing engine, and treat the engine as unaware of them until you have loaded them yourself.
Building the restriction layer you actually need
Wherever coverage is thin, the missing data already exists in the drivers' heads and is lost every time one leaves. Capturing it is unglamorous and it compounds.
- Give drivers one control that reports an obstruction with a position and a photograph, and nothing else to fill in. Anything longer will not be used on a wet afternoon.
- Convert each report into an edge-level restriction with a type and a limit, reviewed by a planner. Free-text notes are not a routing layer.
- Apply the layer as an overlay on the provider's graph so it survives the next map update, and version it so a wrong entry can be rolled back.
- Re-check seasonally. Arches do not move, but weight orders, market closures and roadworks do, and a stale restriction removes a road that reopened months ago.
- Feed confirmed restrictions back to the map provider or to the open map where the licence allows it, so the next update contains them.
Turning free-text driver reports into structured restrictions is a good fit for automation with a review step, and the same review-before-apply discipline described in AI in logistics operations applies: a proposal a planner confirms, never a silent edit to the network.
What a wrong profile looks like from the office
- Stops that keep coming back unassigned in one postcode, because every approach to them is filtered out for that vehicle — one of the causes to isolate in the solver dropped stops and called it done.
- Drivers who deviate from the plan on the same leg every day, then rejoin it. That is a restriction the engine does not know about, reported by behaviour instead of by form.
- Long stationary periods away from any customer. Separating a reversing manoeuvre from a break needs vehicle state, and how little that flag proves on its own is covered in ignition on, off, and what it proves.
- A round that only works when one particular driver runs it. Local knowledge is compensating for the profile, and the round breaks the week they are on leave.
That last symptom is also an argument for stability. Where restriction data is weak, fixed territories preserve the knowledge that keeps routes drivable, which is one of the real reasons to weigh daily optimisation against fixed master routes as part of any routing and dispatch design for a logistics operation.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
What is a vehicle profile in truck routing?
It is the set of vehicle attributes a routing engine uses to decide which roads are usable before it searches for a route: dimensions, gross and axle weight, and the class of goods carried. The engine removes or penalises every road segment the vehicle may not legally or physically use, then plans inside what is left.
Why does consumer navigation send trucks down banned roads?
Because it is planning for a car and has no reason to load truck restrictions at all. The result is not a slightly risky version of a truck route; it is the fastest path through a network that includes roads closed to the vehicle. Treating it as a conservative approximation is the mistake behind most bridge strikes involving hired vehicles.
Do we need a separate profile for every vehicle in the fleet?
No. Group vehicles into a handful of profiles that share binding limits, typically van, 7.5-tonne rigid, heavy rigid and articulated, plus a separate profile for anything carrying restricted goods. More profiles mean more travel-time tables to build and maintain, so add one only when a real restriction separates it from an existing group.
Can we add our own restrictions to a commercial routing engine?
Most engines allow custom avoidance areas or edge penalties, though the granularity varies from a crude polygon to a specific segment with a limit. Ask for segment-level restrictions with a type and a value during selection, because polygon avoidance is a blunt instrument that also removes the legal roads inside the shape.
- truck routing
- restrictions
- route optimisation
- fleet data
The work behind this page
Builds from our portfolio that this page draws on.
Read next
- The travel-time matrix: the input that decides the planThe solver never sees a road. It sees a table of durations between every pair of stops, and every mistake in that table becomes a plan that cannot be driven.definition
- The plan came back complete and forty stops are not in itA solver that reports success while leaving forty stops unassigned is answering a different question from the one you asked. Relaxing one constraint family at a time tells you which.diagnostic
- Service time: the minutes at the kerb that decide the planEvery route plan carries an assumption about how long a stop takes. In most fleets it is one number, applied everywhere, and nobody has ever measured it.definition
- The optimiser made a plan and the desk rebuilt it by hand before eightSystematic override is not resistance to change. It is an unwritten requirements document being typed into your software every morning, one drag-and-drop at a time.diagnostic
- The route crosses itself twice and the driver has already resequenced itA route that doubles back is either obeying a constraint the map cannot draw or genuinely bad. Only one of those is fixed by re-optimising; the other is fixed by explaining.diagnostic
- The solve still has not finished and the first van is loadedMost teams tune the solver and wait longer. In production systems the matrix is usually the slow half, and no search parameter touches it.diagnostic
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation