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)
0voters
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
0voters
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)
0voters
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 bicycle_comfort:footrest=* bicycle_comfort:handrail=*
…
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.
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
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.
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.
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.
