Hi there,
We were wondering if you have any live vehicle position information available, with the actual positions of London buses (and other modes if possible)? This would be really interesting data to have available, which could be put to all sorts of good uses!
Is this something that the URA Countdown API provides in some way for buses already (perhaps as a stream)? If so, do you have any information/documentation on it and how to access it?
Thanks,
David
Hi David, we don’t have any live realtime positioning data available, only the highly processed output produced by Countdown, Trackernet, Daisy DLR and similar arrival time “predictions” systems. These are described in this blog, and all fall under the /Arrivals API.
In the past, developers have interpolated the arrival time combined with the network information on the /Line and /StopPoint API to estimate the vehicle position on the route, however that’s not easy!
Hi Tim,
Thanks for getting back to me. I take it there isn’t a feed directly from iBus (or similar) which could potentially be exposed to do this?
Thanks,
David
That raw data does exist, but we have no plans to expose the raw feed at this time.
Matthew Somerville did an excellent job of trying to show actual bus predictions. You can see it at Live London bus map
However, because it is based on interpolation using predictions and not actual positions, it also does a great job of demonstrating the unreliability of TFL’s predictions.
I don’t think I can embed a video here, but you can see it at https://vimeo.com/300465207
On the left I’m showing his live map and occasionally clicking on a bus so you can see the supposed data behind it.
On the right I’m showing a display (refreshed every minute) of arrival predictions taken from tfl’s Stoppoint/Arrivals. It’s showing predicted time to arrival (minutes and seconds) in second column and actual time of day prediction in fourth column. The vehicle registration is included for easy comparison with the live map.
In the video, the first 2:40 is quite slow, so skip that for the moment. All it’s showing is that a bus SN58CEJ is predicted to arrive at stop D at various times.
At 2:46v (I’m using the v suffix to distinguish elapsed video times from real times) the live map says the bus has left Brimsdown Station (stop D) and should arrive at Fouracres (stop E) in 2.5 minutes. That seems to be consistent with tfl’s Stoppoint/Arrivals prediction at 08:33:36 saying that the bus would arrive there 2 seconds later.
From 2:46v to 3:50v we see the bus moving logically towards stop E but watch it carefully: at 3:51v the bus apparently starts reversing back towards stop D where it supposedly recommences its journey to stop C.
The balloon at 04:11v again shows it heading for fouracres (E) in 2 minutes. The tfl data, meanwhile is now returning a new predicted arrival at stop D of 08:33:38 and this is apparently what caused the bus to “reverse back” to stop D. [Aside: my calculations were never intended to cope with unexpected negative values and -1:12 really means -0:48].
The bus continues its journey, almost reching fouracres, but at 06:00 we see on the right that tfl has revised its prediction for stop D and the bus is now “predicted” to arrive at stop D (not E) only 12 seconds ago.
At 06:43v the bus apparently passes fouracres though that may also not be true because at 06:54v the bus starts reversing, “passes” fouracres and the balloon at 07:04v implies that it has received new data confirming that the bus is still awaited at stop D (at 08:37:49 according to Stoppoint/Arrivals
The yoyoing continues several times until 08:58v when a second bus joins in 
These buses appear to be having a dance together, right up to 11:49v when the first bus finally disappears from stop D arrival predictions and goes on its way.
From then, the second bus continues yoyoing on its own.
The reality is of course that neither of these buses were moving for most of the time. Almost certainly both bus were stationary in the terminus about 200 yards south of stop D,
But it illustrates why arrival predictions cannot reliably be used to determine realtime positioning (and why tfl needs to improve the meaningless predictions presently being given for buses that have yet to reach the first stop).
Though I’ve concentrated on errors at the first stop, in practice similar problems can occur at any stop in an area of slow moving traffic. In such cases, a bus often disappears altogether from predictions without ever having passed the stop – leaving a passenger uncertain whether the bus has been terminated at a previous stop or merely delayed. Should they start walking, or wait longer? Presently it’s not possible to know reliably from the predictions.
Properly, there needs to be a Stoppoint/Actual endpoint which gives exact times of recent arrivals at the stop. This should include separate arrival and depature times, based on actual monitoring (such as the time the doors are opened and closed), preferably with additional flags such as “DriverChanged” or “InstructedToWait” to explain why a stop might be longer due to reasons other than passengers boarding.
Using that information, Matthew could give a more accurate map – but more usefully, having recent actual departure and arrival times rather than just predictions would allow the construction of a bus-specific delays map similar to that of mydrive.tomtom.com