View Single Post
  #14   Report Post  
Old May 14th 05, 03:13 PM posted to uk.transport.london
Dave Arquati Dave Arquati is offline
external usenet poster
 
First recorded activity at LondonBanter: Jul 2003
Posts: 1,158
Default LBC Satellite Data

Tom Anderson wrote:
On Thu, 12 May 2005, Dave Arquati wrote:


Stuart wrote:

Vernon wrote:


When LBC Travel News talk of travel information derived from
"Satellite Data", what sort of satellite help are they getting? I am
aware of GPS for navigation, but I can't see how that could help with
determining the levels of realtime traffic problems.

Just curious, but does anyone here know?

Years ago they used to have 'real time travel data' which was linked
to the Trafficmaster system. This monitored the speed of individual
cars from point A to point B (while making the actual registration
number anonomous) to give a journey time.


Don't TfL do this with the congestion charge cameras too, i.e. measure
the journey times of individual cars between two cameras to get traffic
information for particular links?

I always thought that these traffic-monitoring systems should be
integrated somewhat with the London Buses data. At the moment, the
London Buses realtime information is not particularly realtime, and
generally only talks about roadworks, scheduled diversions and scheduled
disruptive events like demonstrations. I'd like to know how congested a
given link is, so I can plan my bus journey to avoid it, or use the Tube
instead.

A very impressive system would be to not only have accurate Countdown
information online and at stops, but also to have dynamically-estimated
journey times to destinations from that stop, available both online and
via Countdown at the stop itself. Integrate this into Journey Planner
for those looking for journeys departing "now", and you get an extremely
accurate guide as to the quickest way to your destination.



This is what we call a 'pipe dream' .


Aw, you're ruining my fun.

Yes, this would be very cool, but
the amount of effort it would require to gather the traffic data, process
it to produce congestion forecasts (not entirely unlike weather
forecasting - congestion is a dynamic, nonlinear, mobile phenomenon), work
out delays to services and distribute this to every bus-stop would be
substantial.


I don't (think I) mean forecasting congestion, as such... just using
data on current traffic speeds to estimate those journey times. The data
collectors are already out there in the form of on-bus AVL, C-charge
cameras, TfL traffic cameras, RAC info etc.

For example, if traffic is crawling eastbound on Kensington Road, then
the system will flag it up as "slower than usual" and send that
information to London Buses, who can then identify which routes are
affected (9, 10 and 52 eastbound).

The current estimated journey time through the congested link can be
compared to the timetabled journey time, and any significant difference
can then be relayed to relevant terminals (the website, WAPsite, all
eastbound 9, 10 and 52 buses which haven't yet reached Kensington Road,
and Countdown displays at all 9, 10 and 52 stops west of Kensington
Road). That information just needs to be a fixed time increase for an
individual link, and only needs to be sent out when the time increase is
significant (say over 50%).

So, if journey times along Kensington Road (which exists as a defined
link in the database, say between Queens Gate and Scotch House) are
timetabled for 8 minutes, and are taking an estimated 13 minutes instead
(based on traffic speeds), then a "Kensington Road: +5" flag gets sent
out to the relevant stops and buses.

If you are waiting at Kensington High Street, you will see Countdown
scrolling journey times to key destinations across the bottom of the
screen ("Knightsbridge X+5 mins, Picc Circus X+5 mins, Paddington X
mins") as appropriate. Alternatively it may be easier to understand if
it just shows "Routes 9, 10, 52: 5 mins delay past Knightsbridge".

Integrating into the online planner would also, i imagine, be very
difficult - it's the sort of thing that sounds easy, but is often
fiendishly difficult in practice, since the planner software will be built
around the assumption of a static database, rather than one which changes
every minute.


That's true, but Journey Planner already integrates the existing
real-time info into journey suggestions. Let's say this journey time
info is in a database where each link has a field with a delay property
which is either 0 or a delay in minutes.

I'm not sure how the JP works, but presumably when it returns a route,
it is composed of a series of links already. So when you look up
Kensington High St to Trafalgar Square bus bus, you get the appropriate
links between those places returned. All JP has to do is look up the
delay for each link.

How would countdown display the delay information? There are dozens of
destinations for each bus; would it go through all of them? Key stops?
Stops affected by delays?


That's an area for customer research attention :-) The limitation is
really the size of the display. Countdown isn't that big, so you might
have to devote just the bottom line to reporting delays to specific
routes as I suggested above.

If a larger screen were available, e.g. an LCD at a bus station, then
that could display estimated journey times to all key destinations.

Online or by WAP, you could enter your current stop (or get it filled in
automatically if you have a 3G phone, I think) and destination, and get
a personal estimated journey time.

Anyway, having said all that, this is a good idea, and i'd imagine bits of
it will be implemented in the future.


I hope so! I really hope they introduce "next stop" information inside
buses ASAP, because I think that's the single most important improvement
to be made.

The other stuff would be pretty cool though :-)

--
Dave Arquati
Imperial College, SW7
www.alwaystouchout.com - Transport projects in London