Not trying to hijack this thread, but Harry, where exactly in routing.xml do you change the heuristicCoefficient value? I see 2 possible places:
At the beginning, there's this section, with the value unset: <osmand_routing_config defaultProfile="car"> <!-- 1. parameters of routing and different tweaks Influence on A* : --> <!-- f(x) + heuristicCoefficient*g(X) --> <!-- TEMPORARY needs to be reverted to 1 --> <attribute name="heuristicCoefficient" value="" /> Then just a little below that is this section, with a value of 1.5 commented out: <routingProfile name="car" baseProfile="car" restrictionsAware="true" minDefaultSpeed="45.0" maxDefaultSpeed="130.0" leftTurn="5" rightTurn="5" roundaboutTurn="5" onewayAware="true"> <!-- <attribute name="heuristicCoefficient" value="1.5" /> --> Are you supplying a value for the 1st, or uncommenting and using the 2nd? --jack On Sunday, October 2, 2016 at 11:12:02 AM UTC-4, Harry van der Wolf wrote: > > THOR might be a good alternative, but the A* algorithm OsmAnd uses is just > fine. > I agree that OSRM is too limited due to its inflexibility. > > It is the implementation of the A* algorithm in OsmAnd that is wrong (from > my point of view). OsmAnd is literally the only app that uses a heuristic > coefficient of 1.0 thereby increasing both memory usage and calculation > time extremely. And it sometimes even calculates the wrong route (due to > over-optimization?). > > I use a heuristic coefficient of 1.25 or 1.3 which makes the calculation > 3-4x as fast!! and I can calculate routes up to 2000 km (less memory > usage) where I could calculate up to 800 km (1.5GB memory in my phone) . > And routes were never worse and in some cases even better: faster and > shorter! > With that configured the route calculation is still not the fastest but > completely acceptable. > > There is only one disadvantage: deviating from the default 1.0 in OsmAnd > makes that blocked roads (by users themselves for whatever reason) are no > longer recognised. I assume that is an omission in OsmAnd. I can't consider > it a bug as Victor developed OsmAnd for that hc=1.0 (but I still I think it > is a bug :) as other A* algorithms apps have no problem with that). > > > Next to that: OsmAnd knows speed penalties for traffic lights, speed bumps > and the like. It seems that THOR supports that too (dynamic run-time > costing) but is not yet implemented, but maybe I'm wrong. > > The other reason for me for not using OsmAnd for car navigation is the > slow rendering of the screen. > > 2016-10-02 12:11 GMT+02:00 'Norbert' via Osmand <[email protected] > <javascript:>>: > >> OsmAnd needs a new routing engine because of bad performance. Graphhopper >> and OSRM do not fulfill the requirements because they don't support >> conditional edge-weights at query-time*. THis is necessary to support >> options like avoid highways and so on without the need for a separate >> CH-graph for each combination of options. >> >> Competitor maps.me suffers from a similar problem**. The use fast OSRM >> engine but can't offer routing options (avoid highways etc.). >> >> It should be investigated if THOR*** engine (Tiled Hierarchical Open >> Routing) which supports* multi-modal routing *can be implemented in >> OsmAnd to replace the current routing engine. >> >> >> >> * https://github.com/Project-OSRM/osrm-backend/issues/2377 >> ** https://github.com/mapsme/omim/issues/1888 >> *** https://github.com/valhalla/thor >> *** https://mapzen.com/blog/valhalla-intro/ >> >> -- >> 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] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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.
