NEW DATA RELEASE - Common User Format (CUF) electronic timetable data for London Underground


#1

The Common User Format (CUF) is electronic timetable data for each line on the Underground, specifically designed for use in signalling and control systems but also useful for other applications that need to work with timetable data. This data set has richer information about stops and NAPTANS than the timetable data we share in our API.

Read the Technical specification and access the data files here

As ever, we’d love to hear about how you use our open data so please share your ideas with us.

If you have any questions about the CUF data, please post them here and we’ll get one of our experts to answer them.


#2

Glad to see this finally released. Only took a few years of me asking :joy::joy:. Still thanks to Charles and Colin at scheduling services for all their help. One issue I’ve noticed is the recent Easter weekend timetables where not included so not available in the feed. Why were they omitted ?


#3

Yet again another Bank Holiday with a timetable that is not provided in the feed. What’s the point of a feed that doesn’t update with the days timetable?if the Timetable is used it should be available


#4

Brilliant!

Well this sort of works. I’m writing an app to show diversionary routes for MTR Crossrail so I have a lot of terminal stations. So now I have what looks like real data at Ealing Broadway…

And Stratford.

It’s certaainlt better than the blanks screens I had.

So, the residual problem is this one at Paddington


#5

This seems like a great idea. One additional feature that would be really useful from my point of view would be the equivalent of the CIF .msn file and/or the equivalent of the TIPLOC records in the main timetable file.
At present this data is only provided as an appendix in the documentation which makes it that much harder for developers to access.
This would provide translation between the internal codes and the real world descriptions and also deal with cases where the list changes - new locations, stations closed, etc.
Additionally, again from my own point of view, it would be really helpful if this included the physical location of each point (either lat/lon or easting/northing). It should also include some indication of the hierarchy of location points - the equivalent of parentId and topmostParentId in the API.


#6

Thanks for your feedback, Nick! I’ll pass your comments to the team who publish this data for them to review.