TfL Timetable Listings

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.

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

Greetings from Germany
~ 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?

Simon

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:

http://groups.google.com/group/transit-developers/browse_thr...

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?

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.

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.

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

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.

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?

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.

Simon

Has Boris redefined 'weekly' at City Hall?

Update Frequency Weekly
Release Date  21/10/2010
Metadata update  2010-10-22

So, it was updated on the 22nd October and yet all the files inside the zip are dated 28th October and it's now the 7th November.

Which part is updated weekly?

Simon

This is in regards to a TfL Timetable Listings data released on 2010-10-21.

There seems to be a multiple xml files with a similar name like below.
output_txc_48011i.xml, output_txc_48011j.xml
output_txc_60008m.xml, output_txc_60008n.xml

After looking into these files, it has come to my knowledge that these
files are almost identical (both operating period are from 2009-12-01 to
2010-12-23 in the <OperatingPeriod> tag) except for that fact that
stopping bus stops are little bit different.

Why are these similar xml files present?

Hi All,

In vehicle journeys, a run time is specified which indicates the relative time taken to traverse a timing link.

I'm trying to figure out if the runtime is given in minutes or seconds, an example; PT90S. Anyone have a definitive answer as to what format this is?

Many thanks,

Saeed.

Quote

"
There seems to be a multiple xml files with a similar name like below.
output_txc_48011i.xml, output_txc_48011j.xml
output_txc_60008m.xml, output_txc_60008n.xml
"

As far as I can tell, this happens when there is a revision to the timetable OR the data itself e.g. A bus route changes operator and gains a new timetable or there is a correction to the data itself.

The older files seem to be omitted from the next upload of the .ZIP file.

Hope this helps,

Simon

Saeed,

I've had a look on the DfT TransXChange website for you and found this....

Schema 2.4b

Relative time: Time as a duration, usually in minutes, for example, 5 minutes .

Run time. Relative time taken to traverse a timing link.
* See JourneyPatternTimingLink / RunTime.
* See VehicleJourneyTimingLink / RunTime

Hope this helps,

Simon

The new improved open data means I now need to register to get an updated copy of the data the has been easily available/downloadable since September????

:-(

There's been no update to the feed since 2/12/10 and no one to contact. A very poor show.

Has anyone got a response after registering to access this feed? I haven't. It's very frustrating!

Can you re-register response should be immediate.

They have finally now updated the files as at 3rd February.

Hi,

I am the developer of an open source TransXChange to GTFS converter. When working with the TransXChange export stream, I have noted a few issues which lead to invalid GTFS feed files and other potential problems:

1. Stop references that cannot be de-refrenced in the NaPTAN database

As commented above, the export stream includes stop codes that do not have corresponding entries in the NaPTAN stop database. These are, by ATCOCode reference number:

9300RQP, 9300WAP, 9400ZZLUDGY1, 490000239006, 490000276005, 999019415N, 999010137N, 490016845W, 999015458S, 999006610E, 400015817S, 400015816S, 2400A006470W, 190018709E, 999006610E, 999019023W, 44004408112B, 44004408113B, 999004523E1, 4000OC466S, 999006610E, 4000OC467S, 490018875N, 490008239E, 999013106W, 999016063S, 490008239W, 490018840S, 490018840N, 2400105529, 2400102257, 2400A18880A, 2400102259, 999005099S, 999011251NE, 999015710NE, 999004021N, 999008340N, 999005099N, 490006677N, 999006610E

The NaPTAN lookup is needed in order to generate WGS-84 coordinates. Stops without mandatory attributes such as WGS-84 coordinates cause an error in GTFS validation.

2. Duplicate DaysOfNonOperation

A common imperfection are overlapping DaysOfNonOperation in VehicleJourney definitions. Example: File output_txc_24165g.xml, VehicleJourney 24165gg2R1650176, ServiceRef SId_24165g2 defines NonOperatingDays as follows:
<DaysOfNonOperation><DateRange><StartDate>2010-11-06</StartDate><EndDate>2010-11-06</EndDate></DateRange><DateRange><StartDate>2010-11-06</StartDate><EndDate>2011-12-03</EndDate></DateRange></DaysOfNonOperation>

This causes a warning in GTFS validation. 2010-11-06 should not be duplicated.

3. Incorrect London Underground Destinations
The TransXChange exports include only a single Destination for a direction on a London Underground line. This seems incorrect. Detailed Destinations can be looked up on the journeyplanner web site corresponding to individual trips. Although this passes GTFS validation, it introduces misleading trip Destinations. As an example, LId_01DIS0 and the associated services only include the Destination "Upminster" although the Desintations vary by individual trip.

Any chance these issues can be corrected?

Sorry but I can't find the attached zip file containing the 800 sample xml files. Does anyone know where it is?

Sorry but I can't see a link to the zip file. Anyone know where it is?

Nic,

Apologies but this data is no longer provided on the Datastore and is only available via the TfL Developer area.  We recognise that this requires you to register on the site but this is current TfL policy.

The Datastore page will be amended to reflect these changes.

Regards

Gareth

London Datastore Team

5. <VehicleJourney> times after midnight

VehicleJourney's with times after midnight cannot be resolved to the correct calendar day. The "easiest" solution would be to use VehicleJourney times exported in the 25 hour format.

Example of this problem:

Line: Hammersmith

Station: King’s Cross St.Pancras Underground Station

Corresponding TransXChange file: output_txc_01HAM_.xml

VehicleJourney: 01HAM0R457

DepartureTime: 00:15:30

ServiceRef: SId_01HAM0 / DaysOfWeek: MondayToFriday

This VehicleJourney technically falls on a Monday calendar day at 00:15:30. This is a problem - the last VehicleJourney on a Sunday night ends before this time and there are no more trains in service at that time.

Correction to the above (5. <VehicleJourney> times after mid...

After some digging I found that the TransXChange 2.4 schema defines the tags <DepartureDayShift> and <ArrivalDayShift> to accompany <DepartureTime>s and <ArrivalTime>s respectively. These tags allow the proper assignment of times to a calendar day (in lieu of a 25 hour time format). It appears these should be used and it seems advisable to include these tags in the exports as soon as possible.

The journey planner team will review the stop codes and their relation to the NaPTAN codes, however have highlighted TFL is only responsible for the assignment of NaPTAN codes to stops which start 4900. Other codes are arranged by ATCO and NaPTAN - who should be contacted with any issues on these.

In relation to the second and third points, adjustments are being investigated and any corrections that can be inputted - without detriment to the system as a whole will be made.

Lisa, thank you. After following the feeds over some time, there's one more thing, regarding what I call "operator churn":

6. Operator churn

Operators enter and leave the stream almost weekly. Operator OId codes also change (rarely). Just recently, River Services switched from OId_05 to OId_31. I see this problem with feeds in Australia (New South Wales) as well, more severe there. Does this reflect reality? It seems unlikely that operator licenses change that rapidly.

This post to announce the release of version 1.7.0 of the TransXChange to GTFS converter. Download here:
http://code.google.com/p/googletransitdatafeed/

I have created a write-up how to set up the converter for TfL:
http://code.google.com/p/googletransitdatafeed/wiki/LondonTXC2GTFS
Bring time. Setting this up is not trivial. I have also posted a
sample converter script
http://code.google.com/p/googletransitdatafeed/wiki/LondonConvertScript
that should get everybody most of the way.

The resulting GTFS file sets validate, but a few caveats exist, the
most significant two are:
- a handful of stop coordinates are not available from the national
database, and
- the issue regarding trips starting after midnight (as discussed on
this list)

NOTE: As of March 2011, the resulting GTFS data is expected to be
unsuitable for some production uses, such as trip planning. I
understand TfL are aware of the issues, so we'll have to wait and see
if the issues as I see them are being resolved over time.