How it works

Every number and every line on this site is derived from an open data feed by a documented process. This page explains those processes — including where they are approximations, and why.

How the trains on the map are positioned

The moving dots come from the signalling system. The timetable only fills in the seconds between one signalling report and the next, and never overrides a report.

Britain's railway is divided into train describer areas, and within each area a train's headcode is held in a berth — roughly, a section of track between signals. As the train moves, the signalling equipment steps the headcode from one berth to the next and publishes that step. TransitRadar subscribes to those messages, which arrive at something like twenty to sixty a second across the country.

A berth is an identifier, not a coordinate, so turning one into a position takes two more reference datasets: SMART, which maps roughly 22,000 berths to the location codes beside them, and CORPUS, which maps those location codes to the industry's timing point codes. From there the station and junction database gives a latitude and longitude. A train that has not stepped a berth for fifteen minutes is dropped; one that has been quiet for three minutes is drawn in a faded colour, because a stationary dot and a dot we have lost track of should not look the same.

Two honest limitations. Berths are coarse — the dot marks the section of line the train is in, not its exact position within it, so expect it to be right to within a signal section rather than a carriage length. And direction of travel is usually unavailable, because both ends of a berth step frequently resolve to the same location code; the arrowheads only appear when the step genuinely crosses between two known points.

Three refinements sit on top of the raw berth. First, between reports each dot is moved on along the train's route at the pace its timetable implies, starting from the last reported position — so the dot keeps moving between steps, and a train running twenty minutes late is still drawn twenty minutes late. Second, each step is corrected by the berth offset that SMART publishes for it: the typical number of seconds between that signalling step and the arrival or departure it stands for. A step into a platform berth usually happens over a minute before the train actually stops, and the offset puts the dot back where the train is. Where the published offsets for a step disagree, none is applied rather than an average. Third, a headcode is not unique — the same four characters run in several places at once — so when a dot could be more than one train, it is attributed to the run whose booked calling points lie nearest to it, and left unattributed if they cannot be told apart.

Where the describer cannot see a train at all — some lines have no mapped berths — the train is placed on its booked path shifted by its current delay, and drawn fainter because it is an inference rather than a report. And when National Rail's forecasting feed announces that a whole train describer area has stopped reporting, the dots inside it are marked as frozen and the map says so, since from the outside a failed describer and a stationary railway look identical.

Guide: why a train on the map is never exactly where the train is — the same subject at length, including why whole lines have no dots and why half of all reported movements do not move one.

How a route is traced over the network

Drawing the path a train takes is harder than joining its stations with straight lines, and harder than shortest-path over a road-style network.

The underlying map is a graph built from OpenStreetMap's railway data — every piece of running line in Great Britain, as edges carrying their Engineer's Line Reference (the industry's name for a stretch of route, like SPC1 for the Midland Main Line out of St Pancras) and their gradient. Route-finding is an A* search across that graph from calling point to calling point.

The parts that matter are the constraints. A train cannot change between parallel lines wherever it likes, so a path that would require hopping tracks is rejected rather than drawn. A train that has to reverse can only do so where reversing is possible — at a calling point — and the cost model was specifically tuned so that a reversal happens at the station rather than a few hundred metres short of it, which is where a naive scoring gets it wrong. And for a real service the whole journey is solved as one continuous path that visits every calling point in order, rather than as independent hops that might each be locally sensible and jointly impossible.

The result carries the industry references back out: which ELRs the route runs over and for how far, the mileage in miles and chains at each waypoint, the total climb and descent, and the steepest sustained gradient — so a route over the Lickey Incline correctly reports about 1 in 37.

How arrival times are forecast

Three feeds contribute, in order of authority.

When you click a calling point on a route, the times you see are assembled from all three: the booked time always, the expected time when Darwin has forecast one, and an actual time once the train has been reported there. A cancellation is shown per stop rather than per service, because a service is often cancelled between two particular stations rather than in its entirety.

How journeys are planned

Journey planning runs a connection scan over the loaded timetable: every departure is considered in time order, and the earliest reachable arrival at each station is relaxed as the scan proceeds, with a minimum interchange time at each change.

A plain connection scan optimises arrival time and nothing else, which produces technically correct but absurd itineraries — most memorably, riding one stop in the wrong direction to change onto the very train you could have stayed on the platform for, arriving at exactly the same minute. Results are therefore tightened afterwards: each itinerary is re-scanned for the latest departure that still achieves the same arrival without adding a change, so what you are offered is the simplest, latest way to arrive at that time rather than the first one the algorithm happened to find.

Door-to-door planning extends the same scan across rail, bus and walking at once, with walking links between nearby stops and stations. Because a national bus timetable is roughly fifty million connections, the search is bounded by discs around the two endpoints rather than scanning the country — long distance is carried by rail, which is what actually happens.

How train punctuality is measured

The train performance page is a direct read-out of Network Rail's Public Performance Measure feed. PPM counts a train as on time if it arrives at its destination within five minutes for a commuter service, or ten minutes for a long-distance one, and it is calculated by the industry, not by us. We display it, break it down by operator, and show the rolling trend. A figure of -1 in the feed means "not available" and is shown as a blank rather than as zero.

The daily archive and the operator pages are different: those figures are ours. Every settled run is recorded as the day goes on, and a train counts as on time if its recorded arrival at its destination was within five minutes of the booked time. The percentage is always of trains whose arrival was actually recorded, and where cancellations are involved a second figure counts each cancelled train as a failure too. How the daily figures are measured sets out every rule, including why some days state no punctuality figure at all.

Guide: how a delay is measured — why three feeds report the same late train differently, and why our own archive figures are not comparable with the published ones.

How bus punctuality is measured

This one deserves a full explanation, because the bus feeds do not provide it and the number is therefore ours rather than an operator's.

Live bus data gives a position, a line and a journey reference, but no delay. To get one, each live vehicle is matched to the scheduled trip it is running and its position is projected onto that trip's calling-point path; comparing the scheduled time at that point with the current time gives an implied lateness. Matching is deliberately conservative — where two runs of the same route are close enough together that the vehicle could plausibly be either, the reading is discarded rather than guessed, because on a ten-minute headway a bus running nine minutes late looks exactly like the next one running on time.

Crucially, the unit of measurement is a completed journey, not a position reading. Urban areas are swept every few minutes, each run in progress is followed, and each is counted once when it finishes — so a bus stuck in traffic contributes one observation, not one per sweep. The day's tally rolls over at 02:00 and survives restarts.

Guide: why buses run early — why about a quarter of them arrive ahead of time, and the measurement mistake that first reported an on-time rate of 21.9%.

One genuinely interesting result falls out of it: across Great Britain, buses are far more often early at their destination than late. That is not a measurement error — timetables pad the final leg, so a bus that has made up time arrives before it is due.

Where train formations come from

The units and carriages shown against a service come from the rolling stock allocation that operators publish through the Rail Data Marketplace: which units are planned to form which train, with each vehicle's number, seats and design. Two cautions go with it. It is a plan rather than a sighting, so during disruption a different unit may turn up, and the formation is always shown with the time it was last stated. And the feed repeats an allocation for every leg of a journey, naming the same units each time, so units are counted once per train — otherwise a six-coach train is reported as twenty-four. Some operators publish nothing, so a missing formation means none was recorded, not that the train did not run. What a train is made of has the detail.

Where lift status comes from

Live lift status on station pages comes from Network Rail's lifts and escalators feed, fetched nationally and cached for about two minutes. It is shown the way Network Rail's display protocol requires: only lifts that are in commission and open to the public, only their name and status, and the protocol's own wording for each state. Escalators are excluded, because their live data is too limited to rely on. If the feed cannot be reached, the last good copy is used for at most fifteen minutes; after that the card disappears rather than showing a status that may no longer be true.

How often everything refreshes

Live positions, movements and forecasts are streamed continuously and are seconds old. Station boards and the live map refresh every eight to twenty seconds while you are watching them. Performance figures update about once a minute, and lift status every couple of minutes. The timetable reloads daily with short-term amendments applied as they are published, and the forecasting system's own timetable is re-read every six hours; disruption information every ten minutes; formations as operators publish them; the daily archive every fifteen minutes, with each day's page published once the day is complete; the bus timetable and the berth reference rebuild themselves weekly. Nothing on this site requires anyone to press a button, which is the point — a page that is stale is worse than no page.

The full list of feeds, with licences, is on the data sources page.