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.
Description: PGP signature