Prefer forward driving by active route re-calculation.

0709 shared this idea 4 months 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.

Comments (5)

photo
1

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.

photo
1

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

photo
1

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

photo
1

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?

photo
1

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

photo
1

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.

photo
1

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.

photo
photo
1

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.

photo
1

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

photo
1

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.

photo
photo
1

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.

photo
1

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

photo
1

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 !