This object is in archive! 

navigation gets confused for track which starts/finishes at same location

Andrew Heard shared this problem 8 years ago
Not a Problem

Below I have created a simple track that starts (green dot) and finishes (red dot) at about the the same location. A common situation.

55ae7fae58d589c28704bb8e88117252

When I start navigation, if I am closer to the finish trackpoint than the start trackpoint (both of which are logically same location) then navigation thinks I have already completed the navigation even before I have started. Note below the track is already marked as being traveled, and displays the "big question mark" icon:

046e416bad9f87958aa2426d2bcb0cc5

I now ensure when creating the track that the finishing point stops a little further back along the track, and when I start navigating, make sure I am also closer to the starting point than finishing point. If I notice the "big question mark" icon, I know I have cancel/restart the navigation.


I can alternatively set "strict route navigation" but then I loose the advantage/ features of "loose route navigation".

Once navigation has started properly there are no further issues, so I feel Locus could be a little smarter to detect this common situation and make a better initial guess instead of the more drastic option of "strict route navigation".

Replies (9)

photo
1

Hello Andrew,


I guess based on your screenshots:

1. you use just testing simulation mode, not a real navigation (GPS is disabled)

2. you have defined "maximum allowed deviation" less then 53 metres, that's why Locus display question mark and not correct order (navigation is switched to guidance because you are too far away from track).


Try you issue during real navigation and we will see. When GPS is enabled, Locus consider also your current azimuth, so during ride, such issue should not happen.

photo
1

1. No - this is with GPS enabled.

2. No - as I ride along the track in the correct direction for outward section, directly on the track, passing navpoints, the question mark never changes, navigation never commences. It is quite easy to reproduce.

So do I have to be within 50m of the track before I should commence navigation, or should Locus automatically switch from guidance to navigation within 50m?

photo
1

Locus switch automatically.


Anyway 1. cannot be correct. In case you have enabled GPS, visible line "53 m" have to be between current active trackpoint on track and you current GPS position (blue or green circle), not between your center cross.


This seems to be still repeating same problem. Track that lies on exactly same path in two directions. I'll try to simulate and check it during a week ...

photo
1

It didn't happen today. Same path in two directions, with start/finish at same point. I started navigating >50m from start but it worked OK.

photo
1

Just a little update on this topic. When I switched the Map Icon setting from dots to icons for the start/stop I think I found the problem - when I created a new copy of the track (with reverse route) the stop point (which had been further away) now becomes closer than new start point. So when I start navigating the stop point is closer, and without strict navigation, Locus correctly assumes I have finished the navigation. So close this topic. Lesson learnt.

photo
1

Ah ok, good to hear. These "start-stop on same place" and also "criss-cross" navigation tracks will be my death. :)

photo
1

Nooo.....

photo
1

I think "start-stop on same place" is a fairly common cycling scenario.

photo
1

Everything has been greatly improved in the latest releases - track editing/ navigation/ time to target - all working perfectly for non-strict navigation.

photo
1

Glad to hear it. Also mainly because of "start/stop" (rounds) trips, I've created support for "via points". Thanks to this, "recalculate" is also usable and with GraphHopper (probably also a BRouter), it is a deadly combination :).

photo
1

Round trip using via points trackplanning ok ;-) Instruction timing on common trackpath nok :-(

Instructions planned for returning path already spoken and consumed on outward path.

A simple traject demo:

47c08e50a1a00048f5e78145af53fde9

Similar to problem: http://forum.locusmap.eu/index.php?topic=4656.msg38020#msg38020.

photo
1

Thanks, issue found and fixed. (problem with precise instructions after reimport of GPX).

photo
1

I would love to use GraphHopper but unlike BRouter it doesn't support profile scripting and hence can't be adapted to country-specific customs. For example motorways in Tasmania can be cycled (unless signed) but GH creates track 20km long to avoid going through 100m motorway roundabout; with BRouter I can easily adapt these rules and tweak the elevation costs to suit my style of riding.

photo
1

Understand, nice feature. Yep, nothing like this is currently possible in GraphHopper. As I was checking it, all parameters are hard-coded directly in library.

photo
1

This example shows why offline GraphHopper is of no use to me at present - for the cycle profile the track is on a muddy gravel track instead of perfectly pleasant, nice surface, fairly quiet, bitumen road parallel to that track. BRouter fastbike and trekking profiles stay on the road. I discussed this on GH forum, the Java code change is pretty simple (1 liner), but not something an ordinary user is going to modify.

photo
1

Who wants to ride on the road? :). Anyway understand ...

photo
1

exactly - that's why the user needs control over their cycle profile, because everyone will want different costs - not as simple as a car user

Replies have been locked on this page!