[redeyedtreefrog]

Would be better if it had some technical explanation rather than just yet another public transport map. This:

https://vgcgroup.co.uk/news/signalbox-for-train-locations/

suggests the data mostly comes from railway signalling information, plus a bit of "AI" in some way. I wonder how far apart railway signals usually are, or what the AI is trained on, or anything really vs just looking at a map.

[4ndrewl]

I've tried building one of these and the answer is - it's difficult.

There is a message queue that you can use to identify the last reported location of a train. Depending on the line you could get a pretty accurate real-time map (but first you need to georeference all of the location identifiers to eastings/northings.)

But many lines report only the last movement at a station stop - these are mostly in rural areas so the best approach seems to be to build some sort of dead-reckoning network taking into account train type and network utilisation.

[greengreengrass]

> I wonder how far apart railway signals usually are

It varies substantially across the network, dependent on the mode of operation of the signalling, the desired headway, the maximum operating speed, the service braking distance of the rolling stock at line speed, factors in the layout that might influence safety (e.g. junctions), the number of colour lights used on signal heads (i.e. 2, 3 or 4 colour lights), signal sighting distance, whether signal visibility might be affected by sun glare, etc. And of course this assumes that the area is actually using line-side signals – most of the network does, but there's notable exceptions using in-cab signalling or computer-based train control.

> suggests the data mostly comes from railway signalling information, plus a bit of "AI" in some way

I'm in no way affiliated with the website, but in areas that follow track circuit block principles (much of the heavily-used main GB railway network, excluding many more lightly-used outlying lines), the "signalling information" that article indicates the site derives from is almost certainly Network Rail's Train Describer (TD) feed. This feed reports the headcodes for signalling berths across the layout. The signalling system will normally step headcodes automatically as the train activates successive track circuits or operates axle counters in the track.

The Train Describer can only report headcodes in berths, and berths might be quite long! It certainly doesn't provide second-by-second train progress, so this site's mapping engine is likely doing some proprietary interpolation to make the train position indicators appear to "move" in real time to give the illusion of trains making progress. (Whatever the inputs to their algorithm/model are, their calling it "AI" loses all technical specificity.) This interpolation may be based on line speed, perhaps the observed average time a headcode normally remains in a given berth, allowing them to derive a typical 'average speed' for that berth or section.

If it was me designing this, I'd expect a mixture of the train class, the rolling stock and line speed to give a good estimator of the train's current position in block. You then have to make a product decision to decide what to do if you miscalculated train position – do you make staccato jumps of the train position indicators on the map if you got it wrong, or do you somehow try to smooth your error out over another period to avoid indicators suddenly moving?

In other areas of the country, train position may be reported by GPS on equipped units, or in some areas, the passage of trains is dependent on manual reports by the signaller, so the map may not have much real-time data to infer train position from. I find it highly unlikely that they're deriving much accurate data in real time from smartphone apps, but it could be a (noisy, incomplete) set of inputs to improve their model of how trains typically make progress through particular berths.