TransportForge

Getting Started

Build, test, then compare

TransportForge is for sketching a service idea and checking whether it improves journeys. Start with a city, draw the proposal, then use analytics to test who gains and where the design is weak.

A good session usually starts with one clear question. For example, test whether a tram extension improves access to jobs, whether an orbital bus removes slow cross-city trips, or whether a metro corridor is worth its higher cost.

Use Design for new bus, tram and metro services.
Use Build for roads, guideways and crossings.
Use Analytics to compare journey time, access, demand and appraisal.

DesignCreate a service. BuildAdd infrastructure. AnalyseCheck the impact.

Route Design

Bus routes

The fastest way to test a service idea. Draw stops on the map, and the route follows the streets between them - you are designing a bus service the way an operator would, over real roads at realistic speeds.

How routing works

Each pair of consecutive stops is routed over the city's owned street graph, with turn logic that discourages impossible manoeuvres like doubling straight back along the same road. Reusing existing stops connects your service to the interchange network immediately; new stops are placed exactly where you click and snapped to the nearest street. The editor prices the route as you draw: length, cycle time, and the fleet implied by your chosen headway.

What to set before analysing

Headway, first/last service and operating days live in the route editor and directly drive every metric: the journey planner boards your service at its actual frequency, assigned demand allocates passengers against your span, and the appraisal builds operating cost from vehicle-kilometres. A route left on the default timetable is still a testable route - just an expensive all-day one.

Direct beats clever. Every deviation costs all through riders time; the stop review prices this trade if you want the evidence.
Frequency is half the product. The same alignment at 10 versus 30 minutes produces radically different journey-planner and demand results.
Reuse stops where they exist. Existing stops carry interchange with today's network; isolated new stops start with no connections.

Route Design

Light rail and tram

A hybrid mode: the same line can run on-street through the centre, follow an existing rail or tram corridor, and strike out on brand-new reserved track - switching per section as you draw.

How the three alignments work

While drawing, the Street/Track toggle sets how the next section runs. Street sections route over roads like a bus. Follow tram/rail snaps your stops onto the existing network and traces the actual track geometry between them - the model treats this as shared, already-built infrastructure, so it triggers no demolition. New track draws a segregated alignment through whatever you cross: the app then detects buildings in the corridor, water crossings needing bridges or tunnels, level crossings with roads, and checks terrain grades against light-rail limits (~8%).

What the model charges you

Light rail costs roughly £20m per route-km of new construction plus £3m per vehicle in the appraisal, against bus-beating speeds on reserved sections and stronger legibility. The interesting design question is usually how much expensive new track a corridor genuinely needs versus how much existing rail or street can carry it.

Stops on followed rail sit on the rails. Suggested or hand-placed stops snap to the alignment; the walk from the nearest road is the passenger's problem, not the tram's.
Review crossings when prompted. Water and road crossings need a structure decision (bridge/tunnel/level) before the cost picture is honest.
Watch the grade warnings. Terrain checks flag climbs beyond light-rail capability on new-track sections.

Route Design

Metro

Fully segregated rapid transit: every section is its own right of way, drawn as new track or following existing rail corridors, never mixing with street traffic. Fast, high-capacity, and priced accordingly.

How it behaves in the model

Metro runs at ~40 km/h cycle speeds - roughly double a bus - and never routes over streets: sections either follow existing rail (traced onto the real track geometry) or run as new alignment with the full construction checks: building demolition in the corridor, water crossings, and terrain grades. The appraisal charges about £100m per route-km of new construction and £9m per vehicle, so a metro proposal must move a very large market to clear a BCR of 1. That is the honest economics of the mode, not a model penalty.

Designing a credible line

Wide stop spacing is what buys the speed: every station adds dwell and access time but serves a catchment. Strong metro tests are strategic - a dense radial corridor the buses crawl through, or a cross-city link that removes a via-centre interchange. Check each station's connections to the surrounding bus and rail network; an isolated fast line underperforms a connected one in every metric.

Fewer, stronger stations. A metro that stops everywhere is a slow tram with a tunnel bill.
Following rail is cheap; tunnelling is not. Reusing an existing corridor avoids most of the capital charge - often the difference between BCR 0.4 and 1.5.
Read the agent model too. High-capital modes need the distributional story as well as the aggregate one.

Road Builder

Draw infrastructure carefully

Sketch the physical network itself: new roads, bus links and junction fixes that change how everything routes - not just where one service runs.

How it works

Drawn roads join the routing graph for the active scenario: every bus route, journey plan and demand assignment immediately routes over them at the road type's assumed speed. Where your new link meets existing streets, junctions connect the networks; where it crosses water, rail or other roads, you choose the structure - bridge, tunnel or at-grade - and that decision controls whether the networks actually connect or merely cross. Buildings inside the corridor are detected from the footprint data and reported as impacts.

Using it well

The strongest use is the missing-link test: a short connector, a bus gate, a bridge over the barrier that forces every service into a detour. Draw it, resolve the crossings, then re-run a journey the old network did badly - if a 400 m link saves every trip 6 minutes, that is a finding. Long free-drawn boulevards through dense fabric mostly generate demolition lists.

Crossings decide connectivity. An unresolved crossing can leave your link visually present but unusable; resolve the dialog before trusting travel times.
Impacts are screening estimates. Building counts come from footprint overlap - treat them as early constraints, not a demolition register.
Pair with a service. A road on its own moves nothing; add or reroute a bus over it to measure the passenger effect.

Metrics

Journey planner

Plans a real door-to-door journey between any two points, at a specific day and departure time, and shows how your proposal changes it. This is the most concrete metric in the app: one trip, told stop by stop.

How it works

Journeys are found with a Connection Scan over the city's per-day timetable grids, built from the national bus data feed (BODS). Every scheduled departure is searched individually, so a Monday 08:00 query boards the actual 08:04, waits the actual 7 minutes at an interchange, and misses connections that are genuinely too tight. Walking legs are routed over the real street network, not drawn as straight lines. When you have designed routes, the planner runs twice: once on today's network and once with your services merged in at the headway and span you set in the editor, and presents both.

How to read it

The headline states whether your proposal is used and how many minutes it saves. Below it: the best scenario journey, the best existing journey, a fewest-changes option when one exists, and the next few real departures. Expand any card for the stop-by-stop timeline. Legs with exact clock times come from the timetable; legs marked with ~ are estimated from service frequency where no published grid exists for that day.

Departure time changes the answer. The best route at 08:00 can lose to a different service at 08:15. Test the times your users would actually travel.
An unused proposal is information. If the planner ignores your route for a pair, it found something faster. Check where your route loses: frequency, directness or stop placement.
One journey is an anecdote. Use it to explain a story people recognise, then back the claim with reachability or the travel-time matrix.

Metrics

Reachability

Click anywhere on the map and see everything you can reach from that point within 15, 30, 45 and 60 minutes by public transport and walking, plus how many residents and jobs sit inside each band.

How it works

One Connection Scan pass from the clicked point computes the earliest possible arrival at every stop in the city for the chosen day and departure time, riding real timetabled services and transferring only where connections actually work. The map then shades small cells by arrival-time band, and census population (output-area level) and workplace jobs are totalled inside each band. With a scenario active, a second pass runs on your proposed network and the green overlay marks places that became reachable, or reachable sooner.

How to read it

The tiles above the map give the headline: residents and jobs within 30 and 45 minutes, before and after. The shaded map answers the spatial question - which neighbourhoods, sites or estates fall inside a useful travel time of this point, and which stay cut off despite the proposal.

It is a one-point picture. Reachability from the station says nothing about the estate two miles away. Click several origins that matter: hospital, campus, deprived neighbourhoods.
No change can be correct. If your route does not pass near the clicked point, the isochrone should not move. That is the tool working, not failing.
Time of day matters. An hourly service produces very different 30-minute areas at 08:00 and 08:31. Try more than one departure.

Metrics

Opportunity map

Colours the whole city by how many jobs are reachable from each place within 45 minutes by public transport - a citywide accessibility picture rather than a single-point one.

How it works

The city is divided into a fine grid, keeping every cell with a stop within 1.3 km. From each cell the engine computes the jobs reachable door-to-door within 45 minutes, and averages the result over five departure times spread across the service day (07:00 to 19:00), so a half-hourly service is judged on its typical wait, not one lucky departure. Jobs per zone come from workplace employment data, the same inputs the demand model uses. Colours run between the 2nd and 98th percentile of the city's values, so the scale adapts to each city. In gain mode the map instead shows extra jobs reachable because of your routes.

How to read it

Dark areas are opportunity-rich: many jobs within a normal commute. Pale areas are the access deserts. The interesting test for a proposal is the gain view: does the new service meaningfully deepen access where it was weakest, or does it add access where it was already strong?

Jobs are the yardstick, not ridership. This measures potential access, which is the economic and equity argument, separate from whether people ride today.
Compare like with like. Always read before/after at the same threshold; the 45-minute cutoff is a convention, not a law.
The demand model feeds it. Employment sites missing from the inputs (new development, some special sites) will not show as opportunity until added.

Metrics

Appraisal

A screening benefit-cost estimate in the shape of DfT Transport Analysis Guidance (TAG): it prices what your scheme changes, sets that against construction and operating costs, and reports value for money. Below, every section of the report and how to read it.

The value-for-money meter and the benefit ladder

The big number is the initial BCR - TAG's established monetised impacts divided by public cost - and it drives the verdict. The ladder beneath it states exactly what each tier adds, cumulatively: user time savings alone (the strictest view); plus decongestion, collisions, air quality, carbon and health, minus fuel duty forgone, giving the initial BCR - every one of these scales with actual riders, so an unused scheme scores zero; plus agglomeration and labour supply, giving the adjusted BCR (TAG's evolving wider-economy evidence). Land-value uplift never enters any tier because it capitalises the same benefits. When ALL value sits in the wider-economy tier with no riders behind it, the report says so with an explicit warning. The shaded range on the meter comes from the sensitivity run.

The economic case

The stacked bar decomposes total benefits into their streams: user time savings (blue), externalities from car-km removed - decongestion, collisions, air quality at 15p/km (green), and agglomeration (purple). The vertical tick on the bar is total cost: benefits to the right of it are surplus. Net present value = all benefits minus all costs over 30 years, discounted, including wider impacts - so it is the adjusted-BCR view of the world, not the initial-BCR one. The cost note itemises capital + operating minus farebox.

Economic impact tiles

Benefit per boarding is consumer surplus per ride - the micro sanity check (healthy schemes sit around £0.50-£3; £0.00 means the sampled demand never uses your route). GVA uplift is the annual agglomeration productivity effect from denser effective labour markets (TAG elasticity 0.044). Jobs supported counts drivers employed (2.6 per vehicle). Labour-market reach is extra jobs reachable within 45 min per worker - the access mechanism behind agglomeration. PT mode share is the logit mode-choice result; if it does not move, your scheme is not winning trips from cars. Labour supply (WB2), carbon, health follow TAG unit A2 conventions; land value uplift is shown for context but never added to the BCR, because it capitalises the same benefits.

Exchequer view and operations

The exchequer table answers "who pays": farebox and labour-supply tax flow in, fuel duty forgone and operating cost flow out, plus one-off capital - the fiscal case as distinct from the welfare case. The bottom tiles are operational reality: boardings/day assigned to your routes, fleet size implied by cycle time and headway, cost recovery from fares, and how many sampled journeys actually improved.

Initial vs adjusted BCR. The verdict uses user benefits only; the NPV includes wider impacts. A 0.00 BCR beside a positive NPV means all value is model-derived access effects with no riders - treat it as an upper bound, not a case.
Open Sensitivity. The tornado shows which assumptions move the BCR most - if the case lives or dies on one elasticity, you know what to defend.
Trams and metros must earn their capital. £20-100m per route-km means rail modes need large, dense markets before the initial BCR clears 1.

Metrics

Assigned demand

Routes thousands of sampled trips through the scheduled network and paints the results on the map: how many passengers each service and each segment would carry if travel followed the demand model.

How it works

Up to ~2,400 origin–destination trips are drawn from the gravity demand matrix, in proportion to modelled flows, and each is planned on the real timetable within your chosen departure window. Every boarding, alighting and on-board segment is accumulated, then scaled to a daily total anchored to the DfT local trip rate (about 36 public-transport trips per person per year). The result is drawn as flow ribbons - thicker means more passengers - and each service gets a profile: boardings, alightings and load after every stop, the classic load-along-the-line chart.

How to read it

Click any loaded segment for a select-link view: the actual origins and destinations of the people crossing that point, drawn as arcs. Use the service profiles to find where a route earns its keep and where it runs empty. This is assigned model demand - a statement about relative attractiveness under the model's assumptions - not ticket data or vehicle counts.

Low demand is a diagnosis. If your route assigns few passengers, sampled trips found faster paths. Check frequency, directness and stop placement before blaming the tool.
The matrix decides what exists. Airports, hospitals and campuses generate strong flows only because they are explicitly represented as special generators in the demand model.
Departure scope shifts results. A single-time run reflects that time's waits and connections; the all-day scope is steadier for comparisons.

Metrics

Agent model

Simulates individual people rather than aggregate flows: a synthetic population of commuters, each with a home, workplace and departure time, routed one by one before and after your scenario. It answers the question the appraisal cannot: who gets the benefit. Below, each section of its report.

The headline: annual consumer surplus

Each agent's home is drawn from census output areas in proportion to population (carrying that area's deprivation decile - IMD in England, SIMD in Scotland); their workplace is drawn from the gravity matrix row of their home zone; departures spread across the morning peak. Every agent is planned door-to-door on both networks and the change in generalised cost (riding + waiting x2.5 + walking x2 + interchange penalties) is priced and scaled up - each agent represents a known number of real commuters, shown under the headline with the gross gain and gross loss it nets from. The computation runs in a background worker.

Who gains & loses

The diverging bar chart splits net surplus by deprivation decile, 1 = most deprived. This is the equity result: a scheme whose gains pile up in deciles 8-10 upgrades journeys that were already good; one that pays out in deciles 1-3 serves the areas that need it. Losers are real, not noise - a rerouted or slower service shows up as negative bars, and the report names how much loss the headline nets off.

Why journeys improve

Decomposes the saved time into its components: less waiting (frequency), less riding (directness/speed), less walking (stop placement) and fewer interchanges. This tells you which lever your design actually pulled - useful when deciding whether to iterate on headway or alignment.

Wider impacts and peak crowding

Wider impacts translate the agent outcomes into access, carbon and reliability terms. Peak crowding divides morning-peak boardings by the seats your timetable offers (headway x vehicle capacity, per mode): over ~85% signals standing loads, and when a run overloads, the model re-assigns it with crowding-inflated ride times - the comfort feedback - so the shown loads are the settled equilibrium, not the naive first pass.

Patterns over point estimates. With ~1,500 agents the decile pattern is robust; the third decimal place is not. Raise the agent count for finer splits.
Commuters only. Agents model the journey-to-work market; airport passengers and visitors appear in assigned demand and the appraisal via special generators, not as agent types.
Read with the appraisal. The agent model deliberately ignores construction cost: a distributionally beautiful tram can still fail its BCR.

Metrics

Compare scenarios

Puts two saved scenarios side by side under identical assumptions: the same sampled journeys, the same day, the same appraisal settings - so any difference you see is caused by the designs, not by the test.

How it works

Both scenarios are loaded and evaluated against a common set of demand-weighted journeys. For each, the tool reports the shared KPIs - journey-time savings, mode shift, access gains, operating and capital cost, BCR - and the deltas between them. Because the sample is held constant, comparisons are fair even when the individual numbers carry model uncertainty: the noise largely cancels.

How to read it

Treat it as your options table. The strongest use is narrowing: run two or three credible designs, keep the one that wins on the dimensions you care about, and iterate. Name scenarios descriptively when saving ("tram north", "orbital bus 15min") - the table reads much better than with three "Untitled scenario" columns.

Change one thing at a time. If two scenarios differ in mode, alignment and frequency at once, the comparison cannot tell you which choice mattered.
Comparative results are the most trustworthy output. Model biases hit both options equally, so "A beats B" is more robust than "A is worth £4.2m".
Check build impact too. A narrow winner on journey time can be a clear loser on demolition and capital.

Metrics

Travel-time matrix

The classic planner's skim table: door-to-door travel between the city's busiest zones, all pairs at once, so you can see whether a proposal improves one corridor or shifts the whole network.

How it works

The 18 biggest zones by residents plus jobs form the rows and columns. For every ordered pair the engine plans a real door-to-door journey on the scheduled network and records the generalised minutes - riding, plus weighted waiting, walking and interchange time, the same measure the appraisal prices. In gain mode each cell instead shows the improvement over the baseline network, so your proposal's footprint appears as a block of coloured cells.

How to read it

Rows are origins, columns destinations. Scan for structure: a dark row means a zone with poor access to everywhere (a candidate for service); a dark column means a destination the network serves badly; a bright block in gain mode is the market your scheme actually serves. Then pick one interesting pair and replay it in the journey planner to explain the mechanics.

Generalised minutes, not clock minutes. A cell mixes riding with weighted waiting and walking; two pairs with equal clock time can differ here, correctly.
Zones are the busiest, not all. The matrix samples the top of the demand distribution; small suburbs will not appear as rows.
Asymmetry is real. A to B can be faster than B to A on a one-way system or an asymmetric timetable.

Metrics

Frequency search

Answers two operational questions about a designed route: what headway is worth running, and are the stops in the right places. Both use the same economics as the appraisal, so the recommendations are priced, not aesthetic.

Optimise headways

For each designed route the tool tries a ladder of practical headways and evaluates every option with the appraisal engine: shorter waits raise benefits, more vehicle-kilometres and a bigger fleet raise costs. It keeps the best net result and reports what changed. It is a frequency search, not a full vehicle and duty schedule - crew rules and depot logistics live outside this model.

Review stop spacing

The stop review scans each route for two priced defects. Long gaps: a stretch over 550 m where an existing network stop would gain more than 150 residents within 350 m walk - buses may deviate up to 250 m off-path with the detour time charged against through riders (~25 s dwell plus the loop), while trams and metros never leave their alignment, so a suggested rail stop lands on the track and the offset is a platform walk. Redundant stops: neighbours within 240 m on both sides serving fewer than 120 unique residents, which mostly add dwell time. Apply makes the change and re-routes in place.

Frequency is the product. Cutting a headway from 30 to 15 minutes often does more than any alignment tweak - and doubles the operating bill. The search makes that trade explicit.
Stabilise geometry first. Run this after the route shape is right; every applied stop change re-routes and re-costs the service.
Suggestions are net, not gross. A stop that gains 300 residents but drags every through trip 40 seconds can still score badly. The numbers on each card show why.

Metrics

Corridor finder

Scans the whole demand matrix for the movements your next route should serve: places where many people travel and public transport is disproportionately slow.

How it works

Hundreds of zone pairs are scored by trips × excess generalised time - how much slower the current PT journey is than a car-equivalent benchmark, weighted by how many people make the movement. A tangential weighting keeps everything from collapsing into the city centre, so orbital gaps (outer area to outer area) rank alongside the radial ones. A second, separate pass anchors on the most deprived residential zones and asks the same question weighted by need rather than volume. The scan runs in a background worker.

How to read it

Orange arcs are radial corridors, teal arcs orbital, purple arcs the equity-weighted underserved links; thickness is score. Each ranked row states the movement, the excess time and the demand behind it. Treat the list as a brief for sketching, not a verdict - draw a route along the top corridor and test it with the journey planner and appraisal.

Orbitals hide in radial networks. Most UK cities run hub-and-spoke; the teal corridors are where an orbital service quietly beats a 40-minute via-centre trip.
Two lenses on purpose. The volume lens finds the biggest markets; the equity lens finds the most underserved people. They rarely agree - that disagreement is informative.
Low modelled demand is not no need. The matrix is commuter-plus-generators; growth sites, tourism and education travel may be undercounted.

Metrics

Route generator

Auto-designs candidate routes and ranks them - the only tool that chains three engines end to end: corridors say where, the appraisal says whether, and the agent model says for whom.

How it works

The corridor scan finds the strongest unserved markets (both the citywide volume lens and the equity lens over deprived residential zones). Each corridor becomes a candidate: the line between its anchors is sampled at the chosen mode's stop spacing (bus ~450 m, light rail ~800 m, metro ~1.5 km) and each sample snaps to the nearest existing stop, so candidates connect to today's interchange network. Every candidate gets a default service (bus every 12 min, tram 10, metro 6; 06:00-23:00) and a full screening appraisal; the finalists then run a 240-agent equity pass. Candidates are ranked by initial BCR, and the whole computation runs in a background worker.

Rail-following capital

Light rail and metro candidates are checked hop-by-hop against the existing railway and tram network. A stretch that runs along an existing line is charged only a 15% retrofit allowance (stops, signalling, electrification) instead of full new-track construction - the same economics the designer applies when you follow rail by hand. The card states how many km ride existing rail, and hand-drawn routes get the identical credit in their own appraisals.

How to read it

Each card shows the corridor, initial and adjusted BCR, NPV, boardings/day, length (with the on-rail share), and for finalists the share of gains flowing to the three most deprived deciles. Dashed purple previews draw on the map. Add puts a candidate into the designer with its stops and service level, where the alignment re-routes properly - treat the generated numbers as a screening rank, then refine and re-appraise.

A starting point, not an answer. Candidates are straight stop chains along corridor lines; the designer's real routing will shift lengths and times somewhat.
Mode changes everything. The same corridor can rank first as a bus and last as a metro - spacing, speed and capital all move together.
Watch the equity flag. Candidates marked "equity" were seeded by deprived-area demand rather than raw volume; they rarely top the BCR table but answer a different question.

Metrics

Service simulation

Animates the timetable: every scheduled vehicle in the city moves along its real route geometry as the clock runs, so you can watch your network operate before believing any number about it.

How it works

Each timetabled connection becomes a vehicle position interpolated along the service's actual track between its stop times. Scrub or play the clock and the fleet moves accordingly; the counter reports vehicles in service at that moment. Designed routes join the animation at the headway and span you set, so a proposed 10-minute service visibly runs every 10 minutes alongside the real network.

How to read it

This is the sanity check that catches what tables hide: a corridor that looks served on paper but has 25-minute holes in the afternoon; a proposal whose vehicles bunch behind an existing service; a "frequent network" that visibly empties at 19:00. If the animation looks wrong, fix the timetable before trusting the appraisal built on it.

Scheduled, not live. The simulation replays the timetable perfectly; real operations add delay, bunching and cancellations on top.
Watch the edges of the day. Early morning and evening reveal span problems that peak-hour analysis never shows.
Fleet intuition for free. The vehicles-in-service counter approximates the fleet your proposal needs at its busiest moment.

Metrics

Methodology caveats

Everything here is a model, and models are wrong in knowable ways. This page states the main ones so you can present results honestly and defend them under questioning.

What the model is

Demand is a calibrated gravity model of commuting from census data, with explicit special generators (airports, hospitals, universities) layered on top - not observed ticketing. Timetables come from the national BODS feed as real per-day grids, validated against operator data, with frequency fallbacks where grids are missing. Rail runs as typical-service frequency rather than exact trains. Journey planning is schedule-based (Connection Scan) over that data. The appraisal follows the shape of DfT TAG with published, editable assumptions, and is a screening estimate, not a business case.

Where it is strong and weak

Strongest: comparisons. Two scenarios tested under identical assumptions rank reliably, because shared model bias cancels. Weakest: absolute forecasts. A specific ridership or BCR figure inherits every assumption in the chain, so quote them as modelled estimates with their assumptions attached - the appraisal report lists every one for exactly this reason.

Demand data is commuter-shaped. Leisure, education, tourism and off-peak travel are represented only coarsely; special generators cover the biggest gaps, not all of them.
Small differences are noise. A 3% BCR gap between options is not a decision; a 2x gap is.
For decisions, add evidence. Observed patronage, counts, local plans and site constraints belong alongside any output you publish.

Plan a transport network

Norwich

Edinburgh

Cambridge

York