When the dots stop, and what that actually means
Sometimes the dots stop. Occasionally that is because the trains have stopped — but far more often it is because the equipment reporting them has, and from outside the two look exactly alike.
A live map has an awkward property: when it shows nothing happening, it cannot easily distinguish a quiet railway from a broken pipe. Both render as stillness. This is the honest account of every way our train map can be showing you something that is no longer true.
The mechanics of how positions arrive are covered in why a train on the map is never exactly where the train is. This guide is about what happens when that machinery falters.
A step that moves nothing
The most common reason a dot sits still is the least alarming. Positions come from trains stepping between signalling berths, and many neighbouring berths resolve to the same location reference. When a train steps between two of those, the message arrives, the train genuinely moved, and the dot does not.
In the reference data we hold, 22,359 berths map to only 3,766 distinct locations — very nearly six berths per location. Roughly half of all reported movements therefore leave the dot where it was. A train can report four times in a row and appear frozen.
Lines the describer never covered
Then there is track where the equipment simply does not reach us. The berth reference maps only about half of what the describer network reports, and some lines have no mapped berths whatsoever — Ramsgreave, Langho, Whalley and Clitheroe among them.
A train heading up such a branch would freeze at the last mapped berth and reappear on its way back, having apparently spent an hour stationary. That is not a fault we can fix; it is the extent of the data.
It is also why the map carries a second kind of dot. Where the describer cannot see a train but the forecast feed knows it is running and how late, we place it on its booked path shifted by its lateness. Those are drawn fainter and labelled as estimates, because an inference should not be presented with the same confidence as a report.
When a whole area goes down
The case this guide exists for is different in kind. Occasionally an entire train describer area stops reporting.
When that happens, every train in that area stops stepping between berths at once. Their dots freeze exactly where they last were and go on being drawn as though current. Nothing errors. The trains are still running, the railway is fine, and the map is quietly showing you a photograph of a few minutes ago.
Worse, the usual staleness cue fails. A dot's age measures how long since its last report — but what has stopped is the reporting, so a frozen dot can have an age of a few seconds and look healthier than a train that is merely sitting in a platform.
Fortunately the forecast feed says so outright. It publishes an alarm naming the area that has failed, and a matching clear when it recovers. We read those, and any dot in a failed area is drawn as an estimate rather than a report, with a note above the map naming the areas concerned.
Two honest limits on that. The alarm is published once, when it happens, and there is no snapshot of currently-open alarms anywhere — so if an area failed before our server last restarted, we do not know. And an empty list therefore means “no failure we have seen”, never “every describer is healthy”. It errs towards saying nothing rather than marking dots stale without cause, which is the right way round, but it is not the same as an all-clear.
A headcode is not an identity
A subtler failure is two trains being mistaken for one. Headcodes repeat across the country — the same four characters can be running in several places at once — so a dot is keyed on the describer area and the headcode together.
Keying on the headcode alone caused exactly the bug you would expect: a dot sliding across the map between two entirely different trains. In a single sweep we found 15 pairs of genuinely different trains sharing a headcode. Ghost copies are pruned by keeping the freshest per headcode, plus any copy that is both recent and more than 20 km away — that distance clause is what stops the pruning from eating one of a legitimate pair.
One code deserves naming: 0B00 is a placeholder used network-wide rather than an
identity. Anything that treats it as a train will merge a great many unrelated movements.
What the colours are not saying
A dot's fill is its operator and its ring is how late it is. There is a third ring colour for unknown, and it is deliberately not green.
Around 13% of what moves on the map is freight, which the passenger forecast feed does not cover at all. We know where those trains are and nothing about their punctuality. Colouring them as on time would be inventing the most interesting fact about them.
This is the same instinct as everywhere else on the site: absence rendered as absence. A train with no delay figure is not a train running to time, a station with no accessibility data is not a station without a ramp, and an empty alarm list is not a healthy network.
What to do with all this
In practice: a still dot is usually a berth quirk, occasionally a line without coverage, and rarely an area failure — and when it is the last of those, the map now says so. A faint dot is an estimate from the timetable. An uncoloured ring means we do not know how late it is, not that it is punctual.
And if you want certainty about a particular train rather than a picture of the network, its service page carries the calling points with actual times against booked ones, which is a much stronger statement than a position on a map.