@SJCooper
You must have been very bored!
I am aware that some “second stops” on a route are designated as special timing points for QSI purposes because there are difficulties getting the times for the first (departure) stop. Maybe STHQ stops are dummy stops for a similar purpose (tyhe second stop being too far away?).
@SJCooper
Thanks for your reply.
Yes, there would be some point in showing arrival times at last stops and quite likely that usually happens. There is more need for it at earlier stops though and that was what I wanted to focus on.
Yes, 366 (where did I get 147 from as it used to be 145?). I understand the difficulty with lengthy H&R sections but many H&R points (not the same thing, perhaps) do have SMS codes and do generate predictions, I think.
Agreed Jail Lane is a virtual bus stop but it it is located pretty much bang on the non-virtual bus shelter at Berry’s Green. Only one of the two stops should be in the southbound sequence.
I think a bus was in the way when I looked at Clayton Road on GSM! I can see it now. As it is the Datastore JP files I wonder if it could pop up on JP itself?
I was unaware of the role of the 1xxxx codes on LVF. Not sure i can get my head round how you get the data out with a dummy code!
Hi, just to let you know that I’m taking a look at these five stops.
The Colindale Superstores stop is an interesting one: marked as a “Dead Bus Stand”, and Google Street View shows a sign saying “do not stand buses here” (in March this year). But in Adiona it appears in the stop sequence for Route 303. I’ll probably need to check with colleagues who are more familiar with whether Route 303 is actually supposed to stop there or not!
By the way, here is a more complete list of Feature Types, taken from our asset management system’s documentation:
| Code | Name |
|---|---|
| SHCE | Stop - Hail & Ride End Point |
| SHCP | Stop - Hail & Ride Start Point |
| SLRS | Stop - London River Services |
| STBC | Stop - Bus Compulsory |
| STBE | Stop - Dead Bus Stand |
| STBN | Stop - No Flag (Hail + Ride TT |
| STBR | Stop - Bus Request |
| STBS | Stop - Live Bus Stand |
| STCC | Stop - Coach Compulsory |
| STCR | Stop - Coach Request |
| STDJ | Stop - Bus Compulsory CoachReq |
| STDL | Stop - Bus Request Coach Req |
| STDM | Stop - Dummy (No Physical Stop |
| STDQ | Stop - Stn D/Unit w QSlats |
| STDR | Stop - Dial a Ride |
| STHQ | Stop - Stn Hanging w QSlats |
| STNA | Stop - No Public Access |
| STNU | STOP - NOT USED |
| STRR | Stop - Rail Replacement |
| STRS | Stop - Tram Stop |
| STSS | Stop - Bus Station Stop |
| STTE | Stop - Temporary Stop |
| STTP | Stop - Timing Point for CAESAR |
| STTS | Stop - Taxi Stop |
| STVA | Stop - Virtual - iBus Announce |
| STWQ | Stop - Stn Wall Mntd w QSlats |
| STZZ | Stop - Out of County |
An update on those five stops:
With regards to those Bobby Moore Academy Primary School and Sidings Street stops, they are present within the Journey Planner timetable but not in Adiona/iBus/Countdown. A quick look at Google Maps suggests these might only be temporary stops and therefore not captured in our asset management system. I’ll try to get more answers next week.
As for the Colindale Superstores stop, although this is present in the current Journey Planner timetable, it is not present in the timetable that comes into effect tomorrow. I suspect the discrepancies between systems will resolve themselves within the next couple of weeks.
I’ve ridden the 339 around the.stadium a couple of times recently from Shadwell to Stratford and the on bus iBUS screens just show * until they reach the Aquatics centre stop.
Simon
@LeonByford
While you are here may I ask you a question about the bus stop and sequence CSV databases?
I assume they are prepared as reports generated from the main Journey Planner database. Is there any reason why updated downloads cannot be made available on a reasonably regular basis? That is particularly important for the sequences which change more frequently than the stops.
Thanks.
Hi, I’m personally not very familiar with these CSV files or how they’re produced.
The “our open data” web page states that the data comes from iBus, which uses a very different dataset to Journey Planner.
May I ask if there is anything in these CSV files that you need that isn’t in our TransXChange data / Unified API / NaPTAN? Or do you want the CSV files because they’re more convenient to consume?
(cc @SarahLS)
I can’t speak for Misar but for us (LVF), it’s just very handy to have a list of a) all the bus stops and b) the bus route stop sequences in a very simple format.
One thing that would be handy is to know when bus stops are removed / moved / re-named. I believe we recently had a case whereby one of the SMS stop codes for the ImberBus route 23A which had been loaded into iBUS many years ago was re-used for a stop on TfL route 384. As we already had that stop code in our system, the system chose to use the name that it already had… (Oops), so having a definitive list of active / retired stops would have prevented this from happening as it would have been purged.
Simon
Apologies, I find it difficult to identify what lives where in your rather complex system.
Re your question, many years ago I started a program to obtain and display live bus arrivals from the API using the stop NaPTAN ATCO codes. At that time I discovered the two CSV downloads somewhere on your website. They were ideal to allow rapid searches by stop or route for the required ATCO whilst using the Internet (then limited speed and relatively high data charges) only to retrieve the arrivals at the selected stop. I augmented the TfL stop file with additional geo data (eg postcodes) for the stops to broaden the search options. However, the key benefit of the TfL stop file was (I assumed) to provide a list of every bus stop served by TfL and no others. Likewise, the sequence file with every TfL bus route.
Amazingly, using local databases is still very efficient and those files sufficed for most of my usage ever since. However, I realised recently that they are now deviating too far from reality, especially the sequences where you have been making many changes. NaPTAN’s stop downloads are updated frequently and I use them for additional useful information. Unfortunately, “490” only covers Greater London whilst “All London” extends far beyond your services (almost 3x as many stops).
Hence, I find myself in this thread discussing how to generate new CSVs from the weekly XML timetables. A complete list of unique stops should be relatively straightforward but I started with sequences as that is more pressing. I now know that extracting only “correct” sequences is far from straightforward. It was very convenient having TfL do it for me!
I’m not sure whether it’s possible to get these CSV files updated again, but thank you for your feedback; we can keep this in mind as we try to improve our provision of open data.
Extraction of a bus stop CSV list from the XML timetables was straightforward. I just downloaded the current XML zip to check that I picked up the changes at Cromwell Road BS last Monday. However, the part zips are still dated 22082023 with the files showing CreationDateTime=“2023-08-21T16:45:59.2876141+01:00” ModificationDateTime=“2023-08-21T16:45:59.2876141+01:00”.
I was under the impression from my reading here that the files are working timetables updated weekly in advance. Is that not the case?
@misar
That is odd as the zip file that I downloaded last Tuesday evening definitely had part files dated 29th.
@LeonByford explained a technical issue on caching (at the TfL end, not the user’s) a few weeks back but from my understanding of his explanation that would not have any impact several days after a new set of files was created.
@mjcarchive
Thanks. I just repeated the download and now also have the zips dated 29th.
Possibly my PC failed to download the first time and I opened the old zip.
@mjcarchive @SJCooper
I persevered with the XML files as they seem to be the only way to regularly update the stop and sequence CSV databases. Stops are no problem but creating a useful sequence database required a couple of pragmatic fixes. Your thoughts on possible flaws in the logic would be welcome.
The zip download typically duplicates around 50 routes. Referring only to the StopPoint and RouteLink segments, random checks revealed nothing extra of any use so the code ignores the duplicates. As previously discussed, many XMLs have large numbers of sequences. Extracting only the longest sequence in each direction seems to fully cover all routes. It reduces the sequence CSV from ~350,000 lines to ~55,000 lines. The recent FoI download has ~68,000 lines due to many duplicate sequences. Some are shorter runs but I don’t think they are needed for API bus arrivals.
I just download the stop sequences CSV and was surprised to see it had routes 439 and S2 in it which only started in March, so it seems that it is being updated again! 
Can anyone from TfL (@jamesevans ?) confirm how often it’s being updated please?
https://tfl.gov.uk/tfl/syndication/feeds/bus-sequences.csv
Simon
It would also be useful to know the source of the CSV data with an assessment of accuracy. I mentioned previously that I get varying and different results extracting sequences (or stops) from the XML timetables or the API JSON output. There is no way of knowing whether changes each week are genuine or errors in the files so a TfL source of known reliability would be invaluable.
While checking https://tfl.gov.uk/tfl/syndication/feeds/bus-sequences.csv for “phantom” bus sequences I noticed that as well as the expected 328 there are many sequences for Y328 which from the stops seems to be the same route. Does anyone know what Y328 is?
The ‘Y’ prefix routes are variations of the same non-prefixed routes of the same number that operate during the Notting Hill carnival.
Simon
hi @SJCooper
We have a new file every 2 weeks generated from the scheduling system and this lines up with the iBus release I believe. Unfortunately, one of my team has to do the last bit and copy it to the relevant location to serve from the syndication/feeds folder, so exact timing is a bit variable each time.
We’re looking to automate the last hop, but this is a backlog item that needs prioritising. We’ll let you know how that goes in the next few months.
Many thanks,
James
