It's certainly a cool map and useful to get a general idea how many trains are around at any given time, but it's important to note that this is not real data. They use the train schedule combined with the projected delay to estimate track location. I'm not sure if it's because SBB has an interest in keeping reported delays low or if they think exposing real data is a security risk, but I noticed the data being fake on several occasions, for example:

- My train wasn't able to continue its journey and was stuck between two stations for a few minutes while the map showed it continue to the next few stations up until the point where it started moving again, when their App also showed it running with a delay of 8min.

- On several occasions: watching the map show a train roll into the station and driving off, while seeing from my window that the train is only just arriving when the map shows it as between stations already.

I think I saw and was fascinated by this which some time back here on Hackernews, https://maps.vasile.ch/transit-sbb/

Seems similar to Transit's approach: https://blog.transitapp.com/go-underground/

It works fairly well empirically: my 7yo likes to watch trains and we regularly use this map to know when to expect one to pass. Not perfect, but pretty good

I wonder what app has allow location on all the time and is feeding them their data

GTFS is widely adopted, "standardized", but also quite a wild west when it comes to the actual details. I've been building http://mobility-bot.com/ as a spare time project for two years, parsing the alerts GTFS feeds from a handful of providers, and for just about every one of them, I have to do something in the pipeline to clean up the provided data - fixing unicode issues, remapping route and agency IDs, rewriting headers and descriptions to not be identical, etc. You also have to watch and capture the data over time to make sure you have a corpus to generalize parsing and cleanup rules from.

Most of these projects made the smart choice to focus on a single or just a small handful of related providers. As soon as you're trying to aggregate, the problem becomes a lot trickier.

Note that carto.tchoo does not provide real position in real-time: it only has access to departures, stops, delays and suppressions and interpolate position based on this.

This means that if your train is running at half-speed or stopped but does not result in an official delay, the position will not match reality.

The title matters a lot. Without "real-time" this submission has likely gotten the same lack of attention.

Is the interesting part the upvotes, meaning there's more people interested in UK train networks than French ones ? And it's a comment on demographics ?

Or is the interesting part that the UK one is real-time, and the French one isn't (or at least, zooming in, I don't see them moving).

And to see the status (Ile-de-France only): https://ratpstatus.fr/trains.html

That's no surprise. The French equivalent of anything rail related is always more complete than the UK.

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.

> 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.

And obligatory one for Slovakia with much better UX.

https://mapa.zsr.sk/index.aspx

And Polish one, still a gen or two behind just like their rail network. It needs to be said they are investing heavily to bring it up to scratch.

https://portalpasazera.pl/MapaPociagow