Op wo 28 nov. 2018 om 18:11 schreef Greg Troxel <[email protected]>: > > You are talking about 1.0 for ideal, and as I see the world there is no > ideal way, just ways with different speeds. So is there some assumed > max speed that the 1.0 or 1.4 rating is realtive to? As in 1.0 would > correspond to a straight motorway from the in-process route point to the > destination? > > I wonder, if the developers are unwilling to change the heuristic by > default, if the UI could simply have a value for it in an advanced menu. > An alternative would be to bump it up automatically when route > calculation takes too long, and remember heuristic by distance bin. > > Now this will become a long answer :)
There is actually more than both Poutnik's and my explanation when it comes to "max speed" on roads. Note that below does not really relate to the heuristic coefficient, but an "extra" that OsmAnd uses in its calculations. And that is the "penalty" options that OsmAnd uses. Only very, very, very few other nav apps do that and actually: I did not find a single one yet.. OsmAnd uses penalties for "speed bumps", traffic lights, pedestrian crossings, go right/left on intersections has higher penalty than going straight over the intersection, etc. etc. On long travels over motorways, that really has no effect of course (like Poutnik explained). In cities on the other hand, the OsmAnd calculations are almost always better than of other nav apps even though it might seem it takes a longer route. This is because it uses the penalties, like in a 70 km street with 4 traffic lights versus a 50 km parallel street without traffic lights. OsmAnd will calculate the best route. Other nav apps will simply take the "faster" 70 km road. This also leads to better ETAs. I drive relatively often in Den Haag (The Hague), sometimes using 3 nav apps at the same time (that was some years ago when I really did some extensive testing). Sometimes the route was (almost) identical and the others would mention something like 15 minutes where OsmAnd mentioned for the almost equal route for example 25 minutes. No matter whether I took the route of OsmAnd, where the others recalculated for the route, or whether I took the route of another app, where OsmAnd needed to recalculate: In really 95% of the occasions the ETA calculated y OsmAnd was far more precise (be it longer). Mapfactor Navigator uses a simply different approach to calculate a route as fast as possible. They deviate from the A* algorithm by trying to get on a big road as soon as possible (leaving the city), and stay on that big road as long as possible (entering the city as destiny). This skips a lot of "unnecessary" and "unrealistic" paths which makes the calculations extremely fast. Creating a complex route inside a city, takes hardly any shorter than creating a route from the North of Norway to the south of Spain (>4000 km), as the long route in between is actually the most simple one. And then we also have the OSRM routing algorithm (Open Source Routing Machine): http://project-osrm.org/ OsmAnd can use this as online routing algorithm. Currently the routing.xml is read at startup of the application. Making it a user selectable option might require to restart the app, but I think it would be feasible. Harry -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
