I think this is best separated from the general cyberattack thread, even though some of the issues are probably related.
This first post relates primarily to routes with few or no predictions. A further post will look at the number of buses shown on the maps on bustimes.org.
A study over the last two days shows the following routes failing to provide predictions on London Vehicle Finder, and thus presumably on Countdown:-
39 53 131 143 180* 183 204 210 257 263 282 283 284 290 295 302* 314* 328 336 390 E8 U3 U4 W9*
The following report some predictions but less than 25% of the Peak Vehicle Requirement:-
4 7 80* 90 110 112 113 114 134 140 182 201 222 245 248 292* 411* 487 C11 H12 H13 H91 W8
I should qualify this a bit. All counts are for midday or the afternoon peak. It is for a school holiday week, which - if several computer records have to line up to enable predictions - may have brought in additional routes. Actual PVRs might be a bit lower too but not enough to change things much. They are also visual counts from a one-off snapshot so I might just have been unlucky.
Those marked with an asterisk also show less than 25% of the PVR when mapped on bustimes.org but very few of them show more than 75% on that measure.
OK, now for number of buses on the maps on bustimes.org.
The following routes show no buses on the maps:-
80* 180* 229 483 W9* S1 W12 W13 W14
The following show some buses but less than 25% of the PVR:-
8 56 98 292* 302* 314* 358 411* 469 W4
An asterisk denotes that predictions on LVF are also less than 25% of the PVR. Some of these routes show predictions as 100% of PVR, or very close to it. So while there is some overlap with the low prediction routes, most of the dodgy routes only feature in one of the lists.
At the other extreme three routes show more than 150% of the PVR on the route maps - routes 15, 228 and 301. Preliminary investigation suggests that buses from other routes are somehow being roped in, resulting in buses apparently miles away from their normal route. More to follow, I hope, but probably not quickly!
According to bustimes.org there are currently 7 vehicles out on route N18 in the middle of the afternoon. One of them is actually on 469 and the others on 308. 16 buses are shown currently on N15! Most of the buses actually operating on 56 are shown as 301.
I suspect that the problems with the bustimes.org maps are more widespread than I first thought. Of course I have no idea whether the issues are present in what they take (from BODS?) or in what BODS (?) is getting from TfL. It doesn’t appear to be the vehicle identifiers or the actual location, just (!) the attribution of buses to routes and I’m struggling to think how that can have happened. LVF is getting the route right, of course, but I appreciate that the sources they use are not necessarily identical. The misattribution to routes makes it look as if one operator is running on another’s routes, double deckers on single deck routes (hopefully no low bridges!) but don’t rush out to take photos - it is not real.
Oh, and on a small sample the routes now affected were fine before the cyberattack.
@jamesevans
Flagging you more because there has been no reaction to this thread than because it’s really for you! My main aim here is to scope and narrow down the problem, in the hope that it helps isolate the issues. It may be that TfL already knows perfectly well what is going wrong and how to put it right when priorities allow. If so that would be useful and reassuring to know.
The weekend’s changes have added 370 and H22 to the “few predictions” list. There may well be others but I am not going to check every route every week. Both show up just about tolerably on bustimes.org maps.
The return to schoolday schedules has helped, particularly on LVF. The routes now looking better are mostly still a bit short compared with PVR but they would not stand out if I were looking again from scratch. My amended lists for this are now:-
The following routes were failing to provide predictions on London Vehicle Finder (they may subsequently be providing the odd one or two now), and thus presumably on Countdown:-
39 103 (added via edit) 131 180* 210 257 283 284 290 295 390 E8 U3 U4 W9*
(thus 53 143 183 204 263 282 302 314 328 336 no longer feature)
The following were reporting some predictions but less than 25% of the Peak Vehicle Requirement (they may be reporting none now):-
4 7 80* 110 112 114 201 411* 487
(thus 90 113 134 140 182 222 245 248 292 C11 H12 H13 H91 W8 no longer feature)
The bustimes.org maps for 292 314 C11 and H18 now track reasonably.
Hi, I’m afraid I don’t have much to say on this. I’m aware that bustimes.org get predictions data from the Unified API and location data from BODS. Both of these are experiencing data quality issues due to mitigating actions taken as part of the response to the cyber incident.
These data quality issues are likely to be causing problems with the information displayed on bustimes.org and other websites and apps (including our own).
Thanks @LeonByford
In the hope that it might offer some clues as to what is (presumably) going wrong between TfL and BODS, let’s take a specific example. If I ask bustimes.org to map the 15, I get a mixture of weird and wonderful misreports. SE66 is currently somewhere round Abbey Wood on the 244, according to LVF, but on the bustimes map it is labelled as 15 to Charing Cross. If I click on it and look at the history I see
.
I’m not sure what “history” means when some of the times are two hours in the future but look at the pattern: 15-15-483-15-15-483. Wrong operator and destination (for the 483), wrong number of decks (for either).
Theories on a postcard…
Re the 180. How does the system work ? is there a table of which trackers are fitted to which bus… and the a list of which busses are diong the 180 route today ? or does the route number typed into the drivers ticket machine get reported ?
Currently Bustimes says there is only 1 x 180, and its parked at north greenwich… but mathew sommervilles traintimes.org is showing 5 x 180 running up and down the route. how is his page able to get the data that the other site is missing ?
@jcansell
In response to your post on “What is wrong with the 180”, which I am placing here because the issues are not restircted to the 180…
Bustimes.org uses actual location data from BODS. The only other way I can think of is by estimating position from successive predictions on Countdown so maybe that is what Matthew is doing. The number of 180 buses reported on London Vehicle Funder a few minutes ago was six, quite similar to the five detected on Matthew’s maps, so maybe that is how he is doing it.
The 483 is also interesting. LVF shows a full complement of predictions but bustimes.org shows only a handful of buses. The most interesting thing is that all those shown are in and around Harrow Bus Station. As when you looked, the only bustimes.org 180 shown is at North Greenwich (though according to LVF its next stop is Charlton Station). The clustering round a terminus must be telling us something. Like (perhaps) that is where a bus/duty is most likely to be at the same place at the same time in old and new schedules?
Hi. I have moved @jcansell’s message here to keep the discussion together.
The only thing I would add to the above is that traintimes.org solely uses the predictions data, so with the bus locations only being an approximation based on the crow’s flight distance between the two stops it is between and the estimated arrival time.
Conversely, bustimes.org uses the live location data from BODS to plot the buses on the map.
@LeonByford @jamesevans
Checking on this weekend’s changes, it looks like all are reporting decent numbers of predictions on Countdown/LVF. What is more, it looks as if the same is true for most and quite possibly all of the routes identified earlier in this thread. So it looks like whatever was messing that up has been overcome.
The bus location problem (data provided to BODS) is still with us through.
Some bus working timetables tomorrow would be nice!
We updated the static data base version, which seems to have addressed much of the issues. Thanks for confirming the situation is improved.
Top tip: You can check the current base version by making a request to:
https://countdown.api.tfl.gov.uk/interfaces/ura/instant_V1?ReturnList=BaseVersion
You’ll get a response like:
[4,"1.0",1731795847806]
[3,"20241115"]
20241115 being the current base version.
1 Like
