[OSM-dev] GSoC - Travel Time Analysis (classification aproach of Speedcollector)
Nic Roets
nroets at gmail.com
Fri Mar 26 07:29:59 GMT 2010
On Fri, Mar 26, 2010 at 7:49 AM, Marcus Wolschon
<marcus.wolschon at googlemail.com> wrote:
> 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.
>
The points and segments that the router returned. A simple algorithm
to choose a representative point or segment somewhere in the middle
can be devised.
>> 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
No. I said break it up into short (2 minute) sections. If the penalty
isn't attached to exactly the right node, there is still a reasonable
chance that it will cause the router to avoid roads that may soon
become blocked up.
> 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.
...
My router represents all segments as two directional edges. But a good
system will attach some probability to an event that cause delays in
both directions, such as road maintenance or a car crash that cause
motorists traveling in both directions to slow down to take a peek.
I'm not saying it's easy. A lot of trail and error adjustments will be needed.
The main point is that the router already does a lot of the work.
More information about the dev
mailing list