Bus-Stops.csv for Tube & DLR


#1

Is there a up to date CSV station list for the Tube & DLR, I’m aware of the StopPoints api endpoint but I’d prefer a csv version.

Thanks


#2

I concur, a fully valid, up to date geocoded layer of Tube/DLR/Overground/NR stops in the same style as bus_stops.csv and bus-sequences.csv would be very convenient. Personally I am working on static analyses mainly, so I don’t need a dynamic dataset; furthermore querying an API thousands of times in order to construct a whole network is not really ideal.


#3

I think you may both be interested in Stops.csv from data.gov.uk

Go to https://data.gov.uk/dataset/naptan
Click on "Download CSV (30.0 MB)"
Open zip file that arrives
Copy Stops.csv to your computer
… and open.


#4

Thank you for referring to that data, while naptan may be a good up to date stop dataset, it doesn’t allow you to construct a network from the data, as there are no sequence files or route files.

As far as I am aware this data just doesn’t exist in static format, especially for London Tube/DLR/Overground/NR stops.

I may have hijacked the topic a bit, but fundamentally, having sequence data in a static format along with stop data would make network building very easy and avoid needing to construct massive API queries.


#5

@wa-ssx we build Naptan into a network in the API, so you should be able to traverse the network using Naptan and line identifiers on the REST API with no additional effort.

For examples, see https://blog.tfl.gov.uk/2015/10/19/unified-api-part-3-rot-routes-of-things/

Back to your point on wanting a full download to do static analysis - this is something we have considered in the past. After all, we’ve joined all of the disparate data sets together behind the scenes, and a REST API is not always the best if you want “everything”.

I’d be interested to know what data and in which formats would be useful for this? Would it basically be a full dump of our StopPoint API, and a full dump of Line/Route/Sequence? Would JSON be OK?


#6

Hi Tim, thank you for the reply.

We actually have been writing a python script that sort of does what you mention, albeit very slowly, and we haven’t managed the whole city’s multi-modal network due to the sheer volume of buses.

As I mentioned previously, the bus-sequences.csv seems perfect if it was done for all other modes, a csv list of stops in order, with the easting/northing and relevant naptan/atco etc codes. This would be enough for example to write a simple script that joins them into a network with links. So if there was a correct and regularly updated bus-sequences.csv and tube-sequences.csv etc it would make it a lot easier to work on.

But JSON would also be great if it takes less time on your side to produce than a cleaned up csv.

The real pie in the sky ideal would be to be able to have the journey time between each stop in a table (at say 8:30am), so each row says the source and target stop and then the journey time 'stop 1->‘stop2’ ‘3 minutes’. Then it would be even simpler to construct a multi-modal network if you just combine it with the stop locations, which are already available. (Querying journey times between every stop is another API query we have found to be very very slow to do, especially for buses).


Do TfL plan on releasing their network in GTFS format?
#7

I see what you’re saying - kind of like a directed graph, where each node has a stop point id, and every edge has a weight that gives you the journey time. Probably multiple edges actually, for the different line/routes. As you say, you could look up the stop point’s full info given the id.

We actually build that network behind the scenes in our relational database, using the timetables, but we throw away the average journey time between nodes (or the 8:30am time, as you say) while we do so. It wouldn’t be a huge leap to retain that info on each of our RouteSection elements…

Funnily enough we’re investigating something related with regards to intermediate data formats for mapping - where again having the whole network data is useful. Directed Graphs also came up for that…

Anyway these are just ideas for now but keep the suggestions coming.