There are I think two separable parts to this: map bugs and optimal
routing.

One is fixing outright bugs in the map where the map data indicates you
can do something (like a left turn) when you can't.  For that, a
relatively easy feature might be a button to push on the screen that
will create an OSM note (bug report) at the location of the next turn
that says "[type of turn osmand wanted to use] not possible/legal".
People could then push this when they get directions they can't follow.
Also, there could be a stop sign and a traffic signal button, to upload
notes (or actually edit) that people could push while stopped.

The other is much harder, and i think it has two sub-parts.

The first is that the essence of routing should be to calculate a
distance or time for a route that accurately represents what happens.
So there's a cost of traffic lights, assumed speeds, and assumed time
for various turns.  Note that I avoid the word "penalty" because the
point here is to accurately predict what will happen.  Here, OSMand
could save a route record that has the route plan in terms of distance
and time and then the actual distance/time encountered.   That could be
used to fix the map if the speeds are wrong, after we add a
"maxspeed:typical" tag to separate what usually happens from the limits,
whether above or below.  And it could be used to adjust osmand's
estimates of how long it takes to make turns and stop at traffic lights.

The second sub-part is that choosing an optimal route is conceptually
difficult.  People say "shortest distance" or "faster time", but people
hardly ever actually mean that.  Driving 10 miles extra to save 30s is
almost always not actually preferred, as is saving 0.1 miles at the cost
of 5 minutes.  And, certain things are unpleasant, separately from time
or distance, because they are more dangerous or more stressful.  To
address this, I would suggest augmenting "shortest distance" and "faster
time" with a blended metric that is some combination.

Basically, have k between 0 and 1, and minimize

   t*(1-k) * 50 km/hr + d*k

When k is 0, this is fastest time.  When k is 1, it is shortest
distance.   When k is 0.5, driving 1 mile extra and 2 minutes extra are
equally preferred.   I suspect that using 0.1 and 0.9 for
fastest/shortest is likely useful, but I don't really know.

Beyond this, we could allow the user to assign time penalties for things
that they don't want to do, as we identify them.  Once again, I do not
mean times that account for how long things take; those are not
"penalties" but are the actual estimate of what will happen.  I mean
things like wanting to avoid turning left at intersections where it
feels stressful, and that for example I might feel that driving for 2
minutes extra is preferable to making such a left turn, so I would
prefer a 19m50s route that avoids the turn to an 18m route that has it.

I suspect the suboptimal bike routes are some combination of all 3 of
these issues: wrong map data, not accurately estimating times, and
not taking preferences beyond time/distance into account.   This is
certainly all quite difficult.

-- 
You received this message because you are subscribed to the Google Groups 
"Osmand" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osmand+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Attachment: signature.asc
Description: PGP signature

Reply via email to