Bus Live Data Map

Bus Live Data Map  

  By: richardc on Dec. 14, 2017, 5:37 p.m.

Ref bus 'live' data map [http://smartcambridge.org/transport/map/]

Good concept, and quite hypnotic. Would like to understand more about the bus routes, but at the moment this web page looks rather too fragile to use.

1) Buses often appear to be in duplicate, or even triplicate, traversing the same route and starting and stopping together.

2) The symbols do not represent 'live' data - I can see Milton Road from my house, and buses a) do not appear when they should according to the map, but b) others which are not on the map appear without warning;

3) Occasionally buses take off across parks and through blocks of houses at great speed.

Could you indicate reasons and an idea of magnitude of the problem, please?

For example, appears that para 1 above is because some buses have two transponders, and 2b is because other buses do not have any, but an indication of roughly how many would be helpful. Thanks.

Re: Bus Live Data Map  

  By: ijl20 on Jan. 22, 2018, 2:49 p.m.

Apologies for a spectacularly delayed reply. If you'd like a feeble excuse it's that we're deeply buried in significant enhancements to the bus side of the platform...

For others reading this we're talking about the live 'real-time' bus map here: live bus map

1) Duplicate buses: Well spotted. This is was true with the 'data feed' (GTFS) we were receiving from the bus companies previously. A relatively small number of the buses were behaving as if they were carrying two separate position transmitters, transmitting slightly different locations on separate time schedules. At a guess, this is probably what was happening, so 10 points for a correct answer. By coincidence since your post we've moved over to an alternative data feed that doesn't seem to have that issue, but let us know if you spot it again. The analysis necessary to sort the data and work out where an apparent two buses were really two transponders on the same bus isn't something we can get to now as we are really busy with other stuff. Most importantly the new data feed has additional information such as the timetabled journey the bus is supposed to be following that radically improves our options in showing buses in a more meaningful way (see below).

2) The symbols aren't live, some buses appear without warning: The previous feed of position data was on a periodic 30-second batch transfer to us, so the position data was nominally 0..30 seconds old randomly for each bus. In practice there's an additional ~5-8 second delay in the bus companies sending us the data so you can add that to the delay. The new feed (SIRI) is transmitted on a more immediate basis (i.e. eliminating the stock 0..30 second delay) but there's still the delay of ~5-8 seconds before it comes to us. FWIW the data processing on our servers delays less than 0.01 seconds even when transmitting the same data to the five servers we use to process the data. Of course we are in dialogue with the data providers to ask they send the data when they get it without delay, and we're helping them improve their techniques. A bus appearing 'without warning' presumably means it's not sending it's position information. Not much we can do to detect that from our platform but gradually this will improve in part because of our work and the fact we're chivvying the industry to try a bit harder.

3) Buses take off across parks: We essentially move the bus in a straight line from point-to-point as we receive the position data, and sometimes this represents a jump as you've seen. In the prior version of the page (I think that you're referring to) we smoothly animated the bus over 30 seconds from point-to-point and with hindsight this introduced additional delay (due to the 30-second time of the animation) and made the 'park jumps' look worse. In the current version (see link above) we still move the bus point-to-point but do it in one second rather than thirty. Note at this stage the system itself has no idea of the map or the route the bus is supposed to be following, but see below.

We are working on a fundamental set of improvements in the use of the bus real-time data that have been enabled by the improved content of the 'SIRI' feed. The time/position data for the bus is pretty much unchanged, but now we can work out the timetabled journey each individual bus is on (i.e. it departed a particular stop at the start of its journey at a particular time). We have (already working) in development a high-speed 'timetable' server that given this "origin stop/time" can return the entire sequence of stops/times relevant for that particular bus (and can currently do this in 0.01 seconds). We are also working on advanced real-time analysis software that can accurately predict where on a bus journey a particular bus is, given its position and timetabled route (this is hardest part of what we're doing). This is a mix of Cambridge University research (where I work) combined with a genuine commitment to make information available to local travellers as that becomes possible.

 Last edited by: ijl20 on Jan. 22, 2018, 2:52 p.m., edited 1 time in total.

Re: Bus Live Data Map  

  By: richardc on Feb. 19, 2018, 10:35 a.m.

Thanks for explanation and for updates to displays. Icon is great – displaying the service number is what we need. I have done some sporadic monitoring over the last few weeks. Occasional pairs, but they seem genuine and ultimately split, so everything looks believable. You have also got rid of a couple of issues which were annoying – the screen tended to freeze after about a minute, and was also restoring to default zoom level with every update. Good to see they have been dealt with.

In terms of update rate, a modest delay is not a problem for those waiting at the stop. The critical part is that the system is believable until the bus comes into view. If your display has a lag of a few seconds, those at the stop will be pleasantly surprised when the bus arrives ‘early’.

However, the delay does seem a bit variable. General observation – nothing scientific – says it may be dependent upon the age of the vehicle. For older vehicles the delay may be up to about 25 seconds, but with modern buses, the delay is about 5-8 seconds. May only be indirectly related to the age of the vehicle – could be the sequence in which they are polled. If older equipment is polled first, with later vehicles (like the new PR fleet) being allocated a later position in the sequence, that would mean the PR fleet send information to the host a few seconds before the host updates you.

My only adverse comment would be that previously the movement was relatively smooth – albeit across the rooftops. Now the icons move forward and stop, apparently waiting for the next update. If you could get the industry to give you the information every 10 seconds, interpolation could be carried out in the following 10 seconds to produce a smoother display with maximum lag of 20 seconds.

Overall a huge improvement. Notice recent traffic on Twitter that apps are being compared favourably with the ‘real-time’ displays at the stops. I fail to understand how they can be so unreliable.

Re: Bus Live Data Map  

  By: jw35 on Feb. 23, 2018, 9:30 a.m.

I'm glad you like the improvements. The map is very much a 'work in prgress' both for showing the best we can currently achieve and for tryling different representations.

We are just consumers of the real-time data, we don't have any control over it and we have no particular insights into how it is created. Our analysis of the data we are recieveing shows that the frequency of reports by busses is predominantly every 20 seconds (95% of reports are within 21 sec of a previous report, 96% within 30 sec, 99% within 60 sec, and 99.9% within 240 seconds. The maximum observed delta is about 2.5 hours, but in all investigated cases deltas of over an hour are caused by otherwise bogus data.

What we don't currently have a good feel for is what reports we might be missing.

The distribution shows additional small peaks at 40, 60, 80, 100 sec, etc. presumably caused by failed or lost transmission. There are also peaks at 10 and 30 sec. (but not at 50 or above) suggesting some initial transitions on 10 second intervals. I would agree with your theory that perhaps some more modern vehicles may transmit more frequently. They could also reflect different monitoring equipment, perhaps in Stagecoach and Whippet busses.

We are currently going with the "move quickly to the last reported position" since we think it gives a better view of what we actually know. Future planned work on prediction will alow us to better show current predicted position. I'd argue that while a modest delay is not a problem for those waiting at the stop, it is a problem for anyone hurrying to a stop if the result is that they see the bus they wanted dissapearing into the distance - busses can cover quite a distance in 20 sec!


Jon Warbrick
Adaptive Cities Programme, University of Cambridge