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

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)

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

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.

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

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

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

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.

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.

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 ?

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.

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.

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:

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

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.

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 )

= Compute instructions: Unset.

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

Ok, we discuss, app developper decides.

See you.

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

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.

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 ?

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.

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 ;)

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

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.

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.

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.

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.

@Menion

compute instructions always on

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

sounds ok - on first view...

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