Weighted Objective Functions — An Interactive Transport Planning Model
Change what the planner is told to value, and watch the “best” route plan change with it. An objective function is a policy decision disguised as arithmetic.
Open simulation →Simulation
Four ways of deciding which orders belong together, on the same set of orders. The grouping you choose constrains every route that follows.
Discussions about transport optimisation almost always start with the route, which is one step too late. Before anything can be routed, something has to decide which orders belong together. Get that grouping wrong and no amount of clever sequencing will rescue the plan, because the algorithm is now optimising the order of stops that should never have shared a vehicle.
“Belonging” sounds like a geographic question, and partly it is. But two drops a mile apart may belong to entirely different plans if one needs a tail-lift, one opens only between 06:00 and 08:00, and one is on a contract that forbids consolidation. Clustering in transport is really similarity across several dimensions at once, and different algorithms disagree about what similarity means.
This simulation runs four clustering methods over the same generated order set so you can compare their output directly.
Switch between the four methods and watch the group boundaries redraw:
K-Means commits to a fixed number of groups. You tell it you want six territories and it will produce six, whether or not the data contains six natural clusters. It is predictable and easy to plan resource against, which is exactly why operations teams like it — and it will happily split a genuinely dense cluster in half to hit the number you asked for.
DBSCAN does the opposite. It finds dense communities wherever they exist and labels everything else as noise. Raise the radius and separate clusters merge; raise the minimum-neighbours threshold and marginal drops get dropped as outliers. Those outliers are the interesting part: in a real operation they are the awkward rural deliveries that ruin an otherwise efficient day.
Hexbin ignores cluster shape entirely and imposes a fixed spatial grid. Crude, but genuinely useful for capacity planning because the geography stops moving between runs.
Graph partitioning connects orders within a radius and then cuts the resulting network at its weakest links, which tends to respect natural travel corridors better than distance alone.
Then change the Similarity basis slider from Mostly geography toward Mostly Earl problem type. The map barely moves but the groupings change completely, because you have redefined what makes two orders alike. Use Regenerate to confirm the pattern holds on fresh data rather than one lucky layout.
There is no correct clustering method, only a method whose assumptions match your operation. K-Means suits a fixed fleet with stable territories. DBSCAN suits networks with genuine density variation and a tolerance for exceptions. The decision belongs upstream of the routing engine, and it is usually invisible in the product — which is why it is so rarely revisited.
Interactive simulation
Earl has a list of people, places, debts, mistakes, and awkward one-off jobs. Before he can decide the route, he has to decide what belongs together. This demo shows four common grouping ideas: K-Means, DBSCAN, graph partitioning, and feature-vector similarity.
The map is deliberately fictional, so it does not depend on live map tiles. The important lesson is that clusters are not discovered in a vacuum. They depend on what the model treats as similar.
A hexbin groups nearby dots into hexagonal cells and counts how many items fall near each cell. It is useful when raw points overlap or when the viewer needs to see density before seeing a final cluster. In this demo, brighter hexes mean more Earl list items are concentrated in that area.
Product lesson: before routing, planning, or optimisation starts, density often tells you where the operational pressure is.
The lasso is a visual wrapper around the members of a cluster. It is not a legal boundary, a delivery route, or a precise service area. It simply helps the user see which dots the algorithm currently treats as one group.
Product lesson: cluster boundaries are explanations. They help planners challenge whether the grouping makes operational sense.
In DBSCAN, a point becomes noise when it does not have enough similar neighbours within the selected radius. These are the awkward one-off items: too remote, too unusual, or too weakly connected to belong naturally to a group.
Product lesson: not every order should be forced into a group. Some work needs exception handling.
Geography is only one possible meaning of “near”. Similarity can also include effort, priority, customer type, delivery window, risk, temperature regime, vehicle constraints, or the type of problem being solved.
Product lesson: changing the features changes the clusters. That is why discovery matters before algorithm selection.
Change one input at a time, run the model, and compare the result with the starting state. Then repeat the experiment with a different constraint or strategy so you can see which relationships drive the outcome.
Look for trade-offs, thresholds, feedback loops, and points where a locally attractive decision produces a worse system-wide result. The simulation is intended to make the article's idea observable, not to predict a real operation.
This is a deliberately simplified model. It omits the data quality, exceptions, human judgement, and operational constraints of a live system, so treat its behaviour as an illustration of a mechanism rather than as a planning recommendation.
Read: Earl learns about belonging →
Explore the complete Transport Optimisation Explained series