Applying way tag bicycle=use_sidepath

[poutnikl]

Th way tagvalue bicycle=use_sidepath has very minor usage, near 0.04% in Germany, according to lookup.dat. But its wide world usage is cca 1.2% according to OSM bicycle=* taginfo

IMHO, standard bicycle profiles should give a penalty for roads with bicycle=use_sidepath to push the routing on the sidepath.

[AllroadsNL]

This is also for mofa=use_sidepath and moped=use_sidepath and foot=use_sidepath

In the Netherlands, we now have a preset part for use_sidepath, more and more is tagged.

To control routing, moped routing must be set right.

And there is also the tag *:forward *:backward, which is very important, for all.
Here on one side is a oneway a cycleway used by moped:designated mofa:yes foot must use cycleway in both directions,
On the other side a cycle:left=lane
Tags
bicycle:forward=use_sidepath
foot=use_sidepath
mofa:forward=use_sidepath
moped:forward=use_sidepath

routing situation

Maybe also a other problem, in the Netherlands we have many cycleway traffic_sign NL:G12a with moped=designated compulsory. Does Brouter take designated with moped.

Many traffic sign access tags also use forward backward.

[poutnikl]

As mentioned in #85, moped[:*]=* nor mofa[:*]=* tags are not yet considered in BRouter data files, so for now, profiles cannot use them.

[AllroadsNL]

Hope, they will be soon!

[Phyks]

It seems that if bicycle=use_sidepath is used, then isbike is false (https://github.com/abrensch/brouter/blob/master/misc/profiles2/trekking.brf#L55) and then the way has a higher penalty. So it should actually already be pushing the route to the side path, isn't it?

[polyscias]

Found out today that without support for "bicycle=use_sidepath" routing with traffic_lights in NL often has brouter chose the normal way instead of the cycleway for crossings with separate bicycle paths and separate bicycle traffic lights

That makes sense because that way no single traffic light is passed and a slightly higher cost for the normal road will not help because the distances are short while the "distance for a traffic light" can be considerable.

Meanwhile the world wide usage has gone up to 2.26% but looking in my neighborhood I see more ways tagged using "bicycle=use_sidepath" then "bicycle=no".

For NL this is also "official policy", see https://wiki.openstreetmap.org/wiki/NL:The_Netherlands_roads_tagging under "Verplicht Fietspad":

Seperate cycle path, also for mopeds and mopeds. Cyclists, light-moped riders and moped riders are not allowed to ride on an adjacent roadway, except for bicycles and mopeds with more than two wheels that, including the load, are wider than 0.75 meters. These wide (moped) bicycles may use the adjacent roadway (RVV 1990: Article 5 (4) and Article 6 (3)). The adjacent roadway is therefore bicycle = use_sidepath and moped = use_sidepath. Pedestrians are not allowed to walk on an adjacent roadway.

[polyscias]

Created PR #191 - Handle bicycle=use_sidepath the same as bicycle=no

[AllroadsNL]

I tried to reproduce the route.
But I could not get the same. Tried more profiles, tried reserve route.
When I looked at your picture, I see the oneway=yes on cycleway is ignored. Also in reverse, then road

[polyscias]

I think oneway=yes is not ignored but the costs of that part are low as the trekking profile assumes that you may walk that part.

To reproduce the results it is essential to have traffic lights added to the initialcost, I replaced the last three lines of the trekking profile by this piece of code from the vm-forum-liegerad-schnell profile:

assign initialcost
 add switch highway=traffic_signals 200 # Kosten für Ampel
  switch highway=stop 150 # Kosten für Stoppschild
  switch railway=crossing|level_crossing 200 # Kosten für Bahnübergang
  0
 switch bikeaccess
  0
 switch footaccess
  10000 # Kosten fürs Absteigen
 1000000 #Kosten für verbotene oder private Wege

[Phyks]

Hi,

I don't get

That makes sense because that way no single traffic light is passed and a slightly higher cost for the normal road will not help because the distances are short while the "distance for a traffic light" can be considerable.

If the bike following the cycle lanes has some traffic signals penalties, there should be traffic lights penalties for the highways as well, isn't it? (probably missing from OSM data, I don't see them on your screenshot).

Having traffic light penalties is tempting (and I gave it a try in the past), but in the end it does not change much the resulting routes in my experience. Traffic lights are quite homogeneously distributed within a city and it only affects corner cases, some in a good way and some in a bad way (and finding the correct penalty threshold can be quite difficult).

Here is an example where it works well for instance:

http://brouter.de/brouter-web/#map=19/48.84303/2.37046/standard,Waymarked_Trails-Cycling&lonlats=2.369804,48.843027;2.371835,48.841909 vs https://brouter.phyks.me/#map=19/48.84280/2.37076/standard,Waymarked_Trails-Cycling&lonlats=2.369804,48.843027;2.371835,48.841909 with a traffic signal penalty of 50 (https://github.com/Phyks/brouter/blob/phyks/misc/profiles2/phyks-trekking.brf#L437-L439).

More than 100 for the penalty seems to be way too much in my experience.

[polyscias]

If the bike following the cycle lanes has some traffic signals penalties, there should be traffic lights penalties for the highways as well, isn't it? (probably missing from OSM data, I don't see them on your screenshot).

No the crossing is mapped correctly AFAIK, see the link @AllroadsNL provided for the exact location.

For me, having traffic light penalties is essential to have brouter make the route decisions I also made optimizing my commute. On the cost, if a traffic light takes 30 seconds on average and you cycle 20 km/h, the cost should be 167 meter. What is the reason you think the cost should be less than 100?

I see your point that without traffic lights brouter makes also without high penalties for "bicycle=use_sidepath" the right choice as the cost for a cycleway is lower than unclassified/secondary/tertiary/primary, so yes, this problem is specific for traffic lights.

@abrensch

Applying the same for use_sidepath would cut many connections.

Good point.

Would be good to see some examples where handling use_sidepath as no would give problems.
Tag:bicycle=use_sidepath gives a hint:

Please do not use bicycle=use_sidepath in combination with cycleway=track on the main highway, if there is no separate cycleway drawn on the map. This is confusing for routing engines

But if this is the (only) problem, a rule could handle that.

[Phyks]

No the crossing is mapped correctly AFAIK, see the link @AllroadsNL provided for the exact location.

If you follow the current BRouter route (although the place seems to have been recently significantly modified) or the one from

the resulting number of red lights should be the same. You should cross 4 times, meaning you should have four times the red light penalty (except when they are synced).

If you follow the bike lanes, you pass two traffic signals (the remaining two are in sync with them, no penalty should be contributed, this is fine). If you follow the route taking into account traffic signal, you find a route with a net result of only one traffic signal (because traffic signal is mapped for cars on the highway, not for pedestrian and the pedestrian routing over the main highways misses them). This is, in my opinion, an issue with mapping the real location of traffic signals in OSM and not having a traffic signal node at the crossing (this is however a perfectly valid OSM tagging, see the wiki). Not sure what would be the best tagging to fix this, but this is still a tagging issue in my opinion, and it will be really difficult for the router to infer pedestrian crossing penalties here.

On the cost, if a traffic light takes 30 seconds on average and you cycle 20 km/h, the cost should be 167 meter. What is the reason you think the cost should be less than 100?

This is purely empirical :)

[AllroadsNL]

(although the place seems to have been recently significantly modified)

I did that, but the part of oneway=yes on this cycleway did not change.

the way change
not used a realation restriction but a way change with oneway=yes (which was already there) matching the traffic_islands.

It was not allowed by car to go through from right to left.
So I had to change it.
This means that it is not possible to take this route by bicycle, anymore.

[polyscias]

The crossing is non-typical after the updates from @AllroadsNL and currently the routing data seems not to be up-to-date yet, so switched to the next crossing with traffic signals to the east. Also still with the changes to the trekking profile as documented above (replaced the last three lines of the trekking profile by the code for the initialcost of the vm-forum-liegerad-schnell profile that includes traffic lights). Then I get:

So a similar problem because the traffic light costs and no costs for bicycle=use_sidepath

@Phyks: I think I understand why you say:

If you follow the current BRouter route (although the place seems to have been recently significantly modified) or the one from the resulting number of red lights should be the same. You should cross 4 times, meaning you should have four times the red light penalty (except when they are synced).

But that is not how I see it, the traffic lights on the OSM map are places where the stop line is, if you are not passing such a line, i.e. a highway-traffic_signals node there is no traffic light and no cost in Brouter.

I think there is agreement that ways with "bicycle=use_sidepath" should get higher costs in bicycle profiles or I am wrong? Next question would then be what would be the appropriate method if following "bicycle=no" is seen as too strict.

[polyscias]

Some data on "bicycle=use_sidepath".
Currently 103 705 times used on ways of which:

• 3 211 times, 3.09% in combination with cycleway:right=*
• 2 509 times, 2.42% in combination with cycleway=*
• 1 140 times, 1.10% in combination with cycleway:left=*

That is what the wiki is warning about:

Please do not use bicycle=use_sidepath in combination with cycleway=track on the main highway, if there is no separate cycleway drawn on the map. This is confusing for routing engines because bicycle=use_sidepath indicates not to route on the main highway (use the separate cycleway) and this conflicts with the tag cycleway=track, which indicates that bicycles are allowed to route on (bike lanes connected to) the main highway.

Had a look at 15 of these cases and most of the times this is a "normal", i.e. car way with "bicycle=use_sidepath" and "bicycle*=*" with a cycleway along it, so the bicycle*=lane/track should be removed (or the cycleway) while bicycle=use_sidepath should remain on the normal way.

[AllroadsNL]

Then I get:

This is strange, there is a bicycle=no (with wrong name) on the Straatwegstraat (Bergweg), red circle.
Brouter ignore totally a bicycle=no. This must always be used and do not route over it.

There should be a oneway=yes at the blue circle, this must also not be ignored.
As a tagger I expect a routing engine to do so.

Ofcourse the traffic_light is the problem. It makes it more strange that it overrules a bicycle=no
@polyscias I see it exactly the same, traffic_signal on stop position on the cycleway, is correct.
de route as described have not such traffic_signal on the road.

I leave this situation as it is.

[Phyks]

Brouter ignore totally a bicycle=no. This must always be used and do not route over it.

This is however needed in some cases. What about a highway=footway + bicycle=no? This is perfectly routable with a bike but should be penalized because you have to dismount and walk.

I think there is agreement that ways with "bicycle=use_sidepath" should get higher costs in bicycle profiles or I am wrong?

So far, I'd agree that bicycle=use_sidepath. I however disagree that it will solve the underlying traffic lights penalty issue. It will probably solve it in this particular case but it is only a matter of ratio of traffic lights vs distance travelled on a bicycle=use_sidepath to make the traffic light issue appear again.

[AllroadsNL]

This is however needed in some cases. What about a highway=footway + bicycle=no? This is perfectly routable with a bike but should be penalized because you have to dismount and walk.

For that case we have the tag bicycle=dismount, often used in routes on a way.

bicycle=no and a highway=footway, means you can not walk with a bike on your hands.

laws, traffic_signs, often prohibition the vehicle, in this case the bike (bicycle) not the transportation method, the cycling.

[Phyks]

@AllroadsNL I definitely agree with your definition of bicycle values. This has the extra advantage of being consistent with what an highway=elevator + bicycle=no is for instance.

This is however not the most common usage out there and too often, bicycle=no is confused with bicycle=dismount, even by experienced users. For instance, there is no reason why it should be forbidden to walk alongside a bike in https://www.openstreetmap.org/way/703167366 (but riding it is likely forbidden).

This is probably also emphasized by the default access restrictions https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#Default where a highway=footway or a highway=pedestrian should be considered as bicycle=no (and not bicycle=dismount) by default.

EDIT:

laws, traffic_signs, often prohibition the vehicle, in this case the bike (bicycle) not the transportation method, the cycling.

I don't agree on this one, laws prohibite usually the transportation method (by default). Typical example, in France (and in many other places probably), you cannot ride a motorbike or a cycle on a sidewalk. You can however dismount and push it on the sidewalk as you are then considered a pedestrian.

[poutnikl]

In Czech Republic, a biker leading a bicycle is considered as being a pedestrian.

[AllroadsNL]

In Czech Republic, a biker leading a bicycle is considered as being a pedestrian.

This is exactly the same in the Netherlands, by lawrule, biker leading a bicycle must follow the rules of a pedestrian. RVV art 2.2 also mofa, moped, motorcycle.

The difference between rule rules and traffic_sign rules.

But it is possible that a bicycle (the vehicle) is not allowed in a pedestrian zone. Traffic_sign with undersign "Fietsen verboden" (the vehicle, bicycle prohibited), Then you must use bicycle=no. This could be on public ground but also on privat, (permissive) ground. Walking, not with a bike.

being consistent

This is important.

Now back on topic, the traffic_light problem.

[poutnikl]

Hm, but in very most cases, bicycle=no is used effectively in sense of bicycle=dismount, not in in sense No bicycles here.

[polyscias]

The thing I like a lot of Brouter Web is that it can give the details on the costs.

The costs of the crossing Bergweg-Gordelweg both with traffic lights costs but the first forced to the normal route via the cycle paths and the second one as pictured above:

So the cost of the section with bicycle=no is only 125, less than that of a traffic light.

I am surprised to see the cost of "bicycle=no" is only five times that of a normal road.

If those cost were for "bicycle=use_sidepath" (leaving out those with cycleway*=lane/track/shared_lane/*) it would make more sense.

[poutnikl]

@polyscias 5x cost for bicycle=no is used, because for near all cases, it means riding is forbidden, pushing is allowed ( if pedestrians are allowed, i.e. no motorways ) and cost is based on comparing riding versus pushing time.

Particular suitable value is questionable. I have seen 5-8.

In my experience, bicycle=dismount is used very rarely, mostly if there is an explicit request to do it, in agreement with OSM intention for short way segments only, like e.g. narrow bridges, passes, collision danger etc.

use_sidepath should use less cost penalty, as it is not a strict NO riding, in case the supposed sidepath is not available for whatever reason, e.g physical ones as maintenance, construction, obstacles, or logical ones as wrong sidepath mapping.

[AllroadsNL]

I like to tag savely, when I tag bicycle=no, I expect that routers, see this as black/white, as I do, do not route over it for a bicycle, also the vehicles that use use_sidepath in there profile, can not route over it.
When cost is endless, what cost tag is used there?
@polyscias thanks for the cost list.
foot=no, is also black/white, endless.
What cost is used for foot=no? The same method should be used for bicycle=no, no means no.

I make a style, and for me no is no.

What cost is used for foot=no? The same method should be used for bicycle=no, no means no.

bicycle=no is used effectively in sense of bicycle=dismount, not in in sense No bicycles here.

For me strange headtwirl, not logic to me.

but in very most cases,

When one sheep is over others follow, but is it correct?
You can guess my thoughts.

A other question: when a highway=cycleway cycleway=crossing crossing=* is used, is it then possible halfway the crossing to use the roadlane and go futher. Or do we expect that a person takes the whole crossing?
Also this from a route kind of view.

In the above Dutch example, there is no cycleway=crossing, would this effect routing when this is set?

What is the effect on the vehicle profile that use use_sidepath?

[poutnikl]

The only relevant interpretation of bicycle=no is the OSM tagging intention, not what I or you think about it. And that is clear - red/white traffic sign with a black bicycle, or legal equivalent.

The routing itself is for bikers, not bicycles. Pushing bicycle is a legal and frequent mode of bicycle transportation. Bikers may then use such profiles that either penalize it either forbide it ( CF=10000 for total ignoring, or 9999 for navigation hint consideration )

[polyscias]

As far as I see for NL the "bicycle=no" sign

implicitly also mean "foot=no" but not officially nor is it mapped that as "foot=no", see for example here in Dordrecht.

I am pretty sure that if the police sees you pushing your bike on this road they will react, if they are in their rights I do not know.

Places where only pedestrians are allowed (incl. people pushing their bike) are not marked by this sign but instead marked as "highway=footway/pedestrian"

The definitions in OSM are I think following "the rules" but I think currently the rules of the trekking profile are following the rules here too strictly, at least for NL, "bycicle=no" should also mean no walking.

This was not really a problem (or a minor problem) without the traffic light costs as alternative routes were pretty fast lower in costs. It is that with the traffic light costs these implicit rules become more important.

[polyscias]

What cost is used for foot=no?

There is a road here that has both "bicycle=no" and "foot=no" and the result is interesting:

Looks to me the cost is close to infinity.

[poutnikl]

Even better. If costfactor >= 10000, BRouter pretends the way does not exist. If it is 9999, it pretends it does not exist during route calculation, but is taken into account while generating navigation hints.

[poutnikl]

Implying bicycle=no means no walking implies too much. If there is really no walking, foot=no must be mapped as well.

[polyscias]

Implying bicycle=no means no walking implies too much.

Yes, handling "bicycle=no" so that never walking is allowed is not a good idea, but a much higher cost or handling it as "foot=no" for the combination of "bicycle=no" with a highway tag indicating a road of the car network would make perfect sense. See the list of roads in the description of the highway tag under "Roads" (these are the principal tags for the road network) and "link roads" sections.

If there is really no walking, foot=no must be mapped as well.

A pretty generic statement.

Leaving out ways that should be tagged as "use_sidepath" and roads mentioned above, can you give/find an example?

[poutnikl]

Well, playing with access rules is playing with a double-edged sword. They can save you, but you can fall on them.

One must balance tradeoffs between

• false positives - an allowed road that should be forbidden
• false negatives - a forbidden road that should be allowed.

Most users focus on the former, but there are many real cases of the latter, that do not come in their mind at the moment.

Over-restrictive access management often lead to weird routing results with strange detours. Or even to denial to create a route in extreme cases, especially for "first/last miles", or a bottleneck.

A typical case can be riding a bike within a city to/from a pedestrian only city centre. Or, there can be the only bridge with bicycle=no, with bikers forced to use the sidewalk on feet. Etc etc.

Putting aside explicit no-go traffic signs to be marked as bicycle/foot=no, there is the only road class with implicit no access : highway=motorway. And even this is not valid everywhere, I guess in US, as you would get nowhere otherwise. ( At least it was told recently by Czech travellers across US that they legally travelled on motorways in some US states.)

For trunks it may be case dependent, otherwise, together with primaries, it is just not recommended.

Denied access or too high penalties eliminate short road patches with troubled access, that could/should be taken, even if on foot. Long roads are already eliminated by their high costfactor.

Costfactors must be carefully chosen to effectively allow short patches, but to avoid long segments. 5-10 is reasonable.

If there is a 100-500 m road patch, you take it.
If there is 10 km long segment, there is hardly 50-100km long detour to take rather those 10 km.

[polyscias]

Understood, cost should be chosen carefully and where too low cost can lead to strange shortcuts, too high cost can lead to strange detours.

The problem with bicycle=use_sidepath in combination with traffic signals is more general, combining costs are over distance (cost*length) combining with the cost per node is tricky:

• the cost of the node compared to the distance cost depends on the distance and not (only) on the cost per distance
• so if the cost of a node followed by a short segment is low, it will be high if it is followed by a long segment.
• For traffic lights the alternative segments are short, so no length to accumulate the costs

Any idea on how to improve this?

About costs:

• The lower the quality of the data, the more relaxt the costs should be and vice-versa
• Some tags can/could be checked automatically, when that is done the quality is improved
• Cost should be tuned to the environment, rules can be different per country

I understand that the current idea is that bicycle=use_sidepath should have a lower cost than bicycle=no. That is okay to start with but the good thing about bicycle=use_sidepath is that you can check it automated where that is not the case for bicycle=no, so once that check is implemented and the number of errors is low, I think the cost of bicycle=use_sidepath should be actually higher than bicycle=no.

For traffic lights it might be good to switch to an "urban profile" where the assumption is made the quality of the data is good and many alternatives on short distance are available.

[poutnikl]

• the cost of the node compared to the distance cost depends on the distance and not (only) on the cost per distance
• so if the cost of a node followed by a short segment is low, it will be high if it is followed by a long segment.
• For traffic lights the alternative segments are short, so no length to accumulate the costs

I do not get the above. The node cost is absolute, it does not depend on the way length nor costfactor. Therefore, for longer ways segments, the relative node cost wrt the total way+nodes cost decreases.

There can be used basically 4 features:

• Way costfactor - addressing preferred ways
• Way initialcost - acting against frequuent way switching by increase effective costfactor of short segments
• Node initialcost
• Way specific Node initialcost ( via way:<way_context_tag>=<way_context_tag_value> ).
  One can e.g. set twice as big traffic signals node initialcost, if on a mainroad, compared to minor ways.

For bike pushing mode with explicit/implicit access foot=yes , I see as reasonable 2 cases

• inconvenient, but otherwise OK, regarding traffic and traffic rules, with costfactor near 5-8, depending on a profile

• undesired, supposed high traffic roads with unexpected bicycle occurence, with restrictive a/o unclear traffic rules, with high costfactor .e.g. 15-50, but not denying access.

[polyscias]

I do not get the above. The node cost is absolute, it does not depend on the way length nor costfactor. Therefore, for longer ways segments, the relative node cost wrt the total way+nodes cost decreases.

Yes, that is I think exactly what I meant saying "the cost of the node compared to the distance cost depends on the distance", likely I should have called it relative cost of the node.

Thanks for the list of features, took me some time to get, this is what I made of it:

• Way cost factors - what in the brouter-web Data table is called $/km
• Way initialcost - Set for things like route=ferry
• Node initialcost - Set for nodes that have bicycle=dismount or highway=traffic_signals
• Way specific Node initialcost - To pass road context to way context, handy to interpret direction=forward in combination with highway=stop.

Agreed with the 2 cases for access foot=yes.

I do not see bicycle=use_sidepath without explicit foot=no|use_sidepath as foot=yes.

In The Netherlands the traffic signs G11/G12a specify a compulsory cycle path (bicycle=use_sidepath). Apart from that there is ruling saying that pedestrians should use the footway, if that is not available the cycle path and only if that is also not available the side of the main road. It is not common practice to map on ways with bicycle=use_sidepath also foot=use_sidepath or bicycle=no

So for me bicycle=use_sidepath follows your last point, i.e. a high costfactor .e.g. 15-50, but not denying access.

[polyscias]

As written in #183 I tested the two situations above with the accesspenatily set using "if and isroad bicycle=no|use_sidepath then 10" with "isroad" being:

assign isroad = 
       highway=trunk|primary|secondary|tertiary|trunk_link|primary_link|secondary_link|tertiary_link|residential|unclassified

i.e. normal roads

With that the normal routes are taken for the two crossings above. Did do more testing but did not see yet a strange detour because of this.

[polyscias]

OSRM is now handling bicycle=use_sidepath the same as bicycle=no

See:

• Bicycle: treat use_sidepath as no access
• Bicycle and oneway, routing wrong

[AllroadsNL]

That is a part of the solution.
The problem in one of the above cases, on behalve of a biker leading a bicycle is. That on a oneway way, when used foot=use_sidepath, should also be set to foot=no for that bicycle routing script. So that the biker leading a bike use the right pedestrian routing for that part.

[polyscias]

Good to know the problem in OSRM was not only that bicycle=use_sidepath but also missing foot=use_sidepath.

I see foot=use_sidepath is already part of lookups.dat:

foot;0001659694 yes allowed Yes
foot;0000424847 designated official
foot;0000202364 no
foot;0000053031 permissive
foot;0000011661 destination
foot;0000007289 private
foot;0000000167 use_sidepath sidewalk

So it can be used in the profiles.

I linked these issues here as of now the brouter profiles are not taken into account for bicycle=use_sidepath to start of with.

[polyscias]

With #337 checked in, #335 closed and the v1.6.3 released I think this issue can be closed.

[afischerdev]

@polyscias Thanks for the hint.