Offline routing crashes ungracefully in dense urban areas

[polarbearing]

OsmAnd: current nightlies, however the behaviour is the same for ages. Nexus S, Android 4.1.2 unmodified/not rooted Not using any custom routing.xml yet

While the FAQ says OsmAnd has limitations in calculating routes >250km, it seems to me it is more related to urban road density. While I have little problem calculating such route in a rural area or along a long motorway, it fails regularly for "just" driving across Berlin.

A route fully across Berlin, that is shown by air with 30-35 km, never succeeds. It calculates for several minutes and crashes the app. If I restart and drive on, it still crashes with air distances of 20 or 15 km, below that there is a chance that the remaining route is calculated, eventually. Less than 10km mostly succeeds. The blue progress bar goes quickly towards the end, stays there until the crash comes after 2-5 min. While calculating, the rest of the app remains functional, such as rendering, displaying position and speed; GPX is recorded, however the current street name is mostly missing.

It all depends on different on different parameters: if the route goes through the centre or more peripheral, if the phone is freshly booted or not, and if I killed some unrelated background-squatting apps with the process monitor before starting OsmAnd.

In contrast to other crashes (such as recently in re-calculation getting "android.speech.tts service not registered" written to exceptions.log), the app does not write anything to the log, and crashes without restarting itself.

It is known that the calculation is memory-intense, however I wonder if the remaining memory could be better monitored so it does fail gracefully instead of crashing..

I would find it also helpful to produce some debug information, both on screen and written into a separate log file, with details such as air distance, which routing phase we are in, how complex the road layout is being found, and how much memory is consumed in each step. The progress bar could indicate the routing phase, by changing colour or going backwards for phase 2.

[polarbearing]

Loaded custom routing.xml and uncommented the heuristicCoefficient=1.5 in the car profile. Route (36 km air) was calculated in less than a minute. Route looks sane.

[vshcherb]

Yes it mostly depends on how many road segments the algorithm need to check. Though I've tested the Berlin area and couldn't reproduce, please specify example coordinates

[polarbearing]

(nb 28-Jul-2016 10:30 build 177707) Killing killable apps, OS monitor reporting mem total 359.9, free 115MB before starting osmand.

built-in routing.xml:

Routing car from here 52.47273,13.69822 to 52.54485,13.17483 start routing 11:52, progress bar filled 11:53, crash 11:54. os monitor now reporting 155MB free, so apparently osmand squeezes some stuff out. 11:57 trying again, 11:58 progress bar filled, crash 12:01.

custom routing.xml heuristicCoefficient=1.5 as the only modification: start routing 12:05, route calculated in 25 sec, route is sane.

[polarbearing]

heuristicCoefficient=1.5, calculating route 427km road distance, Berlin boundary to Bavaria, avoing Berlin on A10 ring motoway, in 15 sec. Changing start point to Berlin city, 20km towards A100/A114, calculated in 8 sec

[Boothy99]

Polarbear, is there any chance you could run a test with a June version of your map? (unfortunately I don't have your map for June, as I had for GB England.) As you noted above, I'd be interested to see if it relates to the July releases of maps, as the OsmAnd version seems to have no bearing on this recent crashing problem ( see https://groups.google.com/forum/m/#!topic/osmand/QCsaE48ITRU ) Dave.

[vshcherb]

GB England is another issue cause it is reproducible even on high end devices. This issue was tested on OnePlus2 and it doesn't seem to be dramatic on this device.

[polarbearing]

@Boothy99 - while I don't have the June map file anymore, my issue was persistent over a long time, so my observations in June were the same as in May or July.

[Boothy99]

@polarbearing - ok ...a different issue then. Cheers.