Transport Modelling — Calibrated Base Models, Place Names, Monte Carlo

September 19, 2026

Transport Modelling now builds a calibrated base model of a district rather than an illustrative what-if. Name a place and a period and Alfrada OS builds the network, generates demand from population and cited trip rates for every mode, times the signals, calibrates against observed journey times or your traffic counts, runs your scheme against that base, and hands back a 3D replay and a validation report. Describe an uncertain future and it runs a Monte Carlo over that model and gives you a range instead of one number. It is still Eclipse SUMO underneath, still experimental — tagged that way wherever it appears — and honest about what has and has not been checked.

What you can do

• Start from a place name. "Bedford town centre, UK" or "Dubai Marina" is enough: the tool looks the place up, downloads the map and builds everything else from it. Coordinates still work. The result says which place it resolved to, so a wrong town is obvious before you read a number.
• Watch the world model being built. The chat card names the location, then walks through the stages: locating, network, demand, signals, calibration, simulation, and Monte Carlo when you asked for one.
• Base model only, or base plus scheme. Interventions are now optional. No scheme = build, calibrate and validate the base.
• Demand from public data. Residents from ONS Census 2021 (England and Wales) or WorldPop 100 m elsewhere × regional trip rates, mode shares, trip lengths and start-time profiles from published surveys (NTS 2024, ODiN, MiD 2023, NHTS 2022) → cars, vans, HGVs, cyclists and pedestrians by zone, with boundary gateways for external and through traffic. Every figure carries its source in the report; where none is public (most of the GCC) it is labelled an assumption.
• Buses. From OpenStreetMap route relations at an assumed headway, or a GTFS zip you upload (gtfs_file) for real timetables.
• Signals by rule. Signals sit where OpenStreetMap maps them; each junction is classified and timed by Webster's method from the routed demand inside national rules (minimum green, amber, maximum cycle), running actuated. Everything else gives way. list_junctions shows every stage; signal_plans loads your real plans.
• Calibration without leaving the tool. A saturation-flow bench sets driver headway to the regional capacity target. Then probe vehicles drive corridor routes and demand is scaled until their times sit inside observed typical journey-time ranges, fetched automatically inside the tool. Your own journey_times override them.
• Validation against your counts. traffic_counts fit vehicle routes to your counts (SUMO routeSampler) and report GEH per site against the 85% < 5 criterion; journey times then validate independently.
• Your survey files, read directly. Upload counts (CSV or Excel — per-site or 15-minute bins, totals or vehicle classes, sites by coordinates, OSGB grid reference or road name), a signal plan sheet or a journey-time survey and name the file. check_data shows what landed on the network and what did not, with the reason for each miss, before any simulation runs. Unmatched rows are skipped, never guessed.
• Network check. The report says how much of the network rests on tagged lane counts versus road-class defaults, lists arterials with assumed lanes (with Street View links for a person to open), flags corridors where an independent router disagrees with the model's path, and applies country driving side and lane defaults.
• Uncertainty, in your own words. Say "traffic could grow 5–20% by 2031, probably about 10", "there's a one-in-three chance the depot brings 40% more HGVs" or "what about wet winter mornings?" and Alfrada turns it into distributions — triangular, uniform, normal or discrete — over motor, car, van or HGV demand, driver speed and driver headway, and tells you the assumption behind each one. 5–200 samples, up to six variables. You get P10 / P50 / P90 for the KPIs and corridor journey times, the probability the scheme is worse than the base, which input drives the answer, and every sample in *_monte_carlo_samples.csv. Base and scenario share every draw, so the difference between them is the scheme, not chance.
• Runs in parallel, and your study never waits on someone else's. Monte Carlo samples run several at a time inside the same background job, and calibration tries several demand levels at once and abandons the gridlocked ones early. The sidecar caps how many simulations run at once across all jobs and holds capacity back, so one large Monte Carlo cannot take every slot and leave another study crawling behind it. Four studies run side by side.
• A better replay. Per-mode 3D vehicles, pedestrians, live signal heads, sun position for the period, orbit / follow / top-down cameras, synced split view of base and scenario, speed and delay heatmaps, and video recording. The study area is outlined on the map (toggle with B), an eye button hides the whole interface for a clean screen or recording (H), and a Monte Carlo panel shows the ranges when you ran one.
• A report you can mark up. *_report.html and *_report.md, structured after DfT TAG Unit M3.1, the TfL Traffic Modelling Guidelines / Model Auditing Process and FHWA Traffic Analysis Toolbox Volume III: scope, network, demand, signals, calibration, validation, results, uncertainty (when you ran a Monte Carlo), assumptions register, data sources.
• A tidier file list. Generated Files shows the deliverables: replay, report, Monte Carlo samples and the reproducible bundle. The raw SUMO result XML and the KPI JSON sit under System Files, still there for the Code Executor to parse and chart.

Where this shows up

• You have a lane closure to assess in a town you have never modelled. You used to need coordinates, a bounding box and a morning of set-up. Now you name the town centre and the period and read the validation tables when the job comes back.
• A councillor asks "what if traffic keeps growing?" One run gives one answer and no sense of how fragile it is. Now you state the growth range, and the reply is a P10–P90 band and the chance the scheme makes things worse.
• You are presenting the replay. The outline shows exactly which streets the model covers, and the eye button clears the controls off the screen.

Try it

• "Build an AM-peak traffic model of Bedford town centre, 1.5 km radius. No scheme yet — give me the calibrated base and the validation tables."

• "Build an AM-peak traffic model for 1.5 km around 52.2030, 0.1235 (Cambridge, GB). No scheme yet — give me the calibrated base and the validation tables."

• "On that model, cut one lane on 'Gonville Place' and compare base and scenario by mode."

• "Fit the PM model to these counts: East Road northbound 550 veh/h, southbound 500 … and show the GEH table."

• "List the signalised junctions on Hills Road, then run with the Lensfield Road junction on an 88-second cycle, greens 25, 12, 20, 12."

• "Reduce 'Gonville Place' by one lane in the AM peak. Traffic could grow 5 to 20% by 2031, most likely about 10%, and there's roughly a one-in-three chance the new depot brings 40% more HGVs. Run 30 samples and tell me the range of delay and how likely the scheme is to make things worse."

Heads up

• Experimental. Calls carry an Experimental tag in the chat and in the Tools menu, and switching the tool on always asks you first, even when your Safety profile auto-approves other tools.
• Monte Carlo ranges understate total uncertainty. The network, signal plans, buses, cyclists, pedestrians and routing rules are held fixed, and the distributions are judgements, not measurements. 20–30 samples is a first look; use 100 or more before quoting percentiles. Average travel time counts completed trips only, so a heavily congested sample can look better than it was — read it with the completed-vehicle count.
• Every sample is one more simulation per side. 30 samples on a scheme is 60 simulations on top of the base and scenario runs. Alfrada states the count before starting a large one.
• Journey times alone do not prove volumes. The same speed occurs at two different flows. Without counts the demand is labelled speed-consistent, not validated.
• Generated signal plans are typical, not surveyed. They bias any demand calibrated through them; load real plans where it matters.
• No authority audits SUMO models today. VMAP is TfL's Vissim audit process. The report follows the guidance structure for screening and option testing; agree software with the authority before a statutory submission.
• Observed journey times are typical ranges in whole minutes, so corridors need to be a few kilometres long; short links carry no signal.
• Runtime. A calibrated run takes roughly 3–12 minutes; re-runs on the same area reuse the network, observations and calibration. A Monte Carlo adds to that in proportion to the sample count: on our development machine, 40 simulations of a 1.5 km, 30-minute model took about four and a half minutes running four at a time. demand_mode: synthetic keeps the old quick illustrative run.
• One study at a time per account. Starting a second while one is running tells you what the first is doing and how far through it is, instead of quietly queueing you behind your own work. Cancel the first if you want to change course.
• Needs the rebuilt transport sidecar image (SUMO 1.27.1 with its bundled numpy / scipy / pandas / GDAL).