Increase timeout for long calculations

[theraser]

At the moment there is a timeout of 60 seconds while calculating a route using the service-interface. Using a little more complex routing profile and/or little "longer" distances this timeout hits me on a lot of routes. Of course you can split up the route into smaller parts - but how do you know where you should split it / which position will be on your "perfect" route? :-)

I understand that it is not very comfortable to wait a longer time but in my opinion simple waiting is more user-friendly than waiting for the timeout, then switching from OSMand to Brouter app, do the recalculation there and switch back to OSMand. The classic mode isn't supported anymore using a common App Store installation so this limitation primarily hits the "common" user ;-)

Are there any technical reasons for limiting calculations in the background to 60s which I missed? I would like to suggest increasing it to at least 300 seconds, which should be at least okay for day trips using a bicycle.

[EssBee59]

Hello Theraser,

Was is for you a day trip on bicycle? The Brouter is very very fast, a 200 km bike-tour is calculed in nearly 10 seconds!!!! (measured on the brouter-web "brouter.de" and a smartphone with a processor qualcomm/snapdragon 855)

I am able to plan bike-routes longer as 700 km on the brouter-web.

I would not recommend to "recalculate" such a tour dynamically on the bike with the brouter-app.

Compared with the Osmand own routing, the performances are fantastic... Are you sure, you are using the brouter-app properly?

regards

[theraser]

Thanks for your input!

Brouter itself is working fine, the generated routes are as good as expected. It just takes quite long in some areas. I'm mainly using this profile.

Using a Snapdragon 632 this 300 km example route won't get calculated due to the timeout, using brouter-web it takes ~51 seconds. I would not care if it takes a few minutes to calculate on my smartphone, but after 60 seconds you have to switch from Osmand to Brouter app, do the (re-)calculation in foreground mode and then switch back to Osmand. This is quite annoying/uncomfortable.

While testing around now I noticed that other profiles work a lot faster (Trekking bike, original = 16 seconds with brouter-web). Maybe this is just a profile problem which would make this issue hopefully obsolete. I'm not sure how to debug this at the moment, but this already is a nice hint!

[poutnikl]

Hmm, and is it Brouter time out or OsmAnd time out ? AFAIK, LocusMap had its time out issue as well, until it prolonged it's waiting. And I guess now, when it get Brouter integrated into its version 4, it would not be an issue at all.

[abrensch]

There's also a feature called "timeout-free recalculations":

when a request timed out, start the BRouter-App, and you should see a "" option in the waypoint-selection. When you choose that, and wait for the result, the next try in OsmAnd should be fast (because it's re-using the existing result)

[EssBee59]

Yes, your profile is a bit slow (twice longer as trekking or fastbike).. It is very complex, but by simply setting a fix "turncost" you can save a lot of processing time!

[theraser]

Hmm, and is it Brouter time out or OsmAnd time out ?

I think that it is Brouter because OsmAnd internal routing takes a lot longer without problems and I found this in the Brouter readme.txt:

Note that if called via the service-interface, BRouter uses a timeout of 60 seconds, which sets a limit on the distances you can calculate.

This is how it looks (translated: "Route could not be calculated"):

There's also a feature called "timeout-free recalculations":

when a request timed out, start the BRouter-App, and you should see a "" option in the waypoint-selection. When you choose that, and wait for the result, the next try in OsmAnd should be fast (because it's re-using the existing result)

Yes, this works as expected most of the time. But it is quite uncomfortable because you may have to stop your ride, trigger a recalculation in OsmAnd, wait for the timeout, switch to Brouter app, trigger a manual recalculation there, wait for it to finish in foreground and then switch back to OsmAnd to continue/start your ride...I would not care if it takes a while to calculate in the background when I don't have to do something by hand anymore :slightly_smiling_face: That way you could start riding without having to wait for the manual work to be finished.

Yes, your profile is a bit slow (twice longer as trekking or fastbike).. It is very complex, but by simply setting a fix "turncost" you can save a lot of processing time!

Thanks! The turncost calculation is not fixed on purpose since there should be a preference for roundabouts / cycle routes :slightly_smiling_face: Or do you mean something else?

[vodie]

I think that it is Brouter because OsmAnd internal routing takes a lot longer without problems and I found this in the Brouter readme.txt:

This is the default timeout, if the calling app like osmand doesn't set a timeout.

But it is quite uncomfortable because you may have to stop your ride, trigger a recalculation in OsmAnd, wait for the timeout, switch to Brouter app, trigger a manual recalculation there, wait for it to finish in foreground and then switch back to OsmAnd to continue/start your ride...

On the ride I see two situations where you need a recalculation and they both should work without running into the timeout. If you miss a turn or something like that, Osmand detects your detour and sends a new request to BRouter. BRouter will recalculate the near end give a new route before the timeout. The other situation is where your road is blocked (construction etc.). In this situation you can set "avoid road" (Strasse vermeiden) in Osmand on the blocked spot and Osmand will send a new request to BRouter. BRouter will again recalculate the near end give a new route before the timeout.

If you know that you will run into the timeout you can abort the calculation in Osmand immediately and don't wait for the timeout. The recalculation entry in BRouter will be active even if there was no timeout message.

[poutnikl]

Originally, AFAIK, Brouter did not use timeouts ( I could calculate very long routes up to 30 minutes, limited by phone resources and crashes, not by time. I use LocusMap and all timeouts were originally caused by LocusMap ( 1 min ), until time-out interval was prolonged .

Later Brouter implemented API timeout and expired routing can be resumed in timeout-less routing mode as Arndt described above. I use it rarely, preferring using shaping points/viapoints of LocusMap route planner, so all route segments are calculated quickly.

[quaelnix]

@afischerdev, is this still a thing?

[theraser]

At least for me it is. Just tested it again using the latest brouter version.

[afischerdev]

The rules are still the same: the timeout is 60 seconds and a client can top this by using this parameter 'maxRunningTime'. E.g. Locus added maxRunningTime=600

[quaelnix]

and a client can top this by using this parameter 'maxRunningTime'.

So the main problem is that you can not change this parameter in OsmAND?

[afischerdev]

May be not in total. When searching for long routes you will get big export files. This could break the size of the Android service interface (I don't know, may be around 500KB, seams a little dynamic for me). So an app should use acceptCompressedResult=true (only used on gpx export). The save way is using the Share GPX feature.