Case studies
Since our data feeds were made available in December 2012, developers have been creating websites and apps showing what’s happening on the network at any time
If you have an exciting app or website that you would like to have featured in our case studies page we’d love to hear from you! Get in touch at EthicsAndCorporateCompliance@networkrail.co.uk
Here are just a few examples:
Open Train Times
Open Train Times displays real-time arrival and departure information for each train company, helping passengers to plan their journeys. It also features track diagrams displaying the location of trains between signals.
You can read about creator Peter Hicks’ experiences working with our feeds below.
Realtime Trains
Realtime Trains is a source of live running information for the Great British railway network. Through its Track Your Train service, passengers are provided information about the current location, running and forward progress of a train service.
Recent Train Times
Recent Train Times shows the performance of individual trains, enabling users to see which train services are more punctual than others and plan their journeys.
Raildar
Raildar shows real time arrival and departure information, with live public performance measure (PPM) and cancellation statistics. It also allows users to search for specific train services.
trains.im
trains.im displays real time arrival and departure information and live Public Performance Measure (PPM) statics by train company and route-by-route breakdown (where available).
Using our data feeds
Peter Hicks, developer of Open Train Times
Open Train Times started about four years ago – a proof-of-concept to see what I could do with railway data from Network Rail.
I started off with a copy of the working timetable and quickly found the whole railway was far more complicated than I thought.
Once I’d understood how timetabling worked, I wanted to see what I could do with real-time data. I asked for access to TRUST and TD data feeds from Network Rail (the same ones which are now available to everyone on https://datafeeds.networkrail.co.uk) and was wholly surprised when I was told “Yes”.
Within a matter of weeks, I’d extended my proof-of-concept to include data on the trains I took to and from work, and word got out that Network Rail had a fantastic set of data that developers could use to give a new insight in to the railway.
That was a few years ago. I’ve developed Open Train Times wholly in my spare time, and it includes a growing number of live track diagrams (using the train describer feed), as well as a really comprehensive version of the working timetable.
It’s popular with staff who use it in an advisory capacity: platform staff use it to find out where trains are; I’ve had emails from signallers who want to see what’s happening at work when they’re off-shift; and I’ve been told that the British Transport Police have even used it when planning incident responses.
I have plans to develop the site further – more maps and more real-time data. It will never be the authoritative source for passenger data, but I’d really like it to be widely used by staff to help run the railway.
When I’m not developing the site, I spent a good chunk of my free time helping other people in the development community to understand how to work with the data that Network Rail have released. Given how much work I’ve put in to finding out how the data feeds work, it’s only fair that I spread that knowledge and help other people do good things too.
Peter’s three tips for developers
- Work out loud. There’s a community of developers who have likely come across the same problems you have; add something to the discussion.
- Understand the limitations of the data Network Rail supplies. A known level of accuracy is better than an unknown level of inaccuracy.
- Be positive and constructive.
Rob West, developer of Raildar
Raildar® started two years ago after my wife challenged me to see what I could produce with new data feed launched by Network Rail. I had used open data feeds before and initially I was simply interested in what data was being provided. I quickly realized there was a huge amount of data to explore.
Then I had to think of something I could do with it. I could just replicate the timetable, or show industry statistics, but to me, this didn’t spark an interest. I felt I wanted more of a challenge.
While the dataset isn’t the largest I have worked on, it is pretty vast. Processing it in real-time is a real challenge. However, more data has its advantages, as it tends to produce better results from statistical modeling. So I set about building my first mathematical model of the UK rail network.
The initial model was fairly simplistic, simply working on the TRUST data feed. I have now been working on version 5 of the core model for 18 months. It is now pretty advanced and much more complex than I originally thought it would be. Version 5 makes a step change away from TRUST to TD, which contains richer information. This change allows me to track trains at the berth level as opposed to the much coarser timing blocks. This will provide second accurate timings for much of the network, and more accurate plotting of train locations.
The future for Raildar® is to lever its core engine. Producing statistics for rail passengers and the rail industry alike. Version 5 promises new industry statistics, such as sectional running times, station dwell times and sub threshold delay minutes.
The Network Rail feeds are simple to integrate to, but the data is complex. The complexity of the data provides a great insight to complexity of the UK rail network itself. The UK is one of the busiest rail networks in the world and it great to have an understanding of how the network operates.
When I am sat on a delayed train, I take a little comfort from the fact that I understand a little of why it takes so long to fix, and hopefully the statistics I produce may help to reduce the delays in future.
Rob’s Top Tips for developers
- Research the datasets first. The data is complex and easy to misinterpret; however, there are good resources and a wealth of information online.
- Get involved. Not everything is known and other developers are researching certain fields. Contribute your discoveries.
- Start small. Don’t (as I did) subscribe to the whole country data set first. Learn with an area known to you; cleaning the whole country dataset needs a lot of maths.