I use the following data feed: https://tfl.gov.uk/tfl/syndication/feeds/bus-sequences.csv
I noticed that with the recent route updates, this hasn’t yet been updated (for example, the 16 terminates at Paddington now, but the feed still goes on to Victoria Station).
According to this page: Our open data - Transport for London - the data should be updated weekly.
Have you tried using https://tfl.gov.uk/tfl/syndication/feeds/journey-planner-timetables.zip ? I have found this to be both realisable and updated weekly (sometimes more often)
@Mulder
I suspect that the documentation on these csv sets is many years old and does not reflect the actual frequency of updating.
Unless it meant “weakly”…
@briantist is right about the zip file but the data need to be extracted from several hundred xml files. Sometimes there is more than one file available for a route - for example the new 16 file was available alongside the old for a couple of weeks to enable journeys each side of the change to be planned so you may need to look at the service start date. I have also come across a few files where the stop sequences for different days of the week are (incorrectly) inconsistent, usually because only some days of the week have a revised service and the stop sequence has changed since the service for other days of the week was done. This messes up the stop sequence numbers for some journeys.
But apart from that it’s easy…
@Mulder If you need help decoding the date-period-validity from the TransXchange format files, I have managed it…
Hi @Mulder
We’ll speak to our colleague who produce that report output. It appears that the file was shipped to us on 3 May but still has old routes in it - I’m not sure what creation date the actual report has compared to the upload date and this may have been before the routes were updated.
It is very much a point in time though so I would suggest using the TransXChange as @briantist suggeste. This is updated every week and has existing and upcoming schedules (with start/end dates) and the Unified API which updates as soon as the new schedule is in place.
Thanks,
James
@briantist
I gave up worrying about the assorted days of operation and non-operation fields years ago. Are you doing anything over and above using /Services/Service/OperatingPeriod/StartDate and /Services/Service/OperatingPeriod/EndDate?
StartDate does not show the actual start date but if it is not in the future it should mean that the service is live for the days contained in that file. EndDate also is not a real end date unless the service really is due to be replaced in the failry near future.
That is my understanding, anyway.
@mjcarchive That sounds about right. As I run a process on the whole datafile at 0530 to ensure that the current day’s data is in “view table”.
As I’m only needing the bus stops associated with a transport stop (tube, rail and DLR in London) I’m just creating lots of (json-format Postgres) per-hour “views” for each of those…
This means I can allow the user to plug into the “live stop data”
– from RTI
It would be good if the companion csv file, the plain bus stops list could be updated too.
Simon
Thank you for all the suggestions. I’ve decided to move to the Unified API and use https://api.tfl.gov.uk/Line/16/Route/Sequence/all instead - is there any reason I shouldn’t be using this?
