Android Brouter app 1.7.0 do not calculate the right route about brouter HOT 63 OPEN

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

from brouter.

@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

from brouter.

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

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

from brouter.

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

from brouter.

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

from brouter.

I

You either need to uncheck the Unknown_Gate thing or change the "unknown gate logic" in line 308 until it matches your expectation.

maybe because the gates has the tag motorcycle=yes?

No, it falls into the "unknown category" because it does not have an access tag.

ok, very clear, now I understand how it works

from brouter.

This should do what you want: https://paste.rs/DmQ4n, but it will still fail on the last example, because you modified the tags on this gate: https://www.openstreetmap.org/node/10936600030/history, two days ago, just after the rd5 data has been updated on the test server for the last time.

Ok I understand, I never considered the data date, my fault, I thought that data after one day are updated.
In any case, it is not computed well, I changed the zone in order to have an older date, but the compute is wrong, in fact I don't understand it at all, No_Gate works correctly, while unknown_gate behaves in a strange way. Look here, I searched for two other nearby gates in another area with older data date
http://148.251.191.149/brouter-web/#map=15/39.7438/8.6963/standard&lonlats=8.690793,39.745474;8.689628,39.747153

from brouter.

Guess I had a bad day.

I'm sorry

... switch ( and Unknown_Gate motorcycle=yes ) 1000000 0

->

... switch ( and not Unknown_Gate not motorcycle=yes ) 1000000 0

problem gone: https://paste.rs/PsEaJ

😊

But I think you should consider a different approach (see: https://paste.rs/xazBM): to avoid any further confusion. ;-)

That would have been the next step, but I wasn't going to ask you for help. so thank you, you went further, you read my mind
☺️
if you come on holiday in Sardinia, I will be happy to meet you and offer you beer and pizza 🍻

from brouter.

From all registered OSM surface=* tagvalues, only those listed in lookups.dat file at brouter.de are allowed - see below.

Numbers are AFAIK occurances in Germany tiles. With several tagvalues, all are encoded as the first one.

surface;0002497676 asphalt
surface;0001568957 paved
surface;0001562253 unpaved
surface;0000727427 gravel
surface;0000560191 ground
surface;0000350378 dirt
surface;0000237226 grass
surface;0000212587 concrete concrete:plates concrete:lanes
surface;0000188743 paving_stones paving_stones:30 paving_stones:20
surface;0000113800 cobblestone cobblestone:flattened
surface;0000093164 compacted
surface;0000091171 sand dirt/sand
surface;0000023293 wood
surface;0000019915 pebblestone
surface;0000012866 fine_gravel
surface;0000010681 earth
surface;0000007331 sett
surface;0000005778 mud
surface;0000004549 grass_paver
surface;0000004398 clay
surface;0000003760 metal

from brouter.

@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

from brouter.

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

from brouter.

@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

from brouter.

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

from brouter.

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

from brouter.

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.

from brouter.

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?

from brouter.

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.

from brouter.

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?

from brouter.

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

from brouter.

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!

from brouter.

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

from brouter.

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.

from brouter.

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.

from brouter.

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

from brouter.

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

from brouter.

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.

from brouter.

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?

from brouter.

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

from brouter.

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.

from brouter.

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!

from brouter.

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

from brouter.

@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

from brouter.

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

from brouter.

@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

from brouter.

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

from brouter.

@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

from brouter.

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

from brouter.

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

from brouter.

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

from brouter.

@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

from brouter.

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:

from brouter.

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.

from brouter.

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

from brouter.

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

from brouter.

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

from brouter.

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

from brouter.

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

from brouter.

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

from brouter.

@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

from brouter.

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

from brouter.

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.

from brouter.

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

from brouter.

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?

from brouter.

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

from brouter.

@LupinSun, my fault, I did not add enough zeros in line 308:

Technically, values >= 10000 for a (way-)costfactor, and >= 1000000 for a nodes "initalcost" are treated as infinity, so please use these as the "forbidden" values.

assign gatepenalty switch and access= Unknown_Gate 0 100000

needs to be:

assign gatepenalty switch and access= Unknown_Gate 0 1000000

from brouter.

assign gatepenalty switch and access= Unknown_Gate 0 1000000

I had already assigned this value and even higher ones but the route keeps going through this gate, maybe because the gates has the tag motorcycle=yes?

from brouter.

You either need to uncheck the Unknown_Gate thing or change the "unknown gate logic" in line 308 until it matches your expectation.

maybe because the gates has the tag motorcycle=yes?

No, it falls into the "unknown category" because it does not have an access tag.

from brouter.

You either need to uncheck the Unknown_Gate thing or change the "unknown gate logic" in line 308 until it matches your expectation.

maybe because the gates has the tag motorcycle=yes?

No, it falls into the "unknown category" because it does not have an access tag.

Unfortunately I could never wanted writing to you again but unfortunately some tick still don't work as they should. When I select Unknown_Gate, the calculated route could pass through all those gates that do not have the specific "motorcycle=yes" tag, while when I untick, it must not pass through all those gates that do not have the specific "motorcycle=yes" tag, but at the same time the route could pass through all those gates where "motorcycle=yes" is present, while if I tick No_Gate, the route, regardless of the type of tag, must not be able to pass through any gate.
Obviously I've already tried to make some changes before writing to you but I can't solve it definitively. look at these two gates, one does not have the motorcycle tag but a generic motor_vehicle (the one at the start), while the other at the end has the specific motorcycle=yes tag. Saddly in this profile it doesn't happen, the route have no changes if I untick Unknown_gate, the gate at the start must be "jump" if I untick, and the one at the end unchanged: http://148.251.191.149/brouter-web/#map=17/40.08722/9.03471/standard&lonlats=9.056783,40.058241;9.035198,40.087822

from brouter.

This should do what you want: https://paste.rs/DmQ4n, but it will still fail on the last example, because you modified the tags on this gate: https://www.openstreetmap.org/node/10936600030/history, two days ago, just after the rd5 data has been updated on the test server for the last time.

from brouter.

Guess I had a bad day.

... switch ( and Unknown_Gate motorcycle=yes ) 1000000 0

->

... switch ( and not Unknown_Gate not motorcycle=yes ) 1000000 0

problem gone: https://paste.rs/PsEaJ

But I think you should consider a different approach (see: https://paste.rs/xazBM):

to avoid any further confusion. ;-)

from brouter.

@quaelnix @zossebart @0709wiwiwi @poutnikl
I need your help again, I don't know if this can be fixed though.
If I add the rock or rocks or rocky value to the key "surface" brouter by error see attachment, yet in osm it exists, even if it is little used, while other values ​​such as unpaved or dirt are ok

from brouter.

@LupinSun, surface=rock will be supported once #458 is merged:

surface;0000000001 rock rocks rocky

from brouter.

@LupinSun, surface=rock will be supported once #458 is merged:

surface;0000000001 rock rocks rocky

Very well, thank you

from brouter.