Station lifts data

I need to get a list of all lifts at each station, but I am struggling to find an accurate and up-to-date source for this despite looking into many options.

First port of call was lrad-v2 ( This however has not been updated since last year, so is not suitable. According to this post, lrad-v2 has been retired, and replaced by 2 new datasets. This sounds interesting, but despite almost a year having passed, there’s no information on where or how to access this. Have these actually been released yet? If so, where do I find them? If not, is there an ETA on when they’ll be released? (@jwithers)

I looked through the Open Data page on the TfL website, and found apparently yet another similar XML dataset - “Station facilities” under general. Expanding that, there’s a sample file to see the file structure, but no direct link to the full dataset. The only instruction is to go to the API portal, which does not mention this feed at all.

Some Googling also presented this dataset, but this seems to be extremely out of date (apparently last published in 2010). Before anyone mentions it, the /StopPoint/ endpoint in the Unified API does not have the data that I need - I need information about each actual lift, not just the total number of lifts in the station.

My intention is to create a list of lifts that may show up in the /Disruptions/Lifts/v2 feed, and map out what lines/platforms/exits they each serve. If someone knows of a dataset or API that may be more suitable than the ones I mentioned here, please do let me know.

I’ve just realised that the datasets in the 3rd and 4th paragraphs of my post are the same dataset so that resolves my issue of not being able to find it, but the point still stands that it’s 12 years out of date so an alternative is necessary


Just a thought. Can you use the Journey endpoint with the accessibilityPreference (noSolidStairs,noEscalators,noElevators,stepFreeToVehicle,stepFreeToPlatform) to get the up-to-date lifts information by picking a trip from say 940GZZLULVT to each place you want to get the lift data for?

No, for several reasons:

  • It doesn’t identify lifts (i.e. doesn’t mention any lift numbers or letters)
  • In many cases there are multiple routes between 2 lines so you cannot tell if only 1 or more are down, and cannot tell which specific one is down (going back to the first point).
  • You cannot target most areas of stations like mezzanines and concourses as origins/destinations using the Journey Planner

Another alternative that I’ve considered but is not viable is to just assume that the unique identifier for the lift is the NaPTAN, then “-Lift-”, then the number/letter that’s shown on the lift in person,;as I’ve already found inconsistencies in this (e.g. the signage using letters to identifier a lift in a station, but the /Disruptions/Lifts/v2 API feed using numbers instead). One notable example of this is that the lift to the Northern line was called “HUBMGT-Lift-5” by the API when I checked it last night, but there are only 4 public lifts in Moorgate, and they’re labelled A, B, C and D.

Only way I’m seeing that would make this practically possible is just a definitive list of all the lifts in a station, with an identifier and the start/end location of the lift, as in the lrad-v2 dataset (if only it were up-to-date).

1 Like

Hi @arturs, we are about to release the data set soon, just finalizing some last bits.
In the meanwhile, you can find a sneak peek of it at: - matching the GTFS standard - enriched data set, you can find the list of lifts to match tne lift disruptions API in this set.

Note that the final path will be different, just wanted to give you preview access!


This is great, thank you! The Lifts.csv file in the enriched data set is exactly the kind of data I was looking for


Hi @arturs

Just to pick up on your point above about labels of lifts, in relation to the data release Liron mentioned above.

A small caveat that the data on first release is a work in progress, so the lift friendly names (i.e. letters) won’t all be correct. The ones you pointed out could be fixed, but ultimately we won’t have all the data finished for launch

We’ll get as many right as we can and continue to improve them following launch