TfL Timetable Listings

SEPTEMBER 2010  Transport

Average: 3.9 (30 votes)

Multimodal working timetable data from the TfL Journey Planner, including Tube, Bus and DLR.

Please note that this data is updated weekly (every Thursday morning) by Transport for London. You should check the TfL Developer portal for details of the latest data updates.

ExtentGreater London
Author NameTransport for London
Update FrequencyWeekly
Source Category GLA Group
Metadata update2014-04-15
License SummaryTfL Terms and Conditions apply
Download URL
Apps using this data

BusIT London

Tags bus dlr riverboat timetable transport travel tube

3 MB on one line is not easy to read! And I have yet to find one service that is running. All I have seen is non operating from 1 jan til 31 dec.

Fri, 09/03/2010 19:06

Comment submitted by nonymous (not verified

Great Informations, thanks!
It's time for a open Web!

Greetings from Germany
~ Ramses Revengeday

Fri, 09/03/2010 21:14

Comment submitted by Ramses Revengeday

I've downloaded the latest Transxchange Publisher from the DfT website but it seems to have a problem with these files :-

1) Unless I turn off XML validation it throws up "org.xml.sax.SAXParseException: cvc-minLength-valid: Value '' with length = '0' is not facet-valid with respect to minLength '1' for type 'PopulatedStringType'. - more information may be found in the application log. "

2) It doesn't seem able to produce the maps, is this correct?

3) Like the post at 18:06 03/09/2010, It is showing journies as not operating?


Sat, 09/04/2010 11:18

Comment submitted by imon (not verified

Wow, thank you for releasing!

I've tried to convert the TransXChange feed into GTFS this morning. Although it is possible to generate the GTFS feed, there seems to be a problems with the originating data. Findings posted on the transit-developers e-group here:

In a nutshell, the services starting with 76167 (possibly more) are blacked out for all of 2010, through the use of the <DaysOfNonOperation> tag. This doesn't seem to be right - can the originators of the data shine some light on this?


Sat, 09/04/2010 18:05

Comment submitted by oachim Pfeiffer (not verified

Point 1 of the comments of Simon could be empty <Note> fields.

I have seen two <SpecialDaysOperation> blocks in an OperatingProfile block. That's not correct. Example: file output_txc_01BAK_.xml VehicleJourney with PrivateCode 01BAKOH349.

Sat, 09/04/2010 20:20

Comment submitted by nonymous (not verified

Good to see full timetable appear. 

Some of the options using the TransXChange Publisher don't seem to have any effect, namely the options to restrict to principal timing points (perhaps the feed makes no such distinction) and to merge journeys of similar frequency (which I take to mean replaced by "every 12 minutes until" or similar.  This probably explains the large sizes of files generated.

Also found it was necessary to switch validation off to get it to run. 

To get html output, map and diagnostic options have to be turned off, I think.

One wish list item would be for the ability to download individual files for routes, rather than download the whole thing every week, plus the ability to see when each file was updated.  Being able to spider it would be nicer still.

Mon, 09/06/2010 00:47

Comment submitted by nonymous (not verified

I've been working on a tool which may be helpful to developers, to let you browse the TransXchange objects . The SAX parsing ruby code for this is available. And a blog post explaining . It's a very raw data view at the moment, but I'll try and add some enhancements in the coming days

Mon, 09/06/2010 12:37

Comment submitted by Harry Wood

As noted by some other reviewers, there are a number of errors in the TXC files supplied by TfL. I have found:

1. Invalid doubled-up <SpecialDaysOperation> blocks

2. Invalid <Notes/> (should be missing or <Note>Text</Note>

Points 1 and 2 cause the document to fail when validating against the schema.

3. Totally non-operating services owing to (presumably misdeated) <DaysNonOperation> blocks

4. Non-NaPTAN stops (those with <StopPointRef> beginning 999, mostly stops outside London) incorrectly coded under <AnnotatedStopRef> rather than <StopPoint>. This error will cause the GTFS validation to fail.

5. All stops are shown as timing points (PTP status). This is a function of the scheduling program TfL uses and the TXC exporter.

And the other one, which isn't technically an error, is the missing <Track> elements that would allow you to create a route map. It would be required if these were registration documents submitted to the Traffic Commissioner, but London doesn't need to do that and this is an annoyance rather than anything else.

Finally, note that for buses these are "shadow timetables" where the times are not actual scheduled times, but times that are representative of the frequency operation of the buses.

If you want a "Next departures" service, then there is an API run through traveline - see e.g. Nextbuses apps for iPHone, Android. This has London bus departures, although only to the schedules and not real time as London Buses haven't yet made that data available.

While I am not responsible for the TfL data, I work for traveline and therefore work closely with the folk at TfL who generate it. I've made them aware of these errors, and they have promised to look into it urgently.

Mon, 09/06/2010 16:04

Comment submitted by tuart Reynolds (not verified

To make it simpler for everyone here to develop services wouldn't it be a lot easier if TfL corrected the timetable data at source and just published the data using a simpler open standard like GTFS?

Tue, 09/21/2010 15:05

Comment submitted by David Simmons (not verified

I've just downloaded the 2010-10-08 zip file. The good news is that the validation has been fixed (at least as far as TransXChange is concerned) but there are still no route maps.

The number of bus timetable files has droped from 759 to 725, some extra routes are included (KU1 - 3), some have been 'lost' (440) and others are attributed to the wrong operators.


Wed, 10/20/2010 23:02

Comment submitted by imon (not verified