This object is in archive! 

Brouter + LocusMap can not navigate from Germany to Croatia. In Croatia Zadar to e.g. Zagreb works

Johann shared this question 6 years ago
Answered

Hello, the online routing works fine from Germany (via Austria and Slovenia) to Croatia and the offline routing from Villach Austria (via Slovenia) to Zadar Croatia works also. It looks like if Locus Map pro routing offline through 4 countrys it does not work and I receive the massage "unknown problem".


Know anyone this Problem?


Regards Johann

Replies (10)

photo
1

The offline routing from Germany via Austria to Slovenia works also.

photo
1

Number of country borders does not matter.

What does matter for offline routing is

1/avalability of all needed RD5 5x5 deg grid files

2/Availability of resources for the long route calculation. Keep in mind the computation effort ( time, RAM ) grows approximately with the distance squared and Online servers are more powerful than the Android device.

Try to calculate the route via enough viapoints. You may note them from the online routing. That would make the calculation faster and less resource hungry.


Another approach is to generate GPX file with Locus navigation hints by the web BRouter client, download it, and follow this prepared GPX route. Even if deviated from the GPX route, recalculation to return to the route is much faster.

photo
1

Thank you, it works! Great App 🥇

photo
1

For a optimum energy saving is it better to navigate online or offline?

photo
1

In age of powerbanks and solar chargers, battery is IMHO the minor priority. What matters is, what navigation I prefer and if cell signal is present and if there is available and affordable air data plan. ( E.g. during airport transit I noticed data roaming price about 15 dollars/MB. If I would use online Google maps, it would drain my bank account a lot.)

Online navigation may be IMHO generally little more battery friendly, as the routing effort is on the server side. But the difference can be marginal, compared to LocusMap effort, even if screen is off.

The exception with offline routing advantage can be, if the cell signal is in terrible condition and the phone communication (attempts) are draining the battery, like in mountain valleys or abandoned rural areas.


Following the GPX route offline is more battery friendly than full offline routing, IMHO comparable to online routing. Keep also in mind, that for very most of the time, the offline routing is not active, as it is usually one time action.

Many people use GPS navigation together with the phone airplane mode, with all active signalling off. To save the battery and to be undisturbed, especially on vacation. This may be more battery friendly than keeping GSM model ON, especially in bad/no signal areas.

photo
1

Thanks Libor for detailed explanation.

photo
1

Maybe I can throw in sometimg more...


Brouter has a time restriction (60 seconds I guess?) I asked th edeveloper once why, but he didn't answer. The time restriction is noted in the readme of brouter.


That restriction allows only routes to be calculated within 60 seconds. All routes taking longer can't be calculated.


That only applies if brouter is used from within an App (Locus, Oruxmap, ...). If you use the brouter GUI, you can calculate longer routes. But you have to have the start and endpoint exportes as an gpx file. What you get from brouter is a gpx-track. That can be imported after calculation.


Cheers

AWo

photo
1

Brouter does not have such a restriction.

LocusMap had initially such a 60s restriction, causing a timeout if it did not receive the routing result yet. Later, after my discussion with the author, Menion, he increased this timeout to 5 minutes, as the short timeout complicated the navigation along long route on slower devices. ( Brouter has a feature to bypass this 60/300 s timeout when it occurs, as you can manually resume the calculation.. )


The mentioned Brouter time restriction 60s has different context.


When Locus(perhaps OSMAnd as well, not sure if OruxMaps) had the short 60s timeout yet, BRouter implemented a contra-feature called "timeout-free recalculation". If the route is supposed to cause ( or causes) the timeout, the user goes to BRouter GUI and triggers the route pre-calculation. When finished, then the user goes back to LocusMap and triggers the normal route calculation ( same start, end and profile ), BRouter then guarantees the LocusMap(OSMAnd,OruxMaps) will receive the routing data within the 60s limit of the LocusMap timeout.

photo
1

Hmmm, when I check the latest readme (I just installed brouter to check) I found the following sentence in line 185:


"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."


And the last section reads: Mixed operation: "timeout-free recalculations"

==============================================


You can combine both operation modes (service-interface + BRouter-App) to

become able to calculate very long distances, but make use of the advantages of

the service interface as well, especially the dynamic recalculations if you get

off the track, without running into the 60 seconds timeout.


To support this, BRouter can do "timeout free recalculations". It works by

initially calculating a track to your destination and binding it to one or

more routing-modes using the "Server Mode" button. This way, BRouter stores

a "reference track" in the "brouter/modes" subdirectory.


If afterwards a route to the exact same destination is calculated via the service interface,

BRouter uses a special calculation mode that makes use of the reference track for

faster processing that is guaranteed to give a result within 60 seconds.

"Exact same" destination means withing 5m, so best use the same waypoint for

re-calculating that you used for the initial calculation.


This way you can follow a long distance route via the service interface, enjoying

automatic recalculations if you get off the track.


File is attached.


Cheers

AWo

photo
1

Thank you, but I think I am quite familiar with the readme document. After the LocusMap timeout was raised from 60s, its navigation via BRouter definitely does not raise the timeout after 60s, as it was used to before.

Just a while ago I have tried a test route, that took directly in BRouter about 90s to calculate. When the same route calculation was trigerred from LocusMap navigation, the application was waiting those 90s as well with the waiting bar, and then it finally displays the route. No timeouts.

Replies have been locked on this page!