From an OpenStreetMap graph to a queue-by-queue forecast.

1 · The pipeline at a glance

The model runs as a six-stage pipeline. Each stage produces an artefact the next stage reads, and each artefact is inspectable on its own:

1. Ingest — the OpenStreetMap extract becomes a directed multi-graph of links, junctions, turns and signal heads.
2. Demand — census small-area populations become a synthetic set of origin–destination trips with departure times.
3. Assign — trips are routed onto the network as time-dependent agents.
4. Load — agents are advanced second by second; queues build on links and discharge at signals.
5. Calibrate — modelled flows are compared against observed counts; routing weights and discharge parameters are tuned until the model passes a GEH < 5 bar on calibrated links.
6. Record — per-link counts and per-agent positions land in a structured run log that you can scrub, A/B and export.

The same graph, the same population and the same seed always produce the same run. Change one of those and re-run, and the difference is attributable.

2 · Ingest the network

The network model comes straight from an OpenStreetMap extract. Every way, every node, every turn restriction lands in the road graph unchanged where OSM is unambiguous; defaults are applied only where tags are missing.

What's lifted from OSM, directly

• Link geometry — the polyline of each road centreline and its length.
• Highway class — motorway, primary, residential… controlling default speed and capacity.
• Lane counts per direction (lanes:forward / lanes:backward) where tagged.
• Speed limits per direction (maxspeed), with sensible class-based defaults when missing.
• Turn restrictions — no_left_turn, only_straight_on etc. — lifted from OSM relations.
• Signalised junctions — highway=traffic_signals nodes; default phase plans where no detailed timing is tagged.
• Bus/cycle lanes — class-restricted lanes (bus=designated, cycleway=*).
• One-way, roundabouts, access restrictions.

What the ingester adds

On top of the raw OSM data, the ingester resolves the graph: it splits each way at every junction node, builds a turn-permission lookup at every signalised intersection, and audits the result. Common problems — orphan ways, dead-end ramps that should have been linked, inconsistent oneway tags — show up in an audit report that you can fix at source in OSM and re-ingest.

3 · Synthesise the demand

A road model is only as good as the trips it loads. Urbanetric generates a synthetic population from open small-area statistics rather than asking you to provide a hand-built origin–destination matrix.

From census to agents

1. Census small-area populations are sampled into individual synthetic households at the small-area level.
2. Each synthetic person is assigned an activity pattern (home → work, home → school, home → shop, home → leisure) based on age, employment and household composition.
3. Activity locations are sampled from employment statistics for work, from school/college rolls for education, and from gravity-style attractors for other trip purposes.
4. Mode choice splits trips into vehicle (the modelled population) and other (walk, cycle, transit) using observed mode shares.
5. Departure times are drawn from observed time-of-day profiles for each trip purpose, producing an AM peak, an inter-peak and a PM peak that emerge from demand rather than being dialled in.

Why a synthetic population beats a fixed O–D matrix

A fixed origin–destination matrix is opaque: change a land-use assumption and you have to rebuild it. A synthetic population is the opposite — it's the agents themselves, with reasons for travelling. That means you can ask what if we add 200 housing units here and the model will route their plausible trips onto the network, not just multiply a row in a matrix.

4 · Route and load the network

Routing is shortest time, not shortest distance — an uncongested longer route beats a congested shorter one. But the mechanism that produces realistic route choice isn’t a within-day “sat-nav redirect”; it’s a co-evolutionary loop across multiple iterations of the same day, in the lineage of MATSim’s ChangeExpBeta replanning.

One day, simulated many times

A scenario is run as a sequence of full simulated days. In each day: every agent follows a route that was chosen before the day began, departs at its planned time, and experiences whatever queues and signals the rest of the population creates around it. Travel times, queue lengths and arrival times are recorded link-by-link.

Between iterations the simulator replans: each agent’s executed plan is archived into a memory of prior plans, scored against the experienced travel times, and a fraction of the population is selected to innovate — either re-routing against the previous day’s experienced cost surface, shifting departure time, or (where multi-modal) reconsidering mode. The remaining agents stochastically pick from their plan memory, weighted toward the higher-scoring plans (the ChangeExpBeta rule).

Convergence

Across roughly ten iterations the population settles toward a stable pattern in which no large fraction of agents has a materially better plan available than the one they ran with. That stable pattern is the system’s approximation of user equilibrium — the mechanism by which a closed street produces a re-routed network the next iteration, rather than mid-day. Convergence is monitored as the standard deviation of agent scores across iterations.

Within-day exceptions

One narrow within-iteration re-route exists: a watchdog that re-plans an agent’s remaining route if it has been stalled at the back of a saturated downstream link for more than thirty simulated minutes. This is a corrective for pathological gridlock, not a model of normal driver behaviour — without it, a single hot arterial can sink every agent routed through it before the next iteration’s replanning gets a chance to spread load.

5 · Move and discharge, second by second

Once an agent is on a link, it advances by the link's free-flow speed minus the back-pressure of the queue ahead of it. When the link's downstream end is a signalised stop-line, the agent waits there until its phase is green and its turn movement is permitted.

The link discharge model

The model is mesoscopic: vehicles are individual agents, but they aren't simulated lane-by-lane with steering and gap acceptance. Each link has a per-direction capacity (a function of lane count, speed limit and class). The capacity sets the maximum rate at which vehicles can leave the link's downstream stop-line; whatever exceeds that rate backs up as a queue.

Signal discharge

Signalised junctions release vehicles by movement (left, through, right) on the active phase. Banned turns are not released. Where detailed signal timings are available the model honours them; where they aren't, a class-based default phase plan is applied and flagged in the audit so you know which junctions are running on defaults.

Network re-routing around an edit

When you make an edit in the scenario editor — close a street, add a lane, ban a turn — the network changes from that iteration onwards. Agents in the current iteration continue to obey the route they committed to; the next iteration’s replanning sees the new network and re-routes around the edit naturally. The result: the queue forms where it would form, not where you tell the model to put it.

6 · Calibrate against the road

A demand model and a network model both contain assumptions. The only honest test is whether the resulting flows match the road as it actually performs.

The calibration loop

1. Run the baseline for the reference period (typically a weekday AM/PM peak with school in session).
2. For every link with an observed count, compute the modelled-vs-observed GEH statistic.
3. Adjust assignment weights and discharge parameters on links and junctions where the model is most out of line, prioritising the network's high-flow corridors.
4. Re-run, re-score, repeat until the proportion of calibrated links inside the GEH < 5 acceptance band hits the target.
5. Lock the calibrated parameters into the scenario base; from then on, scenario edits are tested against this calibrated baseline.

The validation page documents the count sources, the acceptance thresholds and the calibration scorecard in full. See validation →.

7 · Record, replay, compare

Every run is recorded in full. The run log captures, for every simulated second, the position of every agent and the count + queue length on every link. Two outputs fall out of that log:

Per-link metrics

Aggregated to the time intervals a transport assessment cares about (hourly link flow, peak-hour journey time on key corridors, total vehicle-kilometres), and exportable as CSV.

The replay

The full second-by-second agent positions, replayable on the map. Scrub, pause, jump to a junction at a specific time. Two scenarios can be replayed side by side to see where the difference lives, not just whether the headline number moved.

Determinism

Every run takes a seed. The same seed against the same inputs produces the same run, bit for bit. That means a reviewer can re-run your scenario and see the same result you did — the foundation of an auditable forecast.

8 · What the model does not pretend to do

Urbanetric is a network-level tool — it answers questions about how a whole-city pattern changes under an intervention, not how an individual junction performs at the steering wheel. We are explicit about its scope so you can choose the right tool for each question:

• It does not simulate individual driver behaviour at the steering-wheel level (lane changes, gap acceptance, weaving). For that you want a microsimulation package (Aimsun, VISSIM, SUMO).
• It does not design signal timings. It can tell you whether retiming a junction has a network-wide effect, but you will want a signal-optimisation tool (LinSig, TRANSYT) to author the plan.
• It does not model individual pedestrian movement or active-mode infrastructure dimensioning — cycle and pedestrian demand are tracked at a network level, not a kerb level.
• It does not replace ground-truthing for sensitive design decisions. The model is calibrated and reproducible; for a planning permission battle you may still want supplementary surveys.

What it does do is answer the strategic-level question every scheme has to answer: at a whole-city level, does this change help or hurt, and where does the queue end up instead?