Android Brouter app 1.7.0 do not calculate the right route

[LupinSun]

It seems that these parameters while changing them do not affect the calculation: assign downhillcost; assign downhillcutoff, assign uphillcost, assign uphillcutoff I tryed as external app combine with locus map, and seems that locus map offline calculation have same problem, obviously tested same profile I attached here, no problem with the old version 1.6.3 Enduro v3 initial.zip

[quaelnix]

@LupinSun, the profile is nice, but I cannot find any significant difference in behavior with BRouter 1.7.0 vs. BRouter 1.6.3.

Both downhillcutoff and uphillcutoff are set to 25, which is understandable but still pretty high:

# the global elevation parameters
assign downhillcost             = 100
assign downhillcutoff           = 25
assign uphillcost               = 100
assign uphillcutoff             = 25

The profile should probably use validForBikes and not validForCars as it does right now:

# generate a bike route
assign validForBikes            = false
assign validForCars             = true
assign validForFoot             = false

[0709wiwiwi]

Valid for Cars > Enduro = Motorbiking

@LupinSun You should add your brf file as you have published in the Locus forum named "enduro v3 profile problem.brf" (Blank demo map).

[LupinSun]

@LupinSun, the profile is nice, but I cannot find any significant difference in behavior with BRouter 1.7.0 vs. BRouter 1.6.3.

Both downhillcutoff and uphillcutoff are set to 25, which is understandable but still pretty high:

# the global elevation parameters
assign downhillcost             = 100
assign downhillcutoff           = 25
assign uphillcost               = 100
assign uphillcutoff             = 25

• I have a profile that use very high value:

  # the global elevation parameters
  assign downhillcost             = 4000
  assign downhillcutoff           = 1000
  assign uphillcost               = 4000
  assign uphillcutoff             = 1000

try these parameters on brouter-web and try the same on brouter app, same profile different compute! I'm a beginner, I can't create the profile, that's why zossebart helped me, but I can more or less understand some parameter and edit them , maybe they are too high? But if I put lower values ​​the compute is always the same.

The profile should probably use validForBikes and not validForCars as it does right now:

# generate a bike route
assign validForBikes            = false
assign validForCars             = true
assign validForFoot             = false

Unfortunately I don't know the differences of this parameter, and I left everything as zossebart did, I'll try it

[LupinSun]

@LupinSun You should add your brf file as you have published in the Locus forum named "enduro v3 profile problem.brf"

I attached the profile to the first post, Enduro v3 initial.zip here I attach the two gpx compute file with same profile but different version of brouter app gpx file, same profile different result.zip The red track is compute from version 1.7.0, the green one calculated with version 1.6.3 and also brouter-web site (correct calculation), always the same profile with this values:

 # the global elevation parameters
assign downhillcost             = 4000
assign downhillcutoff           = 1000
assign uphillcost               = 4000
assign uphillcutoff             = 1000

there is something changed in the brouter 1.7.0 app or LoRouter offline compared to the old versions or the brouter.web site

[quaelnix]

I have a profile that use very high value:

# the global elevation parameters
assign downhillcost             = 4000
assign downhillcutoff           = 1000
assign uphillcost               = 4000
assign uphillcutoff             = 1000

The idea behind uphillcutoff and downhillcutoff is to tell BRouter when and when not to penalize changes in elevation.

• uphillcutoff=5 means that an increase in elevation is only penalized if the slope of the road is at least ~ 5 %.
• downhillcutoff=8 means that a decrease in elevation is only penalized if the slope of the road is at least ~ 8 %.

uphillcutoff=1000 and downhillcutoff=1000 should practically eliminate the elevation penalty entirely, which for some reason is the case with v1.7.0 but not with v1.6.3. So this is a bug in v1.6.3 that has seems to have been fixed in v.1.7.0.

It would be interesting to know what caused this error in v1.6.3. However, so far I have not been able to find the cause.

---

Links to the test route and test profile:

• Route: brouter.de/brouter-web/#map=12/39.9051/8.6791/...
• Profile: https://paste.rs/JEXNB

[LupinSun]

It would be interesting to know what caused this error in v1.6.3. However, so far I have not been able to find the cause.

If so, on brouter-web and bikerouter.de site too

[quaelnix]

Yes, as soon as brouter.de and bikerouter.de update the BRouter version running in the background to v1.7.0 or newer, you will no longer be able to generate the red track with this profile. If you actually prefer the red track, then you have to adjust the profile until it generates this track again.

[LupinSun]

The idea behind uphillcutoff and downhillcutoff is to tell BRouter when and when not to penalize changes in elevation.

• uphillcutoff=5 means that an increase in elevation is only penalized if the slope of the road is at least ~ 5 %.
• downhillcutoff=8 means that a decrease in elevation is only penalized if the slope of the road is at least ~ 8 %.

So it means that if uphillcutoff=5 than slope more than ~5 will be exclude to the compute? And what means uphillcost and downhillcost?

[LupinSun]

Yes, as soon as brouter.de and bikerouter.de update the BRouter version running in the background to v1.7.0 or newer, you will no longer be able to generate the red track with this profile. If you actually prefer the red track, then you have to adjust the profile until it generates this track again.

The green one, the red was calculated with already 1.7.0 version

[quaelnix]

So it means that if uphillcutoff=5 than slope more than ~5 will be exclude to the compute?

uphillcutoff=5 means that BRouter treats roads that are less steep than 5 % as if they were flat and roads that are more steep than 5 % as if they were 5 % less steep.

Which is why uphillcutoff=1000 basically means that BRouter should treat any road as if it was flat and BRouter v1.6.3 apparently does not do that, which is why BRouter v1.6.3 is doing something wrong.

And what means uphillcost and downhillcost?

They tell BRouter how much the penalty should be per meter of change in elevation.

[LupinSun]

So it means that if uphillcutoff=5 than slope more than ~5 will be exclude to the compute?

uphillcutoff=5 means that BRouter treats roads that are less steep than 5 % as if they were flat and roads that are more steep than 5 % as if they were 5 % less steep.

Which is why uphillcutoff=1000 basically means that BRouter should treat any road as if it was flat and BRouter v1.6.3 apparently does not do that, which is why BRouter v1.6.3 is doing something wrong.

So if i want more slope do I put this value near 0?

[quaelnix]

If you want to maximize the slope, you need to trick the system as follows:

---context:global

# Disable the elevation penalty
assign downhillcost         = 0
assign downhillcutoff       = 0
assign uphillcost           = 0
assign uphillcutoff         = 0

---context:way

assign costfactor = ...

# Penalize flat ways three times as much
assign uphillcostfactor    costfactor
assign downhillcostfactor  costfactor
assign costfactor multiply costfactor 3

Example profile: https://paste.rs/ZDgYe

[LupinSun]

If you want to maximize the slope, you need to trick the system as follows:

---context:global

# Disable the elevation penalty
assign downhillcost         = 0
assign downhillcutoff       = 0
assign uphillcost           = 0
assign uphillcutoff         = 0

---context:way

assign costfactor = ...

# Penalize flat ways three times as much
assign uphillcostfactor    costfactor
assign downhillcostfactor  costfactor
assign costfactor multiply costfactor 3

Example profile: https://paste.rs/ZDgYe

Ok, thanks, I try to simulate on Brouter-web and as soon as possible I try to ride with this profile! thank you so much for now!

[quaelnix]

You can use this instance of BRouter-Web for testing, it is using v1.7.0: http://148.251.191.149/brouter-web/#map=12/39.9134/8.6160/standard

[LupinSun]

You can use this instance of BRouter-Web for testing, it is using v1.7.0: http://148.251.191.149/brouter-web/#map=12/39.9134/8.6160/standard

great thanks, I wanted to ask you something that has nothing to do with this problem but I can't send you a private message. The profiles that I find on the various sites (bikerouter, brouter-web) compute the route without considering one-way streets, isn't it dangerous especially in the city? for example gravel m11n, or yours.

[quaelnix]

My profile increases the cost of one-way streets by a factor of 5:

assign onewaypenalty
    switch or ( not badoneway ) ( or cycleway=... )  1
    switch not junction=roundabout                   5
                                                    20
...
assign costfactor
    ...
    multiply onewaypenalty

Assuming that you are pushing your bike according to the traffic regulations.

[poutnikl]

It seems this link may be helpful for beginner profile developers/testers:

https://github.com/poutnikl/Brouter-profiles/wiki/Glossary

[LupinSun]

My profile increases the cost of one-way streets by a factor of 5:

assign onewaypenalty
    switch or ( not badoneway ) ( or cycleway=... )  1
    switch not junction=roundabout                   5
                                                    20
...
assign costfactor
    ...
    multiply onewaypenalty

Assuming that you are pushing your bike according to the traffic regulations.

your profile is misbehaving, look here for example: https://brouter.m11n.de/#map=18/39.90331/8.60167/standard&lonlats=8.601378,39.902198;8.59943,39.902568

[LupinSun]

It seems this link may be helpful for beginner profile developers/testers:

https://github.com/poutnikl/Brouter-profiles/wiki/Glossary

thanks, I hope one day to be able to build myself a profile, but for now I'm a simple user

[quaelnix]

your profile is misbehaving, look here for example:

No, it does what it is supposed to do. It concludes that ~ 90 meters of pushing is better than ~ 662 m of driving.

---

If you change line 60 to:

switch not junction=roundabout                   11

it will no longer route against the one-way street in this example. And if change it to 9999 (or higher):

switch not junction=roundabout                   9999

it will never route against the allowed direction of travel, no matter how long the next best alternative route is.

[zossebart]

As the original author of the profile in question, I was curious about the issue.

First, some more info: @LupinSun contacted me via Locus Forum private Message 3 years ago , he used my mtb profile for enduro motorcycling, but needed some adaptions for his usecase. So I adapted it over some iterations for him. You can also find it here: https://github.com/zossebart/brouter-misc/blob/master/enduro-mc.brf. The version that was uploaded here seems to be this slightly older commit: https://github.com/zossebart/brouter-misc/blob/fb48c8b9c49d00c2a6828341e61bde8a84e8eef3/enduro-mc.brf.

However, I'm not able to reproduce the issue. I have an old instance (1.6.1) of brouter running on my homeserver and this also calculates the "wrong" route. My data files are from 4th of june, though. So maybe it has something to do with the map data?

@LupinSun what, exactly do you consider "wrong" with the red route? Or is it simply the fact that it's calculated different than before?

[LupinSun]

your profile is misbehaving, look here for example:

No, it does what it is supposed to do. It concludes that ~ 90 meters of pushing is better than ~ 662 m of driving.

If you change line 60 to:

switch not junction=roundabout                   11

it will no longer route against the one-way street in this example. And if change it to 9999 (or higher):

switch not junction=roundabout                   9999

it will never route against the allowed direction of travel, no matter how long the next best alternative route is.

ok, as a beginner I don't quite understand all the parameters, or how to modify them, thank you very much, I will try this modification you suggested

[quaelnix]

I have an old instance (1.6.1) of brouter running on my homeserver and this also calculates the "wrong" route.

It's possible that the bug that causes the calculation of the "correct" route, was introduced after the release of v1.6.1.

[LupinSun]

As the original author of the profile in question, I was curious about the issue.

First, some more info: @LupinSun contacted me via Locus Forum private Message 3 years ago , he used my mtb profile for enduro motorcycling, but needed some adaptions for his usecase. So I adapted it over some iterations for him. You can also find it here: https://github.com/zossebart/brouter-misc/blob/master/enduro-mc.brf. The version that was uploaded here seems to be this slightly older commit: https://github.com/zossebart/brouter-misc/blob/fb48c8b9c49d00c2a6828341e61bde8a84e8eef3/enduro-mc.brf.

Exact, not having the necessary skills to create a new profile, I asked zossebart if he could help me adjust his profile which of all those found is the one that comes closest to the calculations and routes we do with the enduro bike, the least asphalt as possible and as few flat areas as possible, then I tried to modify some parameters, but as seen in the latest version, they are numbers that I entered without knowing exactly what they were doing, but they suited my needs well. Zossebart was very kind and then modified his profile to suit enduro riding

However, I'm not able to reproduce the issue. I have an old instance (1.6.1) of brouter running on my homeserver and this also calculates the "wrong" route. My data files are from 4th of june, though. So maybe it has something to do with the map data?

@LupinSun what, exactly do you consider "wrong" with the red route? Or is it simply the fact that it's calculated different than before?

yes it's just a fact that for years it has calculated that way and I thought there was a problem with the new version, but it's not!

[quaelnix]

@LupinSun, I thought about it some more and the trick I mentioned above works even better if you set both downhillcutoff and upillcutoff to a small number > 0. The optimal number depends on the quality of the elevation data in the area you're interested at. Once we switch from SRTM to LiDAR this trick will work even better.

[0709wiwiwi]

@quaelnix @zossebart

I don't study profiles, mainly use the trekking profile. Anyway I take the opportunity to ask a question now. Bike profile with trekking bike profile example. https://t.ly/k_W1Q

Situation. Driving onto trackgrade 2 and enforce follow trackgrade 4 toward a shaping(via) point The example as shown still than designs a return with an thereby associated u-turn command. For further forward routing you so need to place the shaping(via) point even a little further away. Question. Can you eventual (x2) discriminate returning (overlap) road sections after a shaping(via) point ? U-turns so still remain possible, but eventual recurring road lengths are so extra penalised. Cruiser_gpx_navtrack_shaping and forward.gpx.txt Cruiser_gpx_navtrack_shaping and return.gpx.txt

[quaelnix]

Can you eventual (x2) discriminate returning (overlap) road sections after a shaping(via) point ?

No, but you could increase the turncost penalty:

assign turncost = if is_ldcr then 0
                  else if junction=roundabout then 0
                  else 90

->

assign turncost = if is_ldcr then 0
                  else if junction=roundabout then 0
                  else 300

and at the same time abolish the special treatment of cycle routes (and roundabouts):

assign turncost 300

[LupinSun]

@LupinSun, I thought about it some more and the trick I mentioned above works even better if you set both downhillcutoff and upillcutoff to a small number > 0. The optimal number depends on the quality of the elevation data in the area you're interested at. Once we switch from SRTM to LiDAR this trick will work even better.

I live in Sardinia and this is where I use Locus, thanks a lot I will try to do some simulations and see if the results are better for me. anyway thanks to you, zossebart, poutnikl I'm perfecting that profile (in one I started removing several parameters that I discovered weren't interesting for me, like low/high speed limit etc etc ), if you have any other suggestions I'll gladly listen to you

[quaelnix]

@LupinSun, I don't know enough about enduro motorcycling to make any suggestions without being shown specific examples of where the profile is currently not making a good choice. If you can show me some routes the profile is currently taking and some it should be taking instead, then I could help you improve it.

[LupinSun]

@LupinSun, I don't know enough about enduro motorcycling to make any suggestions without being shown specific examples of where the profile is currently not making a good choice. If you can show me some routes the profile is currently taking and some it should be taking instead, then I could help you improve it.

The profile I reported is already fine, I'm now trying to exclude all the gates to the compute, but I can't find the right code to add

[quaelnix]

---context:node

assign gatepenalty switch barrier=gate|lift_gate|swing_gate 1000000 0

assign initialcost
    add gatepenalty
    ...

But you probably only want to exclude closed gates, which is more difficult.

[LupinSun]

---context:node

assign gatepenalty switch barrier=gate|lift_gate|swing_gate 1000000 0

assign initialcost
    add gatepenalty
    ...

I added a lot of "if then else" :-D, but finally got around to it

But you probably only want to exclude closed gates, which is more difficult.

no, I want to exclude them all, here in some areas, between untying and tying the rope/string especially "kissing_gates" you waste a lot of time, consider that you could also find dozens within a radius of one km that make you waste a lot of time added together

[quaelnix]

This query should return all gates including the bastards: https://overpass-turbo.eu/s/1w7I

In case you want to test your new profile against them. ^^

[LupinSun]

This query should return all gates including the bastards: https://overpass-turbo.eu/s/1w7I

In case you want to test your new profile against them. ^^

thanks a lot, but I have already included this feature on Brouter-web :-D,

---context: node

assign gatepenalty switch barrier=gate|lift_gate|swing_gate 1000000 0

assign initialcost
    add gatepenalty
    ...

My "if then else" and your code not do correct compute, I think the problem is due to the code that is written later about access controls for motorcycle

[LupinSun]

@zossebart @quaelnix I have a problem with the profile (edited by me) with paths and sometimes with gates (no gate), look at this route http://148.251.191.149/brouter-web/#map=13/39.9172/8.9064/standard&lonlats=8.607155,39.902996;9.052058,40.105912&nogos=8.786316,39.966098,89;8.779922,39.984818,188;8.923312,39.904684,25;8.923774,39.903358,27;8.946991,39.893587,37;8.891008,39.949871,93 why even though the "avoid_steps" value is 10000, the path crosses a path? sometimes it even calculates crossing gates, despite the no_gate flag! attached the brf profile enduro v4.zip or here https://github.com/LupinSun/Enduro/blob/main/Enduro.brf

[quaelnix]

thanks a lot, but I have already included this feature on Brouter-web :-D,

You can also add the Overpass query as an overlay on BRouter-Web, which is very useful when testing changes to the profile:

[quaelnix]

My "if then else" and your code not do correct compute

Because you added them inside of an if then else branch that only matches nodes without any access tag.

Try this (and learn the syntax): https://paste.rs/MuPqS

why even though the "avoid_steps" value is 10000, the path crosses a path?

The steps penalty in this profile is done in a pretty weird way, which is why 10000 is not enough to block the usage of steps completely.

[LupinSun]

thanks a lot, but I have already included this feature on Brouter-web :-D,

You can also add the Overpass query as an overlay on BRouter-Web, which is very useful when testing changes to the profile:

Exactly, I did that for gates

[LupinSun]

Because you added them inside of an if then else branch that only matches nodes without any access tag.

Try this (and learn the syntax): https://paste.rs/MuPqS

this seems to work fine, before the syntax I have to learn to program, I don't even know what programming language this is :-D

The steps penalty in this profile is done in a pretty weird way, which is why 10000 is not enough to block the usage of steps completely.

yes in fact I tried to use values ​​much higher than 10000 but to no avail, unfortunately I'm not a programmer, I know some vbasic commands to use in excel, nothing more, that's why I asked for help

[quaelnix]

I don't even know what programming language this is :-D

None at all. ;)

yes in fact I tried to use values ​​much higher than 10000 but to no avail

Steps be gone: https://paste.rs/Ed4jL

[LupinSun]

this seems to work fine, before the syntax I have to learn to program, I don't even know what programming language this is :-D

I have to correct this answer, the profile works fine, but it doesn't do everything it did before: there's a setting to flag (Uknown_Gate) that doesn't work that excludes all gates that are "Unknown", i.e. all those gates that don't have a specific tag for the motorcycle or the motor vehicle. in this way a route with fewer unexpected events is calculated

[quaelnix]

@LupinSun this will bring back the "Unknown" logic: https://paste.rs/gAo6b

[LupinSun]

Steps be gone: https://paste.rs/Ed4jL

Sorry but no, it doesn't work, crossing steps are still computed check for yourself: http://148.251.191.149/brouter-web/#map=12/39.9155/8.8543/standard&lonlats=8.607155,39.902889;9.056611,40.105124&nogos=8.786122,39.965857,140;8.785736,39.984408,404;8.923791,39.903344,31;8.923373,39.904612,41;8.894314,39.949639,61

[LupinSun]

@LupinSun this will bring back the "Unknown" logic: https://paste.rs/gAo6b

this works fine thanks, But I don't want to take too much advantage of your kindness

[quaelnix]

check for yourself

The route does not contain any segment with highway=steps. Can you please give a minimal example where it fails?

crossing steps are still computed

What do you mean when you say "crossing steps".

[quaelnix]

But I don't want to take too much advantage of your kindness

No worries, just look at the changes I made to the profile and then try to understand why it now works the way you wanted it to. And I would highly recommend that you work with the shortest possible routes that contain the issue your're currently looking it. Makes life way easier.

[LupinSun]

What do you mean when you say "crossing steps".

Sorry, You are right, there is a misunderstanding, I mean highway=path, not steps, steps must always be avoid or at most a flag like for paths

[LupinSun]

But I don't want to take too much advantage of your kindness

No worries, just look at the changes I made to the profile and then try to understand why it now works the way you wanted it to. And I would highly recommend that you work with the shortest possible routes that contain the issue your're currently looking it. Makes life way easier.

i.e. simulate short paths where could the problem arise?

[quaelnix]

I mean highway=path, not steps, steps must always be avoid

No more highway=path and no more highway=steps : https://paste.rs/ZWNj9

i.e. simulate short paths where could the problem arise?

No, just place the start and end markers in the vicinity of a problematic area and then adjust the profile until it does what you want: http://148.251.191.149/brouter-web/#map=17/39.90266/8.92387/standard&lonlats=8.922822,39.903981;8.924369,39.904744&nogos=8.923778,39.903393,19;8.92336,39.904686,22

[LupinSun]

I mean highway=path, not steps, steps must always be avoid

No more highway=path and no more highway=steps : https://paste.rs/ZWNj9

i.e. simulate short paths where could the problem arise?

No, just place the start and end markers in the vicinity of a problematic area and then adjust the profile until it does what you want: http://148.251.191.149/brouter-web/#map=17/39.90266/8.92387/standard&lonlats=8.922822,39.903981;8.924369,39.904744&nogos=8.923778,39.903393,19;8.92336,39.904686,22

No_Gate still giving me problems http://148.251.191.149/brouter-web/#map=18/39.56199/9.44029/standard,viewpoint&lonlats=9.439374,39.562137;9.440291,39.562625