Re: B-router web The standard profile settings at start.

165 views
Skip to first unread message
Message has been deleted
Message has been deleted

Poutnik Fornntp

unread,
Dec 25, 2020, 8:52:22 AM12/25/20
to Willy, OSM Android bikerouting
Hm, I may have not got your question right.
Not speaking for the developer, just  user notes:

/1 Not sure about literal  "Straight straight" voice hint wording, never heard it yet. The BRouter hint logic says "Go Straight ahead", or like that, if some of the other than expected leaving roads have higher PriorityClassifier value than the expected one. The rationale behind is to avoid missing the the right way.

See also 

2/_3/  The optimal generally accepted value for the catching range is controversial. One may want explicit marking of every turn in a complex crossing area, other may prefer the general leaving direction from that area. Both have advantages in some scenarios and cause confusion in other ones. Personally, I use 20m.

4/ One has to be very careful where the shaping points are placed ( I have in mind Locus ones ), as BRouter takes them and ends and starts of a serie of independent routes. The best is if it is placed somewhere in the middle of a road that is being passed through, without any navigation event around.

Dne 25. prosince 2020 11:44:31 Willy <wiv...@gmail.com> napsal:

Who put out the fire here?

Op vrijdag 18 december 2020 om 11:21:36 UTC+1 schreef Willy:

Example files in zip and info demo in the Image.

1. Why Straight Straight is generated ? How to prevent these unnecessary commands here ?

2. Standard the turnInstructionCatchingRange is set to 40m. (Trekking profile and other) This causes a too agressive simplification.

3. Request: Set the standard (at start up) turnInstructionCatchingRange to 10m.  A reasonable more useful simplification.

4. Request: Actual behaviour by a Shaping (way)point a U-turn command is generated when it runs over another separated return path. (2 lane street). But when the out and return do use the exact same path, than no U-turn command is generated. It would be useful if it did so.

https://www.dropbox.com/s/shxaxhm53l39olb/B-router%20example%20files.zip?dl=0

--
You received this message because you are subscribed to the Google Groups "OSM Android bikerouting" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osm-android-biker...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osm-android-bikerouting/5c4a231e-7b01-43aa-9304-ac562adec214n%40googlegroups.com.

Message has been deleted

Poutnik Fornntp

unread,
Dec 25, 2020, 12:27:58 PM12/25/20
to Willy, OSM Android bikerouting


Dne 25. prosince 2020 17:35:21 Willy <wiv...@gmail.com> napsal:

1. Straight-Straight. No idea why that happens.But  I found out after I double checked my previous local osm edit.

It happens you are going along a smaller ( by the profile priority ) and crossing a bigger road. Or if going on a bigger road, which turns, but you are going straight ahead.

2_3 Controversial indeed.  I also found after that same previous double check of that same osm edit. 
By the usual setting (40m) the turn command is a worthless Straight, where a correct Left is expected when arriving from East. 
I think I just will remove this so controversial simplication in my offline Trekking file.  As it also hinders with 4.

Too small value like 10 m often  causes confusion, if due a location error, application or human  delay ,the hint is wrongly positioned in time or space. It may be then confused and unclear, to which turning place the hint belongs.

I often found general and average area leaving direction more confident. 

Message has been deleted
Message has been deleted

Poutnik Fornntp

unread,
Dec 26, 2020, 5:30:24 AM12/26/20
to Willy, OSM Android bikerouting
My experience with Locus hint timing along BRouter based routes is they are consistently 10-30 m behind the real position. GNSS location  error adds to it as well.

If the catching range is 4-10 m and there are e.g  2 options to turn right, stacked one after another, you may not know which one to take.

 I find in such scenarios  more useful the area leaving direction hint, similarly as for big round abouts.

I have learnt myself as a car navigator in foreign countries, that aside of the junction order, that can be easily confused, it is useful to learn the leaving direction. So I announce e.g. "the 3rd exit on 10 o'clock". As mapping may be incorrect or a road is not counted as an exit.

 But one has to keep in mind it works as area leaving direction and not as a simple turn direction. 

This may apply to cities as well as to paths in wood.

Dne 26. prosince 2020 9:00:47 Willy <wiv...@gmail.com> napsal:

Until now I was using or Plotaroute web (GH engine?) or the GraphHopper Locus offline solution. But as GraphHopper offline is going to be deprecated into Locus, I made a switch to the B-router offline solution. But by the Covid beast I had only some few local test drives by best fit profile Zossebart-mtb profile (catching range 4m). Drives on identical local circuits (just to be out) I lost so concentration by cycling in automatic modus, and did not notice some rather strange command hints. By the osm edit and a test using both B-router and the still functional offline GraphHopper mode I now noticed this strange behaviour. Must say the GraphHopper command hints do outperform BRouter. No problem with ferrie accesses, has street names and correct direction hints. By BRouter even the nearby hints as in the example do change by a (or no) catching range setting unexpectedly. Do not know what is happening, but the results do not make me happy.  Need a smart guy here for help.  Anyway GraphHopper = Correct.

Op vrijdag 25 december 2020 om 20:09:07 UTC+1 schreef Willy:
1_2_3. 
Using the Zossebart_MTB profile (set 4m) before ( used in Locus) it was always functioning very well.

Only  just recently I do see these new problems occur by the Trekking profile. Anyway  I really do not know what is happening.
It seems to me (tested by BRouter web).that the hint generation is not working nor reliable, and the results are just at random.
By changing the  turnInstructionCatchingRange setting from 10 to 1 and 0m  the instructions do vary randomly. 
When removing the turninstructionCathingRange completely, the instructions are also unpredictable mostly uncorrect.

So first  I thought it was by my osm edit there there was something false, but the GraphHopper hints are perfectly ok at that position by using any vehicle of by the walk profile.  So The Left direction keeps a Left without unexpectedly changing into a Straight.


Very strange but also on other places the hint results seems to be +/- unreliable. 
Need to take a  looong pause now. 

Op vrijdag 25 december 2020 om 18:27:58 UTC+1 schreef Poutnik:

--
You received this message because you are subscribed to the Google Groups "OSM Android bikerouting" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osm-android-biker...@googlegroups.com.
Message has been deleted

Poutnik Fornntp

unread,
Dec 26, 2020, 7:20:36 AM12/26/20
to Willy, OSM Android bikerouting
The hints are said/displayed by Locus, not by Brouter (BR). 

BR just marks the chosen crossings/junctions with the hint containing waypoints. Interpretation and implementation of  providing hints in advance is on the target application.

It is possible this part is better implemented for GH than for BR.

Dne 26. prosince 2020 11:34:04 Willy <wiv...@gmail.com> napsal:

Well. 
It does work 100% correct with GH.  It must be a problem in B-router I suppose. 
Navigation commands must be precisely attached, no guessings.
If using these hints I better can have a simple view on a map or buy me some paper maps.

Op zaterdag 26 december 2020 om 11:30:24 UTC+1 schreef Poutnik:
Message has been deleted

Poutnik Fornntp

unread,
Dec 26, 2020, 10:49:55 AM12/26/20
to Willy, OSM Android bikerouting
Well, part of it may be your interpretation. I am not sure you fully understand the Brouter hint logic. You may claim it is doing it wrong, because it may just do it differently than you expect.

I cannot check it now conveniently, being on phone only.  Does it mean that you do not go 3 times straight ahead there or that the Brouter straight ahead rule mentors before, should not apply there ?

OTOH, remember that there is the 2nd BRouter rule when to set a turning hint:
Brouter intentionally by design does not announce a turn left or right, if the route leaves the crossing along a road with the highest priorityclassifier value. Then, if you are passing a village or a town along a major road, BRouter does not tell you to turn left or right even if you have to.

So, does or does not have the leaving road the highest priority value when you turn and BRouter does not tell you to do so ?


Dne 26. prosince 2020 14:45:53 Willy <wiv...@gmail.com> napsal:

Interpretation ? Come on.
It is BRouter that adds the instructions wrongly that's the point. 

Check by other download format for example use turnInstructionMode gpsies-style.  By Set turnInstructionCatchingRange 0

See the generated gpx  waypoints.
Contains 3 x Straight instructions. Correct ?  
No, correct would be just one single Left turn generated.

<?xml version="1.0" encoding="UTF-8"?>
<!-- track-length = 407 filtered ascend = 1 plain-ascend = 1 cost=407 energy=.0kwh time=1m 2s -->
<gpx 
 creator="BRouter-1.6.1" version="1.1">
 <wpt lon="3.955753" lat="51.070438"><name>straight</name><sym>straight</sym><type>Straight</type></wpt>
 <wpt lon="3.955761" lat="51.070219"><name>straight</name><sym>straight</sym><type>Straight</type></wpt>
 <wpt lon="3.955015" lat="51.068451"><name>straight</name><sym>straight</sym><type>Straight</type></wpt>


Op zaterdag 26 december 2020 om 13:20:36 UTC+1 schreef Poutnik:

Poutnik Fornntp

unread,
Dec 26, 2020, 10:54:01 AM12/26/20
to Willy, OSM Android bikerouting
P.S. I usually follow just voice hints, saving the battery on long, often multiday trips, also finding checking the phone disturbing.
Area leaving direction hints is for me more practical than visual checking the map.

Dne 26. prosince 2020 11:30:22 Poutnik Fornntp <poutni...@gmail.com> napsal:

Message has been deleted

Poutnik Fornntp

unread,
Dec 26, 2020, 12:57:48 PM12/26/20
to Willy, OSM Android bikerouting
Calm down.

Dne 26. prosince 2020 17:49:43 Willy <wiv...@gmail.com> napsal:

OMG pse help me out.  Advise, first have a look at and a have test by BRouter web to verify this very simple example location situation by the link. Than reply.

Op zaterdag 26 december 2020 om 16:54:01 UTC+1 schreef Poutnik:

--
You received this message because you are subscribed to the Google Groups "OSM Android bikerouting" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osm-android-biker...@googlegroups.com.
Message has been deleted

Poutnik Fornntp

unread,
Dec 27, 2020, 6:13:09 AM12/27/20
to Willy, OSM Android bikerouting

Hi Willy,

addressing just issues from the original email for now:

-----

The straight hints issues in your example  are issues of mapping a/o the real scenario.

All diverting roads in the example are mapped as highway=unclassified, which are by OSM tagging definitions and by BRouter priorities between tertiaries and residentals. The route goes along a residential.

So Brouter does not announce straight hints by an error, but follows it's straight hint rule, as the possible ( and wrong ) turning alternatives have the higher priority.

You can prevent this behaviour, if you set for both involved highway=* classes, in your case residential and unclassified, the same priority in the PriorityClassifier. But it may affect proper working of the turning hint rule, if both road classes were involved.

The tag highway=unclassified, that is an official road class, is often misused for roads of unclear classification, that should be tagged as highway=road. I cannot say, if this is the case, as I do not know road classifications of Belgia nor the local situation.

----

The direction of leaving area design philosophy in the catching range context, merging all into one virtual  crossing -we already discussed it.

You may not like it, but it is like it is. You can always use your personalized version, or make Arndt to change the default, but different people have different priorities.

My one is between yours and Arndt's.

----

The missing U turn for the  shaping point case could be solved if Brouter computed routes with via-/shaping points as a single route. But it calculates it as a serie of independent routes. There are no hints for a series of starts and destinations. This is intentional by design and unlikely to be changed.


For a U-turning-like  shaping point on a  simple roads, it expects you to start the next route segment in the opposite direction, like if you really just started. For separate lanes/roads, it sees you are sitting in a wrong lane/road and tells you to turn in the opposite direction.

In Locusmap, it would be better to use a  viapoint instead of a shaping point for your case, as in cases of triggered route recalculation to a point, the shaping points before destination or the  next viapoint are ignored ( and forgotten for a case of a  computed route, i.e. not following GPX).

----

So it is a  lot about to understanding how Brouter works.

You need different approach to get help. Lack of self-control and personal offenses will not get you far, as you get more than you paid for.  So keep away from nonsenses, to use your vocabulary.





Dne 27. prosince 2020 9:45:28 Willy <wiv...@gmail.com> napsal:

I hoped an expert profile editor would help to detect a potential problem in the profile.
Since I am not a specialist in editing profiles, I therefore again ask for assistance.
The concrete location and the tested settings by BRouter web have been communicated.
Answering with nonsensical stories doesn't help here in concreto.

Another location and the same weird instructions by BRouter.
Both GH and Garmin Basecamp generate the correct instruction. LEFT.


Op zaterdag 26 december 2020 om 18:57:48 UTC+1 schreef Poutnik:

Poutnik Fornntp

unread,
Dec 27, 2020, 6:23:22 AM12/27/20
to Willy, OSM Android bikerouting
P.S.: Note also Brouter considers rather the road approaching angle in wider context than angle at the very point of OSM road connection, that is often mapped incorrectly.

Dne 27. prosince 2020 12:13:07 Poutnik Fornntp <poutni...@gmail.com> napsal:

Poutnik Fornntp

unread,
Dec 27, 2020, 6:54:16 AM12/27/20
to Willy, OSM Android bikerouting
Hi Willy,

You confuse right and expected.

What is right by one design philosophy is wrong in other one and vice versa. 

Connections of small roads, tracks and paths are often very different to the way they are mapped. Their mapped and real angles easily differ by 90 degrees or more. Traditional approach often leads to wrong hints. That is the reason for the approaching angle design and the whole multiple-crossing-area-leaving-direction idea.

You may call it nonsense or not intuitive , but it works, if you know about it and expect it.

Dne 27. prosince 2020 9:45:28 Willy <wiv...@gmail.com> napsal:

Volker

unread,
Dec 27, 2020, 8:34:05 AM12/27/20
to OSM Android bikerouting
Hi Willy,
try the Velomobile profile with 20 meters turnInstructionCatchingRange and you get better instructions. The routing of this profile will most likely not fit your needs, but you can set this value in the other profiles.

wiv...@gmail.com schrieb am Sonntag, 27. Dezember 2020 um 09:45:26 UTC+1:
I hoped an expert profile editor would help to detect a potential problem in the profile.
Since I am not a specialist in editing profiles, I therefore again ask for assistance.
The concrete location and the tested settings by BRouter web have been communicated.
Answering with nonsensical stories doesn't help here in concreto.

Another location and the same weird instructions by BRouter.
Both GH and Garmin Basecamp generate the correct instruction. LEFT.


Op zaterdag 26 december 2020 om 18:57:48 UTC+1 schreef Poutnik:
Calm down.

Poutnik Fornntp

unread,
Dec 27, 2020, 9:15:26 AM12/27/20
to Volker, OSM Android bikerouting
Hi Volker,

My profiles use 20 m as well, AFAIK. 
But the Zossebart's MTB profile that  Willy has mentioned may fit his needs better.

Dne 27. prosince 2020 14:34:07 "'Volker' via OSM Android bikerouting" <osm-android...@googlegroups.com> napsal:

Reply all
Reply to author
Forward
Message has been deleted
0 new messages