5 Jul 2023 by Jonathan Raper

It’s not often that a story about transport data begins in the theatre.  But in this case it begins at Chichester Festival Theatre with a  performance of  Assassins on 20th  June 2023… and a dash to the station at the end to catch the last  direct train to London at 21.40. Trotting to the station I took my first  look at the SWR app (powered by TransportAPI), only to see that all of  the stops from the origin in Portsmouth were marked ‘delayed’. It looked  like the train was going to be a bit late and we could probably slow  down the trotting a bit.

However, on arrival at the station with two minutes to spare it was  already clear that all was not well. Our train was now 13 minutes late,  which was a problem as this service normally couples up to another  service from Bognor Regis that waits at Horsham for us. But as we  watched the departure board, without any fanfare the destination of the  service changed from Horsham to Barnham, which is the next station along  from Chichester.

There was an audible reaction from people on the platform: we all now knew that our train to London had been effectively cancelled as there was no way to get from Barnham to Horsham to connect with the waiting train there. The next service was an hour later, required a change at Gatwick airport, and had a journey time 30 minutes longer. So that would be a 90 minute delay, arriving at 00.40 after the last tubes have gone, rather than 23.14 without a change.

Curiously, through this short travel drama played out on the platform displays and in the app… no announcements were made in the station and no options were suggested. It was not a great customer experience at a time when we are trying to rebuild rail ridership. So my thoughts turned to Delay Repay and finding out what happened.

However, if you want to look back at a service history, what can you find out? It’s the old adage that if you can’t measure it, you can’t improve it…

At the moment the Historical Service Performance API available from RDG and dating back to 2016 only allows you to retrieve the actual times run by the train at the end of the service. The picture below left in black shows the sum total of the data available for the 21:40 train we were trying to catch at Chichester (CCH). The only way you can tell that the final stop was cancelled is by the absence of an actual time at Horsham (HRH), reason 574 can be either a delay or a cancellation and it only gives the ‘RID’ code to identify the train, so this is not very comprehensive. 

To improve the data available TransportAPI has partnered with Northern Trains to produce a rich new API source of rail performance data capable of telling the full story of every train journey at every location on the network. The TAPI Rail performance managed service offers:

• Station Actual Journey endpoint, like a historic departure board with configurable time windows before and after the time of interest (so you can collect a whole day if you want)
• Service Actual Journey endpoint for every minute of each journey to allow a full journey replay, either a single journey or a collection (so you can get every train an operator runs within a time window)

Both endpoints capture scheduled, actual [and]{style=“text-decoration: underline;”} expected times recorded for each minute of each journey along with all delay and cancellation reasons from the industry Darwin service. A snippet of the equivalent TAPI Rail performance data record for the train we were trying to catch after the theatre is shown above in JSON form, showing the different references to the train that we support (we got no retail services ID for the 21:40). Below in table form we show the full record for the train service at the clock time when our part-cancelled 21:40 train actually departed Chichester at 21.56. You can see ‘cancelled’ is TRUE for the stops and passing points between Barnham and Horsham.

The TAPI Rail performance managed service offers a significant new channel of access to historic rail data. As it is available at an API rather than a web interface like the RTTI history page on nationalrail.co.uk, it can be used by developers to produce versatile new insights on the performance of the network and the experience of customers.

Some examples of insight that the API access can support includes the following, and data extracted from the API is tabulated below to illustrate what is possible:

• Recording how long before departure the whole and part-cancellations are announced (as we store all schedule changes). In the example of the 21:40 train the notice to customers of a service change was zero minutes as the leg to HRH was cancelled at the same time it was scheduled to depart. The table below shows the advance notice times for all the other service changes/ cancellations on the CCH to HRH route on 20th June… there is usually enough time to alert customers to make another plan.
• Alternative route comparisons can be made using the origin, calling_at and destination filters.
• The changing expected departure times shown to the customer can be tracked as lateness can increase for a particular train until subsequent connections are at risk. In the example below for the 21:40 train, the lateness rises from 11 to 16 minutes on its way from Portsmouth to Chichester, and the cancellation seems to have been made when the service waiting at Horsham could not be held any longer.
• The amount of lateness attributed to the various delay reasons can be tracked… some trains from CCH to HRH on 20th June ran early while also advertising a delay reason!
• Comparison of different operators over the same route e.g. open access versus DfT-funded operators where they compete.
• Measurement of the reduction of the total capacity in coaches between stations after cancellations.
• Minimum,  maximum and average passenger minutes per day, per route can be measured. On the CCH to HRH route on 20th June, 12/25 trains were right-time and 2/25 were cancelled.

These examples indicate the range of customer experiences that can be measured using the richer data available at the TAPI Rail performance API.

You can try out the endpoints by signing up for a free trial account and exploring the API documentation.

Now we can make our delay-repay claim for the 21:40 knowing the whole story!