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).
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
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.
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.
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”.
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.