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 are not interpolated from a timetable. They come from the signalling system.

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.

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.

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.

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.

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. The timetable reloads daily with short-term amendments applied as they are published; disruption information every ten minutes; 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.