Avoiding yield/stop signs

[Zonarius]

First of all, great work with this router. I use it all the time and I have fun with fine-tuning my profile.

Is there a way to add additional node costs for yield/stop signs? It must account for the direction of the sign and the direction of the route. I believe just adding a cost for highway=give_way or highway=stop will add the cost even if the sign is facing away.

[poutnikl]

Hi, these signs have the qualifier direction=forward|backward|both which can be used with direction of road. OSM ways are oriented in OSM and BRouter injects the internal tag reversedirection=yes if the routing and the mapping directions of the ways are opposite )

So one can set in the global context:

assign stop_penalty  =  A
assign give_way_penalty = B

In the way context:

assign isreversed = reversedirection=yes

which is forwarded to node context as way:isreversed

In node context:

assign initialcost
( chain evaluations )
else if highway=stop then
( if or ( and not way:isreversed direction=forward|both ) 
      ( and way:isreversed  direction=backward|both ) then stop_penalty  else 0
)
else if highway=give_way then
( if or (and not way:isreversed direction=forward|both ) 
      (  and way:isreversed  direction=backward|both ) then give_way_penalty  else 0
)
else if ( chain evaluations )

Note that I currently do not use it in my bike profiles, addressing it by alternative way via progressively increasing initial way cost for main roads.

[poutnikl]

There is another thing to consider:

Is well justified discrimination of crossings with explicitly mapped traffic signs, compared to those with real but not mapped signs ? As there is e.g. almost twice as much mapped stop signs, compared to give_way signs, but reality is very opposite.

Aside of that, limitation by giving way/stopping is much bigger deal for cars than bikes.

[philippguertler]

Thank you! I did not know about the reversedirection node property. Now I can add that to my profile.

Yes, I am aware that there are hardly any mapped give_way signs, but I can add them myself to OSM on my frequent routes to try out other routes in the future.

[poutnikl]

Thank you! I did not know about the reversedirection node property. Now I can add that to my profile.

@philippguertler Note that reversedirection is a way property , not a node property.

Well, it is not even a true way property. It is not an OSM tag, but this pseudotag is generated by BRouter during routing calculation. That is why its value has to be assigned to a way context variable and forwarded then from the way context to node context. Then it can be evaluated with the node property tag direction=*

[FFMbyBicycle]

So one can set in the global context:

set stop_penalty  =  A
set give_way_penalty = B

In the way context:

Set isreversed = reversedirection=yes

which is forwarded to node context as way:isreversed

In node context:

set initialcost
( chain evaluations )
else if highway=stop then
( if or ( and way:isreversed=false direction=forward|both ) 
      ( and way:isreversed=true  direction=backward|both ) then stop_penalty  else 0
)
else if highway=give_way then
( if or (and way:isreversed=false direction=forward|both ) 
      (  and way:isreversed=true  direction=backward|both ) then give_way_penalty  else 0
)
else if ( chain evaluations )

Thank you for showing this hidden trick and sorry for commenting at such an old issue, but I just ran into the same problem and I'm unable to get your solution working.

"set" is an unavailable command (only "assign" is allowed), but even when I use "assign" at way context there is no lookup name "way" available at node context. Is there some other hidden feature is this a problem with my profile...? It would be really nice if we could get this working! I'm able to use "reversedirection=yes" at way context for avoiding oneway streets in the wrong direction.

I'm trying to add this feature to my long distance cycling profile

[poutnikl]

@FFMbyBicycle You are right, assign, not set.

I have also used incorrectly way:is_ldcr=false. Not sure what I was thinking about then, probably a weird subconscious idea "If there is a colon, it must be a lookups value", while it is a normal variable. :-)

I have just tried insertion of the following code to the standard trekking profile on brouter.de/brouter-web/ , just to verify the feature, and it works:

---context:node # following code refers to node tags

assign nodeis_ldcr = way:is_ldcr

I have fixed the code above, check if it or the idea behind works for you.

[FFMbyBicycle]

Thanks a lot, now it is working and I learned a lot! I don't know what I made wrong in the first place, but now it is fine and part of my profile

I just added the case where the sign direction is unknown. Just in case...