Don't use guiding mode if user wants navigation mode (with BRouter)

Andrew Heard shared this idea 3 years ago
Completed

When navigation mode is commenced with offline BRouter as the data source, but there are no turns (waypoints/ navigation commands) along the way, Locus decides it knows better than the user and enters guiding mode instead of navigation mode.


Note it appears (in my limited testing) this behavior only affects navigation when using BRouter as the navigation data source.


This feature? has caught out many users, myself many times, wasted lots of online discussion, chasing tails, going around in circles.


A workaround for an otherwise problematic track is that one single waypoint/ turn at road junction/ navigation command is required for correct operation. Any point will do! So, my suggestion is simple: if the user wants navigation, then use the navigation mode. Maybe internally, Locus can create a hidden point at the beginning or end of the track to be followed if need be, but the user shouldn't need to know or care about these details.

Comments (9)

photo
1

Or the question arises: Who has to generate that starting Nav point ? B-router or Locus ?

If track generated by B-router (Compute instructions = SET) starts by a "Straight" Navpoint, problem solved.

EDIT:

So I see by these very fast replys:

Your preferred solution = a solution by Locus. And so keep a cleanest generated track. (= trkpt points only)

As any Navpoint = An extra generated point in the Waypoint list ?

Attention ! If you ask Locus to Navigate on empty track = Generate navpoints based on the trackshape !

hmmm...only Brouter has the correct answer:

As I Brouter says: At Start Go straigth and further I have no instructions for you = a clear message.

Anyway= most important = idea is launched...and now waiting for that 3e vote. and more.

;-) 10u07 actual time.

photo
1

I don't think any mod to BRouter can always work properly. How would BRouter know whether the user wants a track calculated for guiding or navigation? Only Locus knows the mode the user has chosen. So adding a "straight" navpoint (waypoint) seems like a short term hack workaround instead of a well considered solution. (just my 2 cents worth)

photo
1

Even on a track with navpoints you can explicitely ask for Guiding instead of Navigation.

photo
1

If a user wants guidance, he will choose guidance. :-) There is no reason for Locus overruling the user request, unless the intended track is not routable. But in such a case a user should be asked if he agrees with switching to the guidance mode.

The Brouter based navigation was working without any navigation hints before. I see no reason why it should not work without them now.

photo
1

hmm...all tracks are routable...but some are very simple.

In the earl(ier) days of Locus: Navigation: Locus asked: Your tracks seems to have no navigation points and so Locus suggested: Must I generate the navigation hints for you ? (based on trackshape).

photo
1

But there is not guaranteed the track is a result of routing.

Also, all depends on definition of routing - track following or track generation ?

photo
1

For B-Router design: Autoroutable track is only via known mapped (OSM)streets. But for Locus there is no such limitation. A new design by B-Router of coarse, as most tracks run over already mapped streets. But even a mix (= perfect flexibility) is easy to design. During design switch off autocalculate for a moment, than run part of track (= direct track) over unmapped area, and when back on known (OSM) street set autocalculate on and proceed. Later, manually, by Locus track edit add some missing (turn)instructions.

And of coarse: Best is: Or not using function autorecalculate or at least try not to trigger the autorerouting by not driving off track when in the near of that direct track path.

Files: Hhhh.txt
photo
1

It is not matter of autoroutable track, but of a track being result of autorouting of not. That applies to all OSM routing services, not just to Brouter. The new design of BRouter tracks changes nothing about it.


The hybrid approach for track design ( partial by autorouting, partial not ) is of course possible to design. In fact, I was soggesting something like that in past, not sure if for locus or OSMAnd.


But one of main obstacles is terminology consistence, agreement on the same terms mean the same thing. Or with different meanings there is need their applicability domains never overlap.


Routing and navigation are wildly used in different meanings and different GUI placing over the Locus usage with large overlapping of domains of track preparation and the track following.

photo
1

Some pause...some thinking. In my opinion its B-routers task.

B-router: Do not want instructions ? Unset generate instructions.

Want instructions ? Set generate instructions.

B-router should at least by one single Navpoint (straight at start) confirm that it has taken care of the (intelligent) navpointgeneration.

Imported into Locus this track contains the clear message that Locus should not offer his own generation service anymore. And that is what most of us do want to obtain ? No ?

Not convinced ? See a generated track by B-router generation service (mode 2).

But how should Locus known that already a more intelligent system has generated (no) navpoints ?

No navpoints generated, not even a 'marker' very simple Straight at the start, Locus never will known.

So use the Locus generation service ? Agree with the result ? Nice ?

photo
1

Sorry, but I think you miss the simple point of my suggestion.

  • At present if I ask Locus for navigation on a BRouter generated track that has at least one corner, then navigation mode is correctly entered.
  • However if I ask Locus for navigation on a BRouter generated simple track (although could be very long - one example yesterday I did - 100km!), then guidance mode is entered - confusing/ inconsistent.

That's all. I specifically mention BRouter in topic summary because when I test the same simple track with online navigation data sources navigation mode is correctly entered.

photo
1

Its about gpx tracks ! GPX. Online data sources ? Name ? = tcx ?

Most external sources provide instructions using tcx system. But we do not dicscuss generated files using that already 'adult' tcx system !

Locus Navigation not starting has nothing to do with Brouter itself. The track source does not matter. On any simple gpx track without any serious corner, so internal Locus system does not dedect any turn, no Locus navigation is started. Bug ?

NEW Brouter delivers the commands using gpx ! A NEW system, so probably needs some small fine tune to optimally cooperate (talk) with apps (Locus).

If Brouter tells Locus by at least one single straight command at start, locus navigation always do start. ++ So Locus will even never try to use his internal generator as brouter confirms: I Mr Brouter already did that job for you !

Actually if you present a generated (Set: compute instructions) track with MANY corners but no single turn command generated, as the only alternative is going forward Locus does not know that the tracksource (here Brouter) already had taken care of these commands because Brouter left no such a single message nor a 'marker' (straight) at start.

So Locus starts up the internal generator and on the example track above (= part of Alpe Dhuez climb) delivers you multiple but totally unnessary turn commands.

photo
1

hmm, I'm not convinced it is directly related to a GPX or TCX file format. Sure - can be used has hack workaround. When Locus uses API method of communication with data source, the API has no connection with real files.


Here is another example of confusing navigation behavior: A) navigation is working correctly:

b12282b64d21ab1555e6bc98edf27591

B) I then tap "Recalculate", and now Locus is in guiding mode:

8534eb10bd0d84b099dec1c05e3d1069

I know why is has occurred, so no need to explain. But, as per my suggestion, I wish Locus would just stay in navigation mode.

photo
1

If Brouter does not intend to write down any hint, it could place just a destination hint.

A) Locus would be hint aware and trigger navigation

B) User would be aware no hints are on the road.

C) Being in Locus navigation mode, route recalculation would be available, if allowed.

D) If autorecalculation has route priority, it would calculate just return from deviation , not the whole route to destination. ( this could be essential for long routes )

photo
photo
1

Rather, such a point should not be needed. There are legitimate cases, where BRouter is not expected to raise ANY navigation hint. Putting an extra point is rather a workaround to bypass the problem than a problem solution.

photo
1

= Compute instructions: Unset.

photo
1

But that is another workaround. It should work with keeping it set ON.

photo
1

Ok, we discuss, app developper decides.

See you.

photo
photo
1

hate discussions on helpdesk because there is a mess with reply childs.

What ever...


'have 4 good arguments:


- If i select "guiding", I don't expect "navigation".

- If i select "navigation", I don't expect "guiding".

- If i select "guiding", I expect "guiding".

- If i select "navigation", I expect "navigation".

:)


and

...I need the "navigation" for my personal tts "arrivied" message/sound.

Possible?

photo
1

Well Mister Gynta,

Why in Locus 3.17.2 navigation (generation) by Locus is not offered ?

A workround by our developper because no distinction of routingsource (was) possible ?

Or a test to see how many users complain about missing Locus navigation generation ?

Btw... Brouter results = Nice ! No doubt.

Personal tts when arrived ? Let me guess:

HEY MÄDEL, PFLÜCK MIR EIN EDELWEISS

photo
photo
1

Ok Andrew,

well I think we agree it is not always that simple to find ALL possible issue's even when performing A LOT OF tests.

I still have to look at your last example, but sorry now I (must) have some garden work to do. (Large garden at my parents home +/- 90 years old both so.....)

My actual conclusion so far was:

In the title: Guiding, Navigation,Brouter.

1. Starts up in Guiding instead of Navigation is yes probably a (small) Locus bug. Found by tests: Only on very special (gpx) tracks without any corner, so long time not a discovered issue.

2. Brouter: A Report: Brouter output is not the explicit cause of that previous problem.

3. Brouter: A Suggestion: The Navigation user experience can be improved by a very small addition and optimalisation in the BRouter output file feed towards the Locus app.

Regards my friend,

Willy.

photo
1

@Menion


I see your smiling face, but i'm missing your comment B)

photo
2

Hello guys,


seems that 3 day long vacation is too long to leave you all alone here :).


My opinion is probably same as gyntas and it's only logical opinion I think. User wants "navigation", he have to get navigation. User wants "guidance", he have to get "guidance". No other options are possible, simple.


Where is a problem? Definitely on Locus side. BRouter computes routing correctly. Probably same behavior may happen with GraphHopper or any other routing service.


Solution? I believe it will work. After every routing, before track is used, Locus do something like "validation". All waypoints and trackpoints are tested and to waypoints is attached/set correct index of trackpoint with same coordinates. And here I've added function that check if last trackpoint has valid waypoint with "destination" command. If not, it's added. Of course only in case, user wants "computed instructions".


I believe this will work.


Because current public version seems to be quite stable, there is no need for another bug-fix version, so there will be enough time to test it in one of next Beta versions.


Thanks all for opinions!

photo
1

In the end, it won't be so simple. Too much features in connected in Locus.


My important question: is is useful for anyone settings "Compute instructions" in "Navigate to" function? If so, what expect from it?


Because "Navigate to" should logically start navigation in all cases (not guidance). And navigation without navigation instructions does not make sense. For more complex planning should serve "Add new route" function. So from my point of view, this settings should be removed, isn't it? Only what should be interesting here, may be a small warning for older BRouter and Yours services, that navigation instructions will be generated by Locus from shape of track.

photo
1

Prior to BRouter 1.4.1 I always turned off "Compute instructions" because instructions generated by Locus from shape of track were of no use. But now "Navigate to" + "Compute instructions" + BR is a joy to use, and see no common scenario for turning off instructions. If you display a "small warning" please only display once & not every time navigation is used.

photo
1

The Old solutions ?

-GraphHopper experimental: Always (what I observed) starts Navigation by function "Navigate to" even on a "artificial strange" short and straight traject.

When such a track is saved (exported) by save permanently function = saved inclusive the integrated instructions. A "Straight" at trackstart and a "Destination" at the trackend. (= the signature by routing service that points where generated).

-Import a track without (saved) integrated instructions. About 2 years ago Locus nicely offered his (not ideal) service. Your track seems to contain no integrated turninstructions, should I generate these for you ? Y or N ?

photo
1

I see a bitter fruit of the terminology hell here :-) As the Navigation in wider sense consists of

Navigation in narrower sense as route generation

Navigation in narrower sense as communicating the route to a users

A user may wants the former navigation ( route to be calculated and/or maintained by autorecalculation, but at the same time he may not want the latter navigation ( giving voice or display hints ), if visual following the route is enough for him.


At the same time, he may not be interested an route management.

photo
1

No need to repeat a problems in terminology. At least I do not see it ;). Let's call function that display big navigation icon in top left corner a "navigation". And function that always, in all cases, display simply arrowed line on a map and display only a small icon in top left corner, as a "guidance". Both has it's specific settings of course.

Question here is, if function called "navigate to", should have option to disable compute of instructions. As Libor mentioned somewhere, don't get confuse by name of this settings. It should be better named - attach to track navigation instructions (no matter if service provide them or Locus compute them), or not.

I'm asking, because it attracts me, to completely remove this settings and allow to start really just a "navigation" over this function, nothing more. For creating route for a guidance should be then used "Add new route" function, that has a lot more flexibility.

Hope my English explain my intention clear.

And @Andrew, in case of BRouter, agree. I'm just looking on it from view of thousands users, where everyone use different service for different use case, so not just BRouter. Thanks for opinion.

Ah and @0709: it's possible that I fixed these problems in other services, that's why this problem occur only in case of BRouter.


Anyway I'll probably do something what I mean as a best solution, and you will try it in Beta version ;)

photo
1

I guess Use/compute instructions is better than just compute.

photo
1

We are strange guys, most want and expect new brouter app be able to add intelligent navigation hints? An extra button: No instructions ? Visually following ? Sound off, or no navigation, display track only. If not disturbed by the blue dots.

Actual: Export as gpx.10 (removes the extension garbage) then reimport and split into waypoints and track. Keep track. Yes, another workaround for "nerds" only.

photo
1

Personally, I am quite fine with removing compute instructions , taking it as ON by default.

BUT aftecting of possible scenarios has to be evaluated.

What if one usedimported GPX form other than BRouter source, without the hints and does not want Locust to generate it turning based instructions ? If he just wants to watch the route and get it corrected by autorecalculation. E.g. if keeping device screen OFF and silent, and just occationally turned on.

by other words, I imagine cases of Routing ON, reporting OFF. Little sense for cars, possible much more sense on bike or on-road-hiking multi-day tours.

photo
1

No problem Libor, but I feel some compassion with our developper too..as Locus already has a lot of settings (some via config.cfg). So, lets wait and see.

photo
1

Menion, sorry I waited to answer your very specific question. I needed some time to think about use.

Question here is, if function called "navigate to", should have option to disable compute of instructions.

I do not care if you remove or not. But, no change, means not triggering a lot of contra comments now or later.

photo
1

@Menion


compute instructions always on

and if result = no instructions then create dummy (to stay in navigation mode),

sounds ok - on first view...

photo
photo
1

By the way, latest (current) BRouter profiles has

> assign turnInstructionMode = 1

in every profile, except shortest.brf (Locus use this profile for foot navigation).

So, now Locus (release version) can't start navigation for foot. It start only guidance.

But you can add this line ("assign turnInstructionMode = 1") into shortest.brf to solve this.

photo
1

Not exactly, as additional code snippets need to be included. without it it would work incorrectly. There should be added to the way context the code below.

As alternative, one can use some of hiking profiles derived from my Hiking template. ( See also its Github page ). Optionally with assign shortest_way 0 to mimick the shortest profile.


  1. # way priorities used for voice hint generation

    assign priorityclassifier =

    if ( highway=motorway ) then 30

    else if ( highway=motorway_link ) then 29

    else if ( highway=trunk ) then 28

    else if ( highway=trunk_link ) then 27

    else if ( highway=primary ) then 26

    else if ( highway=primary_link ) then 25

    else if ( highway=secondary ) then 24

    else if ( highway=secondary_link ) then 23

    else if ( highway=tertiary ) then 22

    else if ( highway=tertiary_link ) then 21

    else if ( highway=unclassified ) then 20

    else if ( highway=residential|living_street ) then 6

    else if ( highway=service ) then 6

    else if ( highway=cycleway ) then 6

    else if ( bicycle=designated ) then 6

    else if ( highway=track ) then if tracktype=grade1 then 6 else 4

    else if ( highway=bridleway|road|path|footway ) then 4

    else if ( highway=steps ) then 2

    else if ( highway=pedestrian ) then 2

    else 0

    # some more classifying bits used for voice hint generation...

    assign isbadoneway = not equal onewaypenalty 0

    assign isgoodoneway = if reversedirection=yes then oneway=-1

    else if oneway= then junction=roundabout else oneway=yes|true|1

    assign isroundabout = junction=roundabout

    assign islinktype = highway=motorway_link|trunk_link|primary_link|secondary_link|tertiary_link

    assign isgoodforcars = if greater priorityclassifier 6 then true

    else if highway=residential|living_street|service then true

    else if ( and highway=track tracktype=grade1 ) then true

    else false

    # ... encoded into a bitmask

    assign classifiermask add isbadoneway

    add multiply isgoodoneway 2

    add multiply isroundabout 4

    add multiply islinktype 8

    multiply isgoodforcars 16


photo
photo
1

Tests ? Reports ?

A (single) navigation waypoint(s) confirms navtrack generated by intelligent system.

A (single) navpoint(s) prevent Locus to use internal navgenerator based on trackshape.

Locus trackstart not (audio) announced, or autoadding a navpoint Straight is harmless.

Best not at trackend to * prevent a conflict with personal tts "arrived" message or sound.

* If exported to tcx: <Name>Finish <PointType>Generic !

* If exported as gpx 1.1 no such conflict problem, by <locus:rtePointAction>24</locus:rtePointAction>

Actual situation in Locus testversion 3.17.2.4.

"Navigation to" function: Navpoints auto added at trackstart AND at trackend.

"Route and Measure" function: No navpoint(s) added ?

Suggest: Autoadd a single navpoint at trackstart ONLY.

Attachment: Navigateto and routeandmeasure example.