bobm is spot on - there appears to be a problem upstream from OpenTrainTimes that's causing train describer (TD) messages to be processed slowly.  Consequently, we're getting them quite late and this is also affecting every other site using the Open Data feeds from Network Rail.

I've reported it, and hopefully somebody will fix it soon.  Many thousands of people rely on the maps and information in OpenTrainTimes each day.

I'm ridiculously happy that there's so much discussion around the maps I've put together!  Thank you to everyone who's commented here or emailed support@opentraintimes.com with corrections - I prefer to release maps quickly and get feedback from users then fix any problems.

There's a lot of work going on between Paddington and Reading - still - with Crossrail, and I've got tons to do to sort out the flyovers for the Heathrow lines, as well as fill the missing gaps around Southall.  I might manage to cover PAD^» (Paddington (London) - next trains)-RDG^‡(resolve) (exc.) in a Paddington - Southall and a Southall - the rest map, but I won't know how complex it is until I come to do it!

Thanks for all your comments!  It's hard work trying to get even one map out, but three in a week was fuelled by caffeine and perseverance!  I'm fixing the problem with 1658 and 1660 berths this evening.

I'd love to put route indications on at Paddington, but there are several alternate routes available between signals.  For example, SN37 to platforms 2 and 3 has two possible routes - one via the set of points closest to SN37 signal, and one to the farther set of points.  The train describer only outputs a single indication for both routes, so it's not easily possible to determine which points are set for the route.  I could spend time working out which routes conflict with each other, but that's a lot of work.

For the signalling-minded, these are called 'meshed routes'.  What I could do is display the platform number next to the last signal before entering the platform, a la London Waterloo - and I might look at doing this.

Not all train describers output the data which I use to show signal aspects and routes set.  Plymouth, for example, only had 'route berth' support for two signals.  Paddington, on the other hand, has signals and routes, as does nearly all the resignalled areas on the GWML^▸ (Great Western Main Line).

There will be more maps of the South West soon, and they'll continue to be free for public use!

It's not quite that straightforward - there are 87 instances of a 2N52, but I take in to account the location the train originates, and I also try to 'hand over' data between train describers (there can be three train describers reporting the same train in the same berth in some places around Upminster) - but it's not currently perfect and sometimes mis-links trains.

I'm working on a better solution - either I need to improve the fuzzy matching I do, or I need to nail it down and make it accurate, but liable to break when train describer configurations change, as they do regularly.

Hello, it's Peter here - I run OpenTrainTimes.


I measured it as less than two seconds between a signal changing from a proceed aspect at Putney this evening, and the map on my phone updating.  That's really quite fast!


I have the faults logged in Jira, I just need to find some time to sit down and work on them - OpenTrainTimes is my hobby, I don't make a penny from it and I spent an inordinate number of hours working on it, keeping the Open Rail Data wiki up-to-date and replying to messages on the openraildata-talk mailing list.  I'm surprised I have time to eat...!