[OSM-dev] GSoC - Travel Time Analysis (classification aproach of Speedcollector)

Marcus Wolschon marcus.wolschon at googlemail.com
Fri Mar 26 05:49:39 GMT 2010


On Thu, Mar 25, 2010 at 2:28 PM, Nic Roets <nroets at gmail.com> wrote:
> Rerouting traffic based on collected track logs is essentially an
> extension to this: Take the tracklog, divide it into 2 minute
> intervals (or T seconds).

I suggest to use the ways and segments between pairs of nodes
on ways instead of and time base.
But of cause any such design deccisions are not up to us but the
students who´s project this wil become. It´s their project. We merely
offer a problem and advising suggestions.

> Try to filter out the cases where the
> vehicle was parked or the user was walking around. Ask the router how
> long it should take to travel from the starting point to the end
> point. If it's substantially less than T, mark the point (segment) as
> a penalty point (avoid point)

What point?
You where talking about start to end a second ago.

> with an appropriate weighting.

There is no apropriate weighting as that algorithm
does not know IF the delay even happened in that one, random point.
You are calculating the delay for a complete route
and then suddenly assuming it´s all in single point/segment.

> Serve
> these penalty points to clients and routing servers. Then adjust the
> penalty points according to time of day patterns etc.

And in what way do your random "penalty-points" relate to the
completely different route of the client?

a)
If there is a delay n one direction, there need not be such
a delay in both directions.
b)
That one car had a delay does not mean that one second later
others have a similar delay. You don´t even attempt to describe
merging the delays meassured by multiple vehicles on the same
segment.
c)
Your aproach is highly dependent on the metric on one particular
routing engine with one set of speed parameters. You are penalising
a sportscar in the midle of the night becasue a heavy truck at rush
hour was slow 3 month earlier.
d)
Tracks are about past events. You cannot blindly compare travel
times of different vehicle-classes (heavy truck, light sports car, motorbike,
bicycle, slow city-hopper), drivers with completely different
intensions (driving fast, efficient, mapping sideroads) and at different
classes of days (weekend? start/end of local holidays?) and times (rush hour,
night, evening, morning).

My aproach:

I proposed to collect the tracks in navigation-software in my attempts
(http://sourceforge.net/apps/mediawiki/travelingsales/index.php?title=Speedcollector)
to solve this issue one or two years back becasue there we know
the car and chosen metric as well as the time and day. Then classify
times and days into some broad classes and subclasses and a heuristic
for combining different meassurements taken with different meta-info
with a weighting dependent on how much they aligh with the meta info
that is being asked for.

If a service to collect such tracks with all these meta-information was
provided, I´d be happy to add the functionality of posting tracks there
to Traveling Salesman (provided the user allows it).
http://sourceforge.net/apps/mediawiki/travelingsales/index.php?title=Plugin/FeedbackFastestRouteMetric

Marcus




More information about the dev mailing list