Last month, we said that there would be more frequent updates than before. The only downside to this is that making a blog post every time we release an update bombards you with trivial updates. We’ve decided to make posts every couple of weeks, wrapping up the changes since the last post.
Here’s what’s changed over the past few weeks:
- We’ve changed the way we handle cookies, which means there’s a new pop-up when you first visit the site on a device. Some people have reported problems with this – if you’re seeing problems, such as the popup never disappearing, please email us
- Our new East Kent map covers Faversham to Kearsney, Ramsgate, Martin Mill and Minster.
- The Brighton area map has been redrawn, and now covers the Coastway route as far as Lancing, with route indications at Brighton
- The West Coastway map now covers Shoreham-by-Sea to Emsworth – including Littlehampton and Bognor Regis. It links up with the Horsham map at Arundel, and the Guildford map at Emsworth/Warblington.
- The Catford Loop has been added to the West Dulwich to Otford, Teynham and Sheppey map
- The resignalled Shepperton branch now shows routes, signals and track circuit indications
- Train operator codes are now shown on schedule pages so you can easily see who operates a train. The FRGT code shown where we can’t show you the train running number (or headcode) has now been replaced with a simple padlock symbol – you can still click on it to show the schedule though
- We’ve made some efficiency savings to the site so pages load faster and feel more responsive
We will continue making updates live as soon as they’ve gone through testing, and we’re making a real effort to try to get through the backlog of support tickets – please bear with us!
Now that we have a vastly improved server infrastructure, we’re able to do releases on a much more frequent basis. This week, there’s been a minor release every couple of days, and we’ve done the following:
- At Ferryhill South Junction, the berth for signal T474 populates when Y474 at Northallerton is occupied. We think this is a cosmetic error within the signalling system itself, with no impact on safety. We’ve put a note on the map to mention this
- Between Horsforth and Headingley, berth 3888 never showed trains. We’ve fixed this
- The Rugby map now has route indications for about a third of the map, and we’ve fixed an error with the positioning of some signals in the yard
- Many of the route indications at Sittingbourne showed incorrectly. This was down to a problem with data mapping on our side – we were one bit out! We’ve fixed this, and in the coming hours, the incorrect routes should clear out. We’ve also added route and signal indications to the Sheppey branch
- Signals TL2047 and TL2049 near North Kent East Junction to the right of the London Bridge map now show their aspect
- We’ve removed the berth for signal 1001 at Meadowhall (Sheffield), as this is a distant signal
- At Clapham Junction, we’ve added some more route indications on platforms 1 to 11
- Trains through the tunnel near High Brooms disappeared, so we’ve added an extra berth so don’t disappear
- Platform 1 at Willesden Junction can have a train terminate and run back north to Harlesden. We’ve added the missing berth, which is useful when London Overground terminate trains there
- At Nunhead, we had signal 452 listed twice, and we’ve corrected this
- Trains to and from Selby at Temple Hirst Junction between Doncaster and York now show in all berths on the line, and route indications for trains to and from the branch will now appear
- Signal G426 at Cheltenham Spa is now shown as a ground position light (GPL), not a main aspect
- Missing signal B66 near Nailsea & Yatton is now on the map, so trains will no longer disappear there
- Some errors crept in around the junction to Yate – two signals were missed, and some route indications were incorrectly drawn
- We now have route indications around Newport
We’ve also started planning for the migration to our new back-end server infrastructure, which will start with our train describer processor. Once this is live, the hit-and-miss linking between trains on the map and schedule data will be much, much more robust. More on that in later weeks.
After several months of behind-the-scenes work, we’ve moved the last of our services to our new infrastructure. You will hopefully have seen no impact at all, although a couple of people reported problems on Thursday when we moved our front-end servers.
The new infrastructure gives us much more resilience than before, and also allows us to scale up and down according to demand. When we’ve done this in the past, it’s been a manual process.
Now that everything has been successfully migrated, we’re going to start on rolling out the new version of OpenTrainTimes. This will happen slowly and gradually, and there won’t be any ‘big bang’ change. More about that in weeks to come.
We’ve almost caught up with the backlog of map updates – here are some things we’ve done recently:
There are a lot of support tickets with fixes to implement, which we’ll be doing over the next few weeks and making more frequent releases.
That’s your lot for now – we’ll be back soon with more details of the new version and how we’re going to roll it out. Stay tuned!
The last week hasn’t been great in terms of availability of our data feeds. We’ve had numerous outages that are outside our control:
- On 3rd June, we had an outage of all our data feeds from 0320 to around 0333. This was followed by a period of high latency (the delay between a message being generated by a train describer and it being received by our systems – sometimes known as lag) between 0446 and 0512, then from 0518 to 0524. From 0631 to around 0735, data was being received by our systems between 15 seconds a 2 minutes late.
- On 4th June, we had an outage of all our data feeds from 2342 (on 3rd June) to around 0912. This resulted in our live track diagrams freezing for the duration of the outage, and for some hours afterwards, maps showing out-of-date data and the location screens not reporting any train movements.
- On 5th June, we had an outage of all our data feeds from 0941 to 1103 – again resulting in our maps showing out-of-date data for some time after the feeds returned, due to the nature of the feeds.
- On 6th June, we had a partial outage on our train movement data feed from 1740 until around 2115 on 7th June. Our monitoring systems should have picked up this issue but didn’t – we are investigating why. On the same day, from 1747 to around 2130, we had an outage of all our our data feeds – both feeds returning to normal afterwards, but again resulting in our site showing incomplete and out-of-date data.
- On 7th June, we had an outage of all our data feeds from 0846 to 0851, although the maps will have updated quickly afterwards due to the volume of trains running in the end of the morning peak period
- On 8th June, we had an outage of our train describer feed between 1155 and 1201, from 1215 to 1311, from 1314 to 1328, from 1343 to 1350, from 1358 to 1407, from 1415 to 1430, and from 1438 to 1440. During this time, the train movement feed was operating normally, but this issue caused our maps to freeze repeatedly and intermittently for nearly two and a half hours.
- On 9th June, we had an outage of all our feeds between 1320 and 1350, a partial outage between 1428 and 1440, then a full outage from 1440 to 1453, followed by a further outage between 1601 and 1620.
Quite rightly, many of you have voiced your concern over our inability to provide you with a useful service over the past week. We have no control over the Open Data feeds, which are available to anyone at https://datafeeds.networkrail.co.uk/, and we are not happy at the huge number of outages and the combined total downtime over the past week. These issues have been happening for months, if not years, with seemingly no resolution in sight.
We are facing a difficult decision: do we continue to use the public feeds to operate the OpenTrainTimes public website, or do we move to more reliable feeds which aren’t available to, or suitable for, many other developers and websites to use – since they’re not quick to set up, and not free to use when you consider the additional hardware and technical work required. The answer to this isn’t simple, and we continue to hope that the Open Data feeds will be fixed so that everyone can benefit from them.
We are back to a sorry state of affairs, similar to the problems we had back in December 2018, where the train describer feed from the Network Rail Data Feeds platform starts sending message through later and later, then finally drops lots of messages.
This isn’t a problem affecting just us – sites such as RailCam and Traksy are also affected. There are alternative feeds that we can use which don’t have this problem of late and missing messages, but using them at the moment wouldn’t be in the interests of the whole Open Data community. For this reason, we’ve decided to let the quality of information on our site degrade so we can get the right level of focus on the problem.
Happy New Year from all of us at OpenTrainTimes!
We’ve just released a slightly delayed set of updates to the site. These were due to go live about a week ago, but due to illness we didn’t have time to test everything to our satisfaction.
In this release:
- A new map of Mossley Hill to Runcorn, covering the new workstations at Manchester ROC, as well as Ditton signal box. Garston Intermodal Freight Terminal is also drawn
- Improved functionality from the new control system at York ROC means we can show, and we’ve added, routes and signal aspects for the whole of the York area, covering York station and parts of the surrounding routes
- The Hull area map now contains route indications
Minor fixes include adding a missing signal at Cogload Junction, L394 signal at Seven Kings, F456 signal at Feltham, W367 signal at Southfields, 1999 signal at Gilberdyke, and new platforms berths at Skipton, Ilkley and Bradford Forster Square.
Unfortunately, at least three maps – the Exeter, Liverpool Street and Airedale maps have become corrupted during deployment and rather than rolling back the whole release, we’ll fix them as soon as we can.
The last few months have been hectic. We’re continuing to work on the next major release of the site, which is a total rewrite – and to make sure the public-facing site remains free, we’ve been taking on more consultancy and software development work for the rail industry. Some of the projects that have had our input are very interesting, but not in the public domain – but the important thing is they’ll make sure there is always a public, free version of the site.
Many of you will have noticed that the Network Rail Data Feeds platform has been substantially less reliable than we need it to be over the past weeks and months. Outages started happening several times a day, meaning we weren’t able to bring you accurate information. This didn’t just affect us – all other sites using the Open Data platform were affected. The sheer scale of the problem and the number of people affected has been brought to Network Rail’s attention, and their supplier and maintainer of the Data Feeds platform is working on making it more stable.
Separately, we’ve invested a great deal of time and a lot of money in getting resilient connectivity set up to Network Rail for our commercial projects. We are seriously considering moving the public-facing website over to this feed – but there’s work to do so we obfuscate (hide) freight and engineering trains in the same way as the Open Data feed does. This will mean we’ll be immune to any future outages that affect the Open Data platform, which is obviously good – but is this the right thing for us to do? Having such a large and visible site to highlight problems with the data feeds is useful – it means there’s one more big name that’s affected when problems occur, and that helps get the problems fixed for everyone, not just us. Maybe we should continue with the public site using public feeds. Comment on this post with your thoughts.
We’ve set up a status site to show you what’s going on. Any outages will be reported here once our systems detect them, and also tweeted to a new account (details to come). You can subscribe via email to alerts too.
This status page plugs directly in to our monitoring systems, which we’ve moved over to Amazon EC2 so we can run the public site alongside our commercial products. Over Christmas, we’re going to be moving the last bits of the website over. You shouldn’t see anything different.
Finally, we made a few updates to the existing site:
- The Filton 4-Tracking project has completed, and our Bristol Parkway map has been updated. We’ve had to move the Avonmouth route on to a new map, because there’s simply no way we could manage to fit it on to the existing map!
- The line between Saltmarshe, Howden and Ferriby has been recontrolled to York ROC, and is now available on our Hull area map
- The Thameslink route through Wimbledon was moved to new signalling system at Three Bridges ROC some months ago and, a little late, we’ve updated our map to include route and signal indications
Until the next time, have a peaceful festive period, and see you in 2019!
Our new site infrastructure is progressing really well. The mapping engine is under test at the moment, and we have a big configuration exercise about to start to get it all working. More on that in a few weeks.
Despite all the testing, we’ve released a map of the Horsham area, and fixed a couple of issues on the Derby map.
Earlier this week, we launched our updated Derby map and promised that we’d be adding route indications in due course. Today, we released the update, along with several other issues fixed:
- A crossover from Royal Oak Sidings at Paddington was commissioned at Christmas and is now present on the map
- We’ve included two berths at Glenrothes with Thornton which will more accurately show trains in the station
- There’s a new pair of berths between Shiplake and Henley which will stop trains disappearing on the branch
- Signal 2490 at Oxford now shows descriptions when trains pass through
- Two berths near Proof House Junction outside Birmingham New Street were showing incorrect descriptions
We’re still working hard on our new Scottish map – more on that in a subsequent update.
This week, we’ve been working on extending existing maps to continue to cover more of the railway network, and so the following maps have extra track and signalling:
Due to popular request, we’re now displaying the last train that entered a platform at London Kings Cross. Let us know what you think of it – positive or negative!
We’ve also fixed bugs at Woodborough Sidings, Liverpool Lime Street, between Poynton and Adington, and signal 2215 at Swindon – all of which were reported as bugs to firstname.lastname@example.org. Every email you send to the support email address is logged and used to help us prioritise what to fix and work on next.