Slow route (re) calculation

[bitboy85]

On long distances the route calculation is slow. This wouldn't be a problem but if a road is closed it seems to take the same amount of time to recalculate the route. In my case this was about 10 minutes. Maybe you miss the next possible route because of this.

Maybe both issues can be fixed if you assume that you usually use motorways on long distances so keeping the route after the motorway link and just recalculate the route to the link. On first calculation it might be possible to start navigation after finding a route to the next motorway link. the rest of the route could be calculated in background.

[bitboy85]

And i can't install a newer one because of the android version

[bumbaras]

I am not sure why this matter is still discussed. I reported similar issue few years ago and only solution was to stop using this app. Because offline calculation is too much for average smartphone. Not sure how to interpret this because i was using some mio navigation device which calculation power were no more than 1/10 of my smartphone so i just stopped using osmand plus and went to google maps. The most annoying thing in this long time calculation was long time calculation after changed road. Such thing is just useless for ordinary driver. And now i am reading that the time is even longer than it was before ...

[bitboy85]

Any chance to get the current version backported to android 5? I tried maps.me and it calculates a route within 2 minutes but it is lacking other features...

[bumbaras]

Any chance to get the current version backported to android 5? I tried maps.me and it calculates a route within 2 minutes but it is lacking other features...

Huh? You want the maps.me be ported to old android? Is this somehow related to Osmand app? Android 5 is currently like Windows XP in modern times. Wouldn't expect anyone be interested to play with it. Beside 2 minutes suggests maps.me can be using online calculation.

[bitboy85]

no, question is if the osmand version (current version?) with fast route calc can be backported to android 5. I have one of those chinese car head units with no upgrade to android 6. And throwing away a working device is not what i want to do.

PS: maps.me still supports android 5 and has fast route calculation. but is missing other features i like...

[bumbaras]

I doubt. Not supporting given and older version of android is a mostly result of upgrading code to modern libraries. Maintaining two different lines of software is not what normally developer want to do - it can and will create additional issues. And after read the whole thread i don't see any notice that osmand fixed or improved their calculation algorithm or maybe i am just blind. By fast route calculation You meant online algorithm? Or Osmand really improved and is worth further testing?

[bitboy85]

As @vshcherb said:

Bitburg - Dortmund on my device (4.2 OsmAnd Android 11) takes 10-15 seconds and 230 km route.

sounds like it is working in newer versions. Maybe increasing the memory helps.

[H-Sachse]

I thought about a solution for reducing the number of roads for the routing algorithm to take into account, and I think the following may work: If the routing algorithm is further away than say 50 km from the starting point and the destination and any intermediate destinations, ignore roads of lower levels. Meaning only use Autobahn/Bundesstraße/Staatsstraße for Germany, Interstate/Highway/State Roads for USA and so on. This would cut out all the little roads in between. They would not lead to a usable route anyway. The cutoff distance could be a tunable parameter, maybe even part of the map data, depending on how dense the higher level road network is.

I also think this would not be too hard to implement into the current algorithm. It would "just" have to check the distance to the start and destination(s), check the road type and drop this path if the road type is too low.

I just tried to calculate a Route from Füssen to Hamburg in Germany with Osmand+ (F-Droid) 4.2.6 and it couldn't do it, stating it didn't find a solution, although there's the A7 going from Füssen to Hamburg.

[scaidermern]

Not sure if ignoring these minor roads completely is a good idea since they could be necessary in some edge cases. There could be a solution somewhere in between, for example by significantly raising the priority of major roads during route calculation. This should be possible with a simple A* algorithm, shouldn't it?

Anyways, other apps manage to calculate long offline routes without such problems (see for example brouter). Also, other simple low end devices have been able to calculate such long routes for decades. They have had significantly slower chips and way less memory than modern smartphones. Of course map data was more sparse these days but computational power increased significantly. So it can't be impossible to finally "fix" this major(!) downside of OsmAnd.

I think a performance analysis of the routing engine would be a good idea to identify bottlenecks. Is it raw CPU power the limiting factor? Or is it storage throughput? Or memory usage? Is it possible to improve route calculation by splitting maps into road-only data and POI/landuse/building data?

[H-Sachse]

Interesting observation: uNav + OSM scout server on Ubuntu Touch on a Lenovo TB-X605L can calculate a route clear across germany (from near lake constance to Hamburg) in about 10 seconds, where OSMamd takes forever if it can calculate a route at all on my FP3. To make sure everything is done offline I actually switched off network connectivity. Both devices have similar HW specs. Might be good to check out what the scout server does for routing to see why it is so much faster.

[mwerle]

Just to add my 2c; I've now several times gotten completely lost in Tokyo after taking a wrong turn on one of the inner-city highways because OsmAnd failed to calculate -at all- the final 10km to my destination. In both cases I eventually had to turn off the highway (there are no verges) in order to be able pull over and get it to recalculate, which costs a lot of money (the highways are all toll-roads, and you pay every time you leave and re-enter).

I have no idea what OsmAnd is trying to do under the hood, but it appears to have been trying to recalculate the entire route from my original starting point (a few hundred km away) to my destination (<10km away), instead of from my current position. Or it starts recalculating every time my position changes (obviously it's impossible for me to stop).

After pulling over, cancelling the current route (it still fails to recalculate after stopping), and calculating a new route to my destination it only takes a few seconds, so it's not an intrinsic issue with the routing in this area, just the way in which recalculation is working.

FWIW, I'm on a motorbike, so fiddling with the routing and/or asking a passenger to do it for me while driving is not an option.

Conversely my ancient Garmin Zumo 660 has no problems recalculating routes in a "sane" amount of time and I used it for routes covering 1000+km in Europe..

Perhaps a way to improve matters is for routes to have virtual waypoints (every X kilometers, or at major intersections, etc); if a user leaves a route, only a sub-route from the current location to the next waypoint needs to be calculated to get back on the original route. This would not require recalculating everything.

[sonora]

Perhaps worth opening a new issue about this, and also state app version and map version fir reproducability.

I personally recently had sporadically the following, using v4.6.5: I was using car routing, but just displaying the route, i.e. not in turn-by-turn modus. On some occasions I noticed that the route line now extenden not only in front of me, but my position was somehow displayed "in the middle" of the route line. Apparently, at some point OsmAnd had failed to recognize that I had progressed along the route,and still displayed the route starting from some point behind me (actually some turn, if I remember correctly).

I had left that situation for a while, but it did not resolve itself, so eventually that 'stuck' starting point would have been far behind me (though not the original starting point of the route). Canceling the route and re-starting it resolved the situation in seconds. It is hard to reproduce, but happened to me 2-3 times in a week of extensive driving.

[vshcherb]

We have already new routing for car & bicycle (Development settings -> Special routing) it's early stage alpha and still not in C++ (Java) but it's promisingly fast and fast recalculations

[naoliv]

We have already new routing for car & bicycle (Development settings -> Special routing) it's early stage alpha and still not in C++ (Java) but it's promisingly fast and fast recalculations

Is this the HH route planner? (#18378)

[vshcherb]

yes