Countdown data on 222 seriously bad

1

Last autumn, route 222 changed contract from London United to Metroline. Generally an improvement but now almost a majority of buses are “off the radar”. I have discussed this with the controller and it seems they are not “failing to inform” when buses are dispatched because they have no mechanism to do that. He suggested that the absence of a “Countdown Box” at the first stop “M in Uxbridge Bus Station” might be the issue. However, I think that the “system thinks” that the buses are still dispatched from Hounslow (London United) instead of Uxbridge (Metroline) so is “forecasting departures” on the basis of buses approaching from Hounslow when, in fact, they are usually put in the garage and a fresh one dispatched.

Who administers this data, not the webpage?

2

Hi @MikeYates - we’ve passed this query onto the Countdown team and we’ll let you know once we have a response.

thanks,
James

3

Yesterday my wife received an email from TFL Marketing with a link to:

which has the 222 under “London United Busways Ltd”
which is at least six months OUT OF DATE!
Why?

4

Hi @MikeYates

This is a manually created page with no dynamic updates. I have highlighted the issue to our Content Management team who will get this updated.

Thanks,
James

5

Thanks James
Just to let you know that there is a slight improvement in the middle of the route but departures from Uxbridge still show huge gaps (ignoring scheduled departures from depot) if there is a huge gap in Northbound buses and departures from Hounslow still show on schedule.

6

The issue is still affecting displays. Customer Services have assured me that it has nothing to do with depot location but the evidence flies in the face of that.

Does anyone know how to contact the actual administrators or developers of the system?

7

There is something buzzing round my brain that Countdown has an issue with departures (from anywhere) until the bus actually departs, or perhaps until the driver switches the engine on or presses a button to indicate that the next trip is about to starts. I thought that something was displayed but that it was of dubious accuracy, whereas here it seems that nothing is displayed on the electronic systems. Is it possible that the system is not displaying a bus leaving from the garage because it is getting no information about the location of the bus until the driver actually moves the bus? As that clearly wasn’t the case when the 222 was run from Hounslow, equally close to the other end of the route, that can’t be an answer on its own, unless something was being done at Hounslow to get the bus into the system that isn’t being done at Uxbridge.

Has anyone checked whether something similar happens with other routes started from and operated by Uxbridge depot?

8

The buses do have to “log on” as they leave the depot but that is not the issue. They are predicted up to 30 mins ahead and near the depot, if before log-on that is based on the timetable. Near the other end, it is based on buses approaching that end from the depot. Thus the system “needs to know” which end is the depot and, in the case of the 222, it is clearly at least six months out-of-date from the change of contractor.

The U5 changed from Metroline (Uxbridge) to Abelio (Hayes) about the same time (last Summer) and, though I do not use it so have taken only random samples, I think it has the same issue.

9

Had a bit of time on my hands, with the builders in. So I had a look at the 222 earlier today through using the London Vehicle Finder site at https://lvf.io/. This is a useful tool, as not only does it show you the next stop for every bus on the route but also shows the bus fleet and registration number. It also does not (or should not) “lose” vehicles during the day as it shows the most recent report generated by a bus until it finishes for the day - and even then it lists the vehicle as
having operated on the route.

I used LVF to capture data for the route at roughly three minute intervals for over an hour. I have put the results on an Excel file at http://mjcarchive.www.idnet.com/route222.xlsx; follow the colours to see where the buses were due next on each call. Unless the time due is more than a minute or two ahead (or impossible) I have not shown the time.

Four buses show particularly odd behaviour:

  • LK16DGO is initially shown as due to arrive at the first stop in Uxbridge at 1106. But at 1059 it materialises a being due next at Porters Way (a long way along he route) at 1128. I have no idea whether this (presumably bogus) expectation would appear on the Countdown screen. Then, at 1115, it is shown as due to arrive at the first Uxbridge stop at 1112!

  • LK16DFD is initially shown as due to arrive at the first stop in Uxbridge at 1126 but at 1129 it is shown due to arrive at Yiewsley Library at 1139. I did not continue long enough to see whether it reverted to Uxbridge at some stage.

  • LK67CXN is shown as due to arrive at the first stop in Uxbridge at 1145 but London Vehicle Finder shows it as not having operated on the route after 1150. I presume that it kept on reporting something (maybe not Uxbridge at 1145 throughout) until 1150 then disappeared form the feed.

  • LK16DGO is shown as due to arrive at the first stop in Uxbridge at 1047 … up to and including the 1114 report (I would not expect Countdown screens to edit out negative waiting times!), after which it shows up as expected at 1116

Of these four vehicles, the first three were the only ones (for which I observed claimed departure times) which I can be confident registered an expected arrival time at Belmont Road on the way in. Most buses registered their last expected arrival time at Crown Walk (the preceding stop). These appear to have then reported correctly for the outgoing journey.

Two vehicles - LK16DFL and LK16DFZ - set off southbound without having arrived from the south first (at least within the period viewed). These first cropped up in the LVF results after the first stop and if they appeared in the feed for the first stop it can only have been for the briefest period.

Also noted that LK67CXJ’s expected arrival time at the first Uxbridge stop changed at 1059 from 1116 to 1106. In effect it took the slot previously shown by LK16DGO above. LK16DGO then takes over the 1116 slot (as set out above)

As the terminus is effectively the depot, it is presumably comparatively easy to shuffle the vehicle pack around and put out another vehicle if (say) the arriving vehicle is late or has a mechanical or cleanliness problem. I can sort of see how confusion could arise in these circumstances; a bus has arrived so its path southbound can be projected but that path is actually used by another vehicle.

The other document worth a look is the working timetable at
https://s3-eu-west-1.amazonaws.com/bus.data.tfl.gov.uk/schedules/Schedule_222-MF.pdf. This shows two distinct stands in use for the route UX GR S (the garage) and UXBRSNHS (Bakers Road, Stop H stand). UX GR S actually occurs twice for some reason. Buses arriving at Stop M (the first pick up) can do so from either of these stands or straight from the depot (UX). The working timetable cannot be lined up with LVF as there is no identifier in common (plus, if there is disruption buses could work quite differently) but if the last reported call on arrival is relevant, that could be associated with the stand/source of the southbound bus.

A couple of unrelated points also stood out from the data. No expected arrival times at all were reported for stops between Hounslow West and The Bell in either direction. Instead we get times several minutes ahead at one or the other, depending on direction. Also there appears to have been an extended period during which buses from Uxbridge were expected at the Treaty Centre but presumably got turned short at The Bell (there is one identified short journey in the data). Perhaps there were local problems causing curtailment but I don;t think that can explain the missing tranche of stops; unexpected diversions do not usually “report” that way.

10

Yes, it’s still bad!
I’m on a 222 which left Uxbridge on schedule at 11:00 when the boards and phones said non till 11:14 when LK15DFE gets in from Hounslow. Just passed it!
This LK67CXM didn’t appear on the stops until it had left the second one, which has a board.

11

September and it’s still the same!
It’s 14 months since the 222 contract and hence depot-end changed.
If you want “the truth” near Uxbridge, southbound, you need the planned timetable because they are reliably dispatched. Near Hounslow, northbound, replace the nonsensical regularity of Countdown with actual southbound buses.

Thanks for all that work, mjarchive, which seems to confirm my theory, does it not?

Still no one has answered my question - is the software capable of changing depot-end?
Should I write to Sadiq for more software development (re-development) funding instead?

12

Hi @MikeYates

We’ve now had a response from the Buses technical team in TfL.

They informed us that these problems are primarily caused through a limitation of TfL’s current AVL system (iBus), in that it does not record bus performance before its first stop, therefore it does not provide an update to the schedules held in Countdown until it has actually arrived at its first stop.

Also, occasionally the first stop for a bus, may not be the first stop on a route, or a driver may not correctly log on to their AVL device, (which provides the updates to the Countdown algorithm), hence busses ‘appearing’ mid-route.

Another existing issue is when buses go on diversion, as the current system is limited as to how quickly these diversions are loaded into the system, so it does not always have this diversion route, without this route and schedule it cannot update its actual arrivals vs timetabled arrivals for the Countdown system.

These are known issues, and are being explored in feasibility for the new iBus2 system, although this project is only in its early stages, with the scope and delivery schedule yet to be agreed.

Hope this explains some of the anomalies you are seeing in the data from iBus.

Thanks,
Theo

13

Hmm. These points apply to all routes, surely? The “start of route” issue is something that I have observed before on an occasional basis.

The question is - why is it so uniquely bad on the 222 (and, Mike says, the U5)?

14

I have answered that question several times, today in an email to Theo Chapple.
Since the contract-change which reversed the depot-ends, near Uxbridge, outgoing 222’s are only predicted if there is an incoming one. no longer necessary now it is the depot, while U5’s are predicted as per the timetable and often fail to turn up because there was no incoming U5 at what is now the turnaround.

I doubt that it is easy to “change depot” for a route. That eventuality may have been unknown during development of the system. Perhaps the administrators may be reluctant to delete and re-enter a route to avoid downtime.

We have had over 14 months of poor prediction since those contracts changed.

15

Mike

My point is that I cannot see anything in Theo’s earlier posting which would directly be affected by a change of depot and thus might explain the stack of evidence that the system is not working properly for the 222.

Routes often change operator and depot when a new contract is issued. Changes can also occur during contracts. The 222 is not unique in that.

There are plenty of other routes where the first pick up point is very close to the depot (and where buses may well be scheduled to come out in a different order to that in which they went in). My local routes 29 and 141, for example. So the 222 is not unique in that either.

The 222 may well be unique in having changes from one depot close to the first stop to a depot at the other end equally close to the first stop. That’s pretty niche. I’m struggling to understand why changing depot might be a problem in that situation when it doesn’t seem to be for all the other routes which have changed depot. It is quite possible that it is the cause but if so I’d like to see something from TfL which says “yup, that’s it and we’ve worked out why”.

Do we even know for certain that there is a field within the data used for Countdown that represents the depot?

16

Unfortunately my private email to Theo bounced so I have put the contents into the other thread: “Who maintains the Countdown system?”