Improved and updated step-free access and toilet data

Hi everyone,

We have just released an improvement to our step-free access and toilet data.

This was previously in a dataset known as “lrad-v2”, which hadn’t been updated for a while. We will be retiring “lrad-v2” soon as it is out of date and we will just be keeping the new format data up to date.

The new data is available in GTFS format, and also in our own more detailed spec which allows us to include additional information not in the GTFS spec (e.g. step and gap between platform and train).

The new data works alongside our new lift disruption API.

Please see this specification for additional info about the data. Any further questions let me know.

I have added all of these links to the “Our Open Data” webpage under “Accessibility and toilets”

Hope this helps, and please share any feedback you might have, thanks!



Thanks for this. It’s interesting that this has arrived at the same time as National Rail Lifts & Escalators version 2 which, rather shockingly, actually works this time.

As I implemented the NR API first, I’ve got objects which look like this which seem to be linked to a primary key “sensorId” which you can use a all of the objects

  "id": "831",
  "crs": "BXH",
  "type": "Lift",
  "uprn": "u022369000001",
  "location": "Platform 1",
  "sensorId": "7991",
  "description": "Lift 1, Platform 1",
  "displayName": "Lift 1 Platform 1"

there’s a separate call to get the state of all the sensors, which come back as one of three values


This compares with the TfL call which lifts just disruptions.

I’ve looked at the stops.txt CSV file in and this is a list of stations that can then be used with the pathways.txt CSV part of the ZIP.

This gives the pathway_id as the useful index, and you can create the name of the lift by using the from_stop_id and to_stop_id for “from” and “to” where pathway_mode=5 (for “lift”).

The only annoying thing is matching the data from Disruptions/Lifts/v2 as these disruptedLiftUniqueIds are partial matches to the end of pathway_id.

 SELECT * FROM public.liftsandescalators where "sensorId" ilike '%940GZZDLPRE-Lift-2' 

But otherwise this is very useful and easily linked to having single table for National Rail and TfL lifts, so thanks.

@jwithers A little more with the question about the index objects. At Poplar there are six lifts listed in the dataset (pathway_mode=5)…

  • 940GZZDLPOP-1002064-DLRW-4-940GZZDLPOP-1002064-BRIDG-5-lift-940GZZDLPOP-Lift-2
  • 940GZZDLPOP-1002064-DLRE-2-940GZZDLPOP-1002064-BRIDG-5-lift-940GZZDLPOP-Lift-1
  • 940GZZDLPOP-1002064-CONC-6-940GZZDLPOP-1002064-DLRW-4-lift-940GZZDLPOP-Lift-2
  • 940GZZDLPOP-1002064-CONC-6-940GZZDLPOP-1002064-DLRE-2-lift-940GZZDLPOP-Lift-1
  • 940GZZDLPOP-1002064-CONC-6-940GZZDLPOP-1002064-BRIDG-5-lift-940GZZDLPOP-Lift-2
  • 940GZZDLPOP-1002064-CONC-6-940GZZDLPOP-1002064-BRIDG-5-lift-940GZZDLPOP-Lift-1

But there are two problems listed in the /Disruptions/Lifts/v2 endpoint…

So I end up with six matching items for the two items “940GZZDLPOP-Lift-1” and “940GZZDLPOP-Lift-2”

I get it that these are two lifts that stop at more than one level, but I’m not sure how I’m supposed to see that in the dataset.

Use the detailed dataset, which has the IDs that match the lift disruption API. Here are the 2 lifts in Lifts.csv. The location IDs that the lifts serve match those in the stops.txt GTFS dataset, so the 2 datasets be used in tandem.



I didn’t really want to have to cross-reference another ZIP file!

Seems like the FOI team, or whoever they used as a source internally within the company, needs to be informed of the new GTFS dataset, as they have provided an entirely false response to someone’s FOI request, claiming that “TfL does not currently use or produce any GTFS data”.

1 Like

Hi @arturs - I’ve flagged that change to the FOI team to update the response. I suspect they were using the reply to previous requests for GTFS data before these went online.