New Topic

Locus Map - help desk Topic Idea Locus Map (Android)

This object is in archive!

Category Locus Map (Android)

Tags Navigation., Route recalculation

Comments 13

Subscribers 4

Votes 1

Prefer forward driving by active route re-calculation.

0709 shared this idea ago

Completed

Add neglected return order to a 'penalty counter" into the reverse (shorter) drive direction.

Ignoring (multiple) return suggestions so promotes the (alternative) forward (longer) path.

My (cycling) settings: Alert distance: 75m. Recalculation distance: 100m.

I like this idea 0

Replies (5)

Menion ●

Good day Willy,

we probably talk mainly about BRouter right? In case, there is any recalculation, Locus has the only option: specify to BRouter current users direction and also how long (in seconds), the user should stay in the current direction.

Current Locus Map has defined 3 seconds. From your personal experience, this time is too short?

In case of GraphHopper, there is only an option of "users direction", not the time.

URL

Stephan ●

Are you really sure, because I can influence the start time of recalculation be the recalculation distance using brouter.

URL

Menion ●

May you describe more in detail what you wrote please?

To be true, I'm also not perfectly sure what Willy wants.

In case, I ride in the certain direction, which is for some reason out of originally planned route, what else should be important to me except parameter "how much time I need till I will be able to react on new computed instructions"?

URL

0709 ●

Ok I'll try to explain. See my settings. After deviating from the proposed route (for whatever reason) Locus generates multiple return commands until an alternative (shorter) new route path is generated. When ignoring (for whatever reason) "multiple" such returns commands Locus should fastly 'learn' and prefer route generation into the forward (driving) direction even when this results into longer total path distance. At least if a correct alternative path into the forward driving direction is available. By adding a penalizing (counter) system at the return path route generation, each time a successive return order is generated. So still at least a single return command is normally generated. So a (forward) alternative (even when longer) route so fastly becomes more and more favorised. Roger?

URL

Menion ●

Hmm roger, finally understand and agree it may be useful.

I also personally remember an experience, when riding a different path by intent and have to listen "recalculation success" every few seconds until routing decided that it will be better forward.

But I have absolutely no idea how to do this ...

URL

Stephan ●

I am not really sure, I used for many years Brouter with Osmand. But it seems to me, that Brouter reacts different to loosing the intended route in this two apps. It is in the most cases in the first attempt a going forward solution in Osmand, in Locus it is mainly a going back solution.

URL

0709 ●

Okido, I do understand Menion.

By using only external routing sources, indeed probably not a simple task.

Keeping at least ONE single out of track alert before a new recalculation(s) occurs does warn a (distracted) user(s). I got inspired by some concurrent (routable maps) (auto)(cycle) gps nav softwares.

Anyway I prefer the Locus navigation compact discrete loud and clear tone commands ;-)

Compare by example video: https://youtu.be/LgOroLaG4Xw

Alternative path is short deviation, so here Locus generates limited number of track alerts and "return" recalcultion(s) result.

URL

Menion ●

Hi guys,

I'm analyzing this problem and its solutions.

Seems that system I have in the code for BRouter is just copy&paste mistake from old not anymore working MapQuest system. Seems that BRouter does not support necessary feature at all, but I've rather asked on BRouter forum here, so we will see.

Anyway, GraphHopper implementation should be correct. GraphHopper is mainly online-based routing, but from my tests, data usage is so low (few kb) that it does not even worth to worry. So if possible, give it a try Willy, it should be better.

And if I get some information from Arndt about any possibility to do this in BRouter as well, I'll definitely implement it and let you know here.

URL

Stephan ●

Arndt explain here how Brouter do recalculation: http://ftp5.gwdg.de/pub/misc/openstreetmap/FOSSGIS2015/772.mp4

URL

Menion ●

Heh, oki thanks, but ... after all these years, my "German language" skills start and end with the word "Karte". Anyway from what I see, it is the explanation of routing algorithm, but not a technical solution I need here.

URL

Michael Peeters ●

I watched the presentation given in the link above.

It's no technical instruction but there is a explanation how Brouter does recalculation internally.

If you lost the planned route brouter checks for the nearest point of the planned track doesnt matter if back or forward direction.

It doesn't use this as the target for recalculation because it might you point back. Instead it looks for a point factor 30 of this distance in forward direction and uses this as the recalculation target point. With this the new recalculated way is more or less "optimal".

Assume you start recalculation when nearest point is 200m.

Brouter looks for a point in (200*30) 6km distance (forward) as the target point.

Interesting idea.

I think this isn't used in Locus for route priority?

As far as I undersood Osmand uses this recalculation algorithm.

Then there should be a interface for this.

Files:

URL

Michael Peeters ●

Don't know what happens in this logic when planned track has multiple points in 30*x distance....

URL

0709 ●

The system by (temp) return block seems to do the job correctly (V.3.38.7.5)

Maybe needs only some smaller fine tunings. Discussion topic here :

https://forum.locusmap.eu/index.php?topic=6554.msg56255#msg56255

Until recently Point Priority by multiple Via Points (transferable by gpx) was the only usefull mode

But now Route Priority (for the first time) delivers (auto)recalcualtion as expected.

Nice ! Completed !

URL