Tagging cyclist footrests/handles – merging and widening previous discussions

[Supaplex030]

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)

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

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)

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

[Nielkrokodil]

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
bicycle_comfort:footrest=*
bicycle_comfort:handrail=*
…

[Langlaeufer]

@Supaplex030

A specific term like “footrest” or similar that clearly names the device – it might need a separate value for handles then

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.

[dieterdreist]

@Langlaeufer

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?

[Langlaeufer]

distinct subtags as suggested by @Nielkrokodil
cycleway=bicycle_comfort
bicycle_comfort:footrest=yes
bicycle_comfort:handrail=yes

[Nadjita]

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

cycleway:right=bicycle_comfort
bicycle_comfort:foot=rail
bicycle_comfort:hand=handle

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

[Mateusz_Konieczny]

@Supaplex030

71% A node on the line of the cycleway or highway

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

[dieterdreist]

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

[Nadjita]

@Mateusz_Konieczny

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

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

[Nielkrokodil]

@Langlaeufer

cycleway=bicycle_comfort

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

[Langlaeufer]

@dieterdreist

nd possibly as ways if they are longer than 1-2 meters

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

[Supaplex030]

@Nielkrokodil

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

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.

[Mateusz_Konieczny]

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)

[Supaplex030]

@Langlaeufer

cycleway=bicycle_comfort

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?

cycleway=waiting_aid
waiting_aid:footrest=yes
waiting_aid:handrail=yes

(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…?)

@Mateusz_Konieczny

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

Possible, but untypically and unfavourable in my opinion.

[dieterdreist]

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

[Map_HeRo (Mikke)]

@dieterdreist

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,

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

@Supaplex030

cycleway=waiting_aid
waiting_aid:footrest=yes
waiting_aid:handrail=yes

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

[dieterdreist]

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?

[Kovoschiz]

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

[Kovoschiz]

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.

[Supaplex030]

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.