How to avoid critical strict set in Navigation.

freischneider ●

every now and then I would like to intentionally shorten the route. Then Locus would not recognize this track point. The idea is very good. You could generate a warning message or a question when Locus jumps to a trackpoint in the hidden area. If that is wanted I confirm yes and if not mine.

Reply URL

1

0709 ●

Yep, understand.

No trackpoints should be hidden for the manual selector "To nearest trackpoint" that allows you to skip track sections. This is also functional and allows you to skip track sections while operating by the actual VERY strict navigation mode. The main goal of the idea is to avoid these uncontrollable unexpected jumps, while still maintaining the flexibility by the standard so NON VERY strict mode navigation operation.

Reply URL

1

Menion ●

Hi guys,

such feature is already partially implemented. What happens on the screen is limiting a fully visible route to distance defined by the screen size. What already! happens inside the routing is that with every new location (usually 1 per second), the app tries to detect if the user is still on the route and if not, it tries to find optimal trackpoint (in case of disabled Strict nav.). And here already exists a limit to 100 next track points, not more.

In rare cases, the app select trackpoint incorrect, there is always a safenet as "Nearest point" in the navigation menu.

Does it make sense? If so, any other suggestion?

Reply URL

1

0709 ●

The 100 next track points? That explains a few things. That can therefore already be a fairly long trajectory length that can already cross itself. Earlier I thought of a protection length of the order of 100 meters. By the way, before and during the Strict navigation introduction this was also tested in a densely built environment with relatively short self-crossing 8 loops.

See the example with the always very critical, fairly short T deviation to a turning point that is not too far away from the main trajectory. (Many GPS units fail in this test)

Artificial forced circuit? Yes, but this can still happen. Such as a short deviation to a viewpoint somewhat away from the main route.

In standard nav mode with real test drive, this is almost always successful. And I also know why. Aerial photo because of trees does not show this. Street View does.

https://www.google.be/maps/@51.0512487,3.9988805,3a,75y,178.82h,73.75t/data=!3m6!1e1!3m4!1sNQ2yLTQteFJZu0zIRdH_GA!2e0!7i13312!8i6656

As a right driving cyclist you therefore already cut the bend to the right directly toward the turning point, before you too nearly approach that critical T junction as is drawn designed on the map.

If the curve to be taken to the right would be less wide, the chances are greater that due to GPS / map tolerances you will pick up the later and therefore wrong track point AFTER the T first.

Strict navigation mode (with comfort disadvantages for the entire route) does continue to "mecker" if you (by forced test!) skips that T without turning toward the turnpoint. (Point by name "Keerom" and cmt "Keerom na het controlepunt"

See video demo: https://youtu.be/0b9Vq9gk7b8

Video: "Strict Must Pass Via Points" title is meant for another gps forum that optimally uses AND Shape AND Via Points active also in the Navigation mode. (Like the Garmin's gps do).

Not (yet) presented here for this Locus topic. This current idea, if successful in tests, maybe will prevent the need for such Must Pass Via Points. Anyway I do realise a secure robust gps track_route navigation by a very complex circuit design is a fairly tough job to do for the gps app developer in the end.

The 100 next track points? That explains a few things. That can therefore already be a fairly long trajectory length that can already cross itself. Earlier I thought of a protection length of the order of 100 meters. By the way, before and during the Strict navigation introduction this was also tested in a densely built environment with relatively short self-crossing 8 loops.

See the example with the always very critical, fairly short T deviation to a turning point that is not too far away from the main trajectory. (Many GPS units fail in this test)

Artificial forced circuit? Yes, but this can still happen. Such as a short deviation to a viewpoint somewhat away from the main route.

In standard nav mode with real test drive, this is almost always successful. And I also know why. Aerial photo because of trees does not show this. Street View does.

https://www.google.be/maps/@51.0512487,3.9988805,3a,75y,178.82h,73.75t/data=!3m6!1e1!3m4!1sNQ2yLTQteFJZu0zIRdH_GA!2e0!7i13312!8i6656

As a right driving cyclist you therefore already cut the bend to the right directly toward the turning point, before you too nearly approach that critical T junction as is drawn designed on the map.

If the curve to be taken to the right would be less wide, the chances are greater that due to GPS / map tolerances you will pick up the later and therefore wrong track point AFTER the T first.

Strict navigation mode (with comfort disadvantages for the entire route) does continue to "mecker" if you (by forced test!) skips that T without turning toward the turnpoint. (Point by name "Keerom" and cmt "Keerom na het controlepunt"

See video demo: https://youtu.be/0b9Vq9gk7b8

Video: "Strict Must Pass Via Points" title is meant for another gps forum that optimally uses AND Shape AND Via Points active also in the Navigation mode. (Like the Garmin's gps do).

Not (yet) presented here for this Locus topic. This current idea, if successful in tests, maybe will prevent the need for such Must Pass Via Points. Anyway I do realise a secure robust gps track_route navigation by a very complex circuit design is a fairly tough job to do for the gps app developer in the end.

URL

1

Menion ●

My list of "Do later" tasks related to navigation system is growing ....

100 points ... yes, it's problematic value. It may be a huge distance, but not always. Probably better as we talk about it, should be estimated time, so for example "Search distance: 5 minutes of ride", instead of current "Search distance: next 100 trackpoints".

URL

1

0709 ●

Menion: "Find optimal trackpoint (in case of disabled Strict nav)"

The "cordoned off" traject path: = From user gps position + 100 m > this than till the first next trkpt.

Goal: For any (complicated) navtrack circuit a robust navigation without need option SET Strict.

Some references.

Kurviger too suffered from unexpected jumps by standard (non strict) navigation on self crossing tracks.

- This app @ navigation by Set Strict: Operation by Must Pass announced Via Points combined with Must Pass non announced Shape Points.

- Garmins do not have option Set Strict: Standard operation is by Must Pass announced Via Points combined with Free Pass non announced Shape Points.

Must Pass: = Skip by user menu action ONLY. Free Pass: = Can be "auto" skipped.

In both apps the Via AND Shape points are reference points @ routing (re)calculations.

Example of a multiple self crossing trajectory.

(BE) "The Tour of Flanders" Professional cycling

The trajectory contains many self crossings but no professional cyclist skips circuit parts.

As during the race the "next near route to follow" is cordoned off with crowd barriers.

Taking a wrong turn at the critical intersections is thus made impossible ;-)

Menion: "The list of "Do later" tasks related to navigation system is growing."

So for now suggest "Do later". Better let it rest (think) for a while. Idea temp on hold.

URL

How to avoid critical strict set in Navigation.

Replies (3)