Tagging cyclist footrests/handles – merging and widening previous discussions

From time to time, the question pops up on how to tag footrests or handles for cyclists that are intended to make waiting at traffic lights more comfortable (a list of half a dozen discussions on this topic from different OSM channels can be found in the OSM wiki).

The discussion results have been mostly sparse so far, but in the meantime, there are two proposals on this subject (amenity=cyclist_leaning_rail and cycleway=footrest) and certainly some more tags in the wild. However, I think that a few aspects should be discussed again in a larger circle, e.g.:

Which primary tag should be used for this?

  • amenity
  • cycleway
  • highway
  • (other)
0 voters

Where should the geometry be located?

  • A separate geometry at the exact location of the device
  • A node on the line of the cycleway or highway
0 voters

This type of street furniture comes in various forms - especially as a footrest as well as a handrest/handle.
How should the value be named? Please also suggest a term in the thread if you know a good one : ) If possible, from a traffic-/professional-related discussion or publication…

  • A specific term like “footrest” or similar that clearly names the device – it might need a separate value for handles then.
  • A (newly invented?) generic term that includes both footrests and handles – a subtag could possibly be used for further differentiation.
  • (Something different)
0 voters

It would be great if a picture of the opinions could be painted here and more opinions are shared, so that maybe we can finally come to a proposal and a documented tagging to close this tiny but obvious gap in the OSM universe : )


I think more important than mapping the specific objects is mapping it as property of the crossing, like we do with traffic_signals:sound=yes and similar.

For example

1 Like

Some devices combine both footrest and handle (first image), others are only a handle or a footbar - therefore I would prefer an generic term plus subtags.


wouldn’t this be easier to represent with 2 distinct tags, one for devices you can hold yourself with your hands and one for foot rests?

1 Like

distinct subtags as suggested by @Nielkrokodil

You could even go further and have the type as value:


because it seems cities are starting to be creative when it comes to the what and how of these things :wink:

note that sometimes you may need to be able to specify side/direction (but expecting it to be done in every single case like some silly Osmose rules want for traffic lights is not needed)

there can be a case of such stand in the middle of a crossing (on island) on both sides or only on one side

currently people are in favor of „cycleway“ as the key and connected to a highway=cycleway. We also can anticipate from the pictures that some rails can be quite long. IMHO we would better map them at their actual position (thereby implying the side), and possibly as ways if they are longer than 1-2 meters

I guess that’s when you can use :forward/:backward and :left/:right: cycleway:forward:right=… with :right being the default for countries with right-hand traffic I suppose. But this brings up the old discussion about these suffixes on nodes :smile:

1 Like

Do we need cycleway=bicycle_comfort at all in this case? I think we don’t.

1 Like

for me it doesn’t, matter how long they are. Even the capacity does not tell you if you get a free place there.

1 Like

Imho we need a primary tag for them, because otherwise you would have to map them as a property of e.g. a traffic light, but with the variety of shapes and situations all over the world I am sure there are some that are not at a traffic light or even in front of another traffic facility. So in my opinion its better be map them as an own object in front of the traffic light or whatever/whereever they are located.

1 Like

bicycle_comfort:foot can be also a primary/feature/main tag

(see also man_made=advertising advertising=* tag family, nowadays advertising is the main tag and redundant man_made=advertising typically skipped)

What about the term “waiting aid” to clearly name the object by its function and to avoid misunderstandings/misuse for other cycle related features that have nothing to do with this specific piece of street furniture?


(I have already done some research, but I have never noticed a generic English term for this in publications. In German there is “Wartehilfe”, which could be translated as waiting aid…?)

Possible, but untypically and unfavourable in my opinion.


In German there is “Wartehilfe”, which could be translated as waiting aid

IMHO saying there is this word for this kind of thing is a stretch, some people might use the word for these and it is descriptive in an abstract way, but it isn’t well defined. If a friend told me to go and buy a Wartehilfe, I had not idea what they wanted me to get. Just have a look in the Internet, you will find different uses of the word in quite different contexts (and bicycle infrastructure is not among the first hits).

I agree that “waiting_aid” could be anything and is as vague as “bicycle_comfort” - but being used as value to the key “cycleway” the subject becomes quite clear imho. I would support the suggestion of Supaplex030

but I would not use “handrail” (as this is no rail in many cases) but “handgrip” or “handhold” instead.

1 Like

but I would not use “handrail” (as this is no rail in many cases) but “handgrip” or “handhold” instead.

is it about function alone, or is it required to be intentional?

Please don’t use *:foot= . That’s obviously a collision with foot= .

i don’t agree with any of the above exactly. First of all, it should be emphasized the attribute and feature are not mutually exclusive, for iterative refinement. The attribute can first be added to the =traffic_signals= . Then the feature separately drawn later.
bicycle_comfort= is too “subjective”. waiting_aid is too vague. We don’t use holding_aid and moving_aid for handrail= and ramp= .
For the attribute, referring to ramp:*= , we can simply use handrail:bicycle=yes to be exact and physical. Then footrest:bicycle= arises logically. footrest= on its own can potentially be applied to =bench and other features for extremely micro details, similar to backrest= . Indeed, footrest | Keys | OpenStreetMap Taginfo is already used on 27 objects, from =bench to =fence . This can be compared with the 2833 Key:armrest - OpenStreetMap Wiki .
On a separate object, the feature should be identified. In opening example photo 1, the footrest can be considered a part of the handrail. Then the attribute footrest=yes remains a solution on the feature.
For the feature, although there is barrier=handrail, it isn’t clearly distinguished with =fence . Furthermore, dedicated handrails can be installed on a fence in addition to the structural top rail of the fence (maybe it’s too tall), making =handrail ambiguous and not a viable solution at all. While the main purpose of example 1 is for holding onto as an integrated design, they still prevents movement through them similar to a =fence . On the contrary, the top rail on most fences used as barriers aren’t for holding onto. As such, the feature barrier=handrail should be reserved for dedicated handrails on a short section of a wall etc that needs to be drawn separately.
Therefore I suggest a comprehensive solution using =fence . This can succeed Proposal:Fence attributes - OpenStreetMap Wiki to replace fence_type= and barrier=handrail .
In this case, fence:top_rail=yes + handrail:bicycle=top_rail can be used to show there is no separately installed handrail, only the structural top rail (tube) of the fence itself. (Eg handrail=dedicated might be used for the opposite) And the top rail is supposed for bikes to hold onto.
Instead of the undesirable style fence:type= , fence=handrail can be used directly to show overall this fence is dedicated as a handrail. fence:function= can be used for the purpose, whether =comfort (I still don’t want to be too specific as =bicycle_comfort ) , =waiting , =handrest (depending on example 2 below), or something else.
For example 2, the feature can be man_made=traffic_signals | Tags | OpenStreetMap Taginfo (N=75); or simply man_made=pole first (sorry I don’t agree with =utility_pole when traffic lights are not a “utility”), due to the undefined meaning when there are multiple signal heads on one pole. As there are concerns about them not being a “handrail”, handgrip= (specific to the form) or handrest= (in line with armrest= and footrest , but overlapping with handrail= ) can be invented. If needed, they can be suffixed with *:bicycle= as well.

Sounds like a little nightmare for data consumers. We are taking about a distinctive device with a clearly intended function that increasingly appears in different cities (and different forms) around the world. Who is interested in using this data need a clear data scheme to identify this kind of street furniture.

1 Like