What’s not clear about handrail:bicycle=yes ? Attributes can be handled easily on the associated features. And handrail= is already widely used. This is the same format as the standard ramp:*= , including ramp:bicycle= . Will you say cycleway=moving_aid + moving_aid:ramp=yes + moving_aid:automatic=yes should be used? Or cycleway=bicycle_movement + bicycle_movement:ramp=yes ?
Also a pedestrian can still rest on it. This is the same as how a ramp:wheelchair= can used by non-wheelchair users. So a general attribute handrail:*= as ramp:*= is more usable. Can’t motorcycles, mopeds, and mofas use it too? The user shouldn’t be unnecessarily restricted by bicycle_*= or cycleway=* . This limits flexibility and extensibility. We can focus on the physical structure.
The difficulty is on the separate feature. If I add a footrest on an existing railing for restraining pedestrians, what does it become? It wasn’t installed for bikes either, although you can hold onto it. They are inherently multi-purpose, and this complexity will be reflected.
Hmmm, to make it more clear to me (and presumably others) can you give us a short and simple example how you would propose to tag the structures shown in the 2 pix, just a few lines like these:
Picture 1:
cycleway=waiting_aid
waiting_aid:footrest=yes
waiting_aid:handrail=yes
Picture 2:
cycleway=waiting_aid
waiting_aid:handgrip=yes
You shouldn’t focus on the physical structure here imho, because there is no distinct physical structure, what makes it hard to identify objects in our database later that are intended/structural “waiting aids”. Instead there is a wide range of forms for devices, that share one characteristic: Their intention to make waiting for cyclists more comfortable. If somebody is interested in “informal” waiting aids, of cause he:she can look for barriers near traffic lights, but that’s not what we are talking about in this thread.
Thats why I think it’s a very good and easy way to just tag them with a clear term like “waiting_aid”. I personally prefer putting it to the “amenity” space (e.g. to avoid the motorcycle problem, although I could find any evidence they exist for this purpose), but the poll shows that most mappers prefer the “cycleway” space.
Often, they are a literally stand-alone features, that’s why you can’t compare them to ramps.
I completely agree that it would make sense to tag the feature on traffic signals (and railway crossing, etc.) as an additional property and also record the exact location (probably with different tags).
Using fence as the base-tag seems wrong, though, because the ones we’re talking about are clearly not fences. An iterative approach makes sense for data consumers. For me, ramp= is a refinement of highway=steps and ramp:bicycle= a refinement of ramp=. Much like this, it would make sense to add something generic like “this feature has a waiting aid” (like “this feature has a ramp”) and later on refine it to “it’s a footrest for bicyclists” (like “it’s a bicycle ramp, sorry wheelchair users”). But I can also understand that it would need to be generic enough to also allow tagging of “unplanned” waiting aids, like a handrail that was actually meant as a barrier. Whether that’s going to be as a value of something like waiting_aid:handrest=fence or fence:waiting_aid=handrest, I don’t know. But it would surely be nice to take it into account.
- The question is whether they need to be a feature, and how.
- _
2.1. It’s at least unnecessary to prefix thewaiting_aid:*=attribute. This serves no purpose. A handrail is of course for holding onto, and resting here. There is no significant difference in the meaning. On the associated feature’s attribute, you still aren’t showing it’s for bikes. Can it be a rest for old people and the impaired?handrail:bicycle=makes it clear. Again, it’s not necessary to specify it’s for “waiting”. (In fact, there exist chairs for them to wait to cross. Korean elderly back road safety seats - BBC News —— Will it bewaiting_aid:bench=instead ofbench=?)
2.2. I’m opposed to usingcycleway=as a feature.cycleway=should remain an attribute.=aslor=bike_boxis an exception. It’s a stop-gap solution beforehighway=traffic_signalscan be sorted out. This should not be encouraged. Mopeds, scooters, etc are possible users, despite not being the main intention. (There is already a question about ASL for motorcycles Talk:Tag:cycleway=asl - OpenStreetMap Wiki ) In splitting thehighway=road to tag on the routable line, it should still be egcycleway:*:handrail=, where the*:bicycle=can be assumed. There’s no need for*:waiting_aid:handrail=to bloat subkey with meaningless namepsacing. If you still want a feature point on thehighway=road, it should behighway=waiting_aidif anything. But it will run into the same problem ashighway=speed_cameraonce you use it as an unconnected object physically, causing functional gaps and inconsistency. So please don’t do that. - The rationale is the separate feature’s attribute should be consistent with the associated feature’s attribute.
handrail:bicycle=can be used in all cases. Myramp:*=comparison is exactly for the attribute. For a feature example, would you prefercycleway=repair_equipment+repair_equipment:compressed_air=yesoveramenity=compressed_air+bicycle=yes?
The =fence replacement is mainly based on the problems of barrier=handrail . Physically and structurally, these are railings. Is there any visible difference between a staple-shaped railing used for restrain and leaning? It belongs to fence:function= .
You compared ramp= as the counterpart to “waiting aid”. First of all, one problem here is cycleway=waiting_aid seemingly proposed both as a feature, and an attribute or a feature to be added to other features. This should not be done. If you want a generic attribute on other features, ok perhaps at most eg waiting_aid=yes can be considered (because cycleway= is used on highway= roads), but this does not support the introduction of prefixed waiting_aid:*= when handrail= and sparsely footrest= are used perfectly fine. For the feature, as I said, =waiting_aid alone already means it is unspecified.
Now, ramp= is already referring a recognizable physical structure, while waiting_aid is a functionality. I would rather compare “ramp=” with “handrest” , which can be a “handrail” (difference with armrest= ???) or “handgrip”. In practice, what I want to ask is is there a level of detail when you can only specify waiting_aid=yes, but not footrest=yes or handrest=yes ? On =bench, there doesn’t seem to be a need to show there is something unspecific you can rest on. =backrest , =armrest , =footrest are used directly. Is waiting_aid=yes a needed category then?
It depends on how “handrest”, “handrail”, and “handgrip” are organized. The vals below may be changed to =separate if desired. The format depends on whether you want “handrail” and “handgrip” to be available on both. I used handrest:bicycle= to align with footrest:bicycle= .
1.
Stop-line point
highway=traffic_signals
footrest:bicycle=yes
handrest:bicycle=handrail
Rail line (I can accept barrier=handrail when there is only a single segment here, but it’s poorly defined in the existing usage.)
barrier=fence
fence=railing
fence:function=handrest
handrail:bicycle=top_rail
footrest:bicycle=yes
(I assumed fence:top_rail=yes is redundant for =railing. Also I now think handrail:*=additional is better than handrail:*=dedicated to differentiate top rails from handrails installed on top or the sides of barriers that are structurally separate)
2.
Kerbing (There is no footrest of any type here. I assume footrest=no is sufficient. footrest:bicycle=no can still be used, if there is no concern about this suggesting other footrest:*= can exist. )
highway=traffic_signals
handrest:bicycle=handgrip
footrest=no
Traffic light pole (Traffic light and pole tagging not shown)
man_made=*
handrest:bicycle=handgrip
footrest=no
Thanks for making it more clear. I agree to add a certain tag to the traffic_signals and a separate tag to the object itself, but I do not see any good in calling these objects a fence which they are definitely not.
Combining the above said I would go for
highway=traffic_signals
bicycle_waiting_aid=yes
+
cycleway=waiting_aid
waiting_aid:footrest=yes
waiting_aid:handrest=yes
highway=traffic_signals
bicycle_waiting_aid=yes
man:made=* (some kind of pole)
cycleway=waiting_aid
waiting_aid:footrest=no
waiting_aid:handrest=yes
Using footrest and handrest instead of *rail" or *grip" makes the values more generic and easier to use imho.
Many cyclists (including myself) use any suitable object as waiting aid, like lightpoles, roadsign poles, street cabinets and whatever may be availble. I would not tag any of these as “cycleway=waiting_aid” but well, if there is a handrail or hoopguard barrier available for use the above tags would serve well.
Both resonate with me, but in the separate nodes with cycleway=waiting_aid, it really makes no sense to use the waiting_aid-prefix, so:
cycleway=waiting_aid
footrest=yes
handrest=yes
As @Kovoschiz pointed out already, this would be in line with backrest=yes and could possibly be used to refine existing amenity=bench or amenity=lounger.
The other thing I’m, unsure is bicycle_waiting_aid vs. bicycle:waiting_aid vs. waiting_aid:bicycle=yes. But I think we’re slowly grasping what’s needed. Woohoo!
I would not use bicycle:* because- bicycle is an access-tag.
Just throwing it into the mix, because we already use things like bicycle:repair=*, bicycle:rental=* bicycle:type=*, and so on. I don’t prefer one over the other 
As I noted, barrier=handrail remains an option. My opposition is for the cycleway= feature, and the unneccssary waiting_aid:*= . amenity= mentioned above is usable, but for basically all other features, it’s only used on points, not lines. That’s why barrier= has topological and physical suitability. While it may not block your intended movement, a =handrail prevents you from failing down. So it’s clearer and cleaner than the bloated (same for amenity= ) and disliked semantics man_made= .
I would like to add that for thoughts about using waiting_aid:*= to store prefix future resting devices, the same can be done in *rest= and *rest:*= , and more clearly showing what it is for from the beginning. Eg imagine handrest:rings=yes or footrest:spikes=yes .
many of them are not really handrails at all
From Projekt odrzucony - Podpórki dla rowerzystów na skrzyżowaniach - Budżet obywatelski
I like this one
Yeah, me too.
But what about the valid argument that this device could also be imagined for situations/users other than cyclists, e.g. on special lanes or places for motorcyclists or scooters/small electric vehicles? Don’t you think amenity would therefore be a better choice than cycleway? I am sure it would be worth it sooner or later…
Another open question is how to indicate the side of the path on which the device is located if we place the node on the way. Especially for footrests, I think this is an interesting information. cycleway:right=waiting_aid/amenity:right=waiting_aid sounds like a bad choice to me. footrest:right=yes sounds better, but might also be a stretch of the footrest/handrail concept.
Are these not handrails? They are advertised as such. The Hold-tight Handrail Jamb Mount 18 is the Perfect - Etsy Ireland
What I want to point-out is you need to find something that fits both points, and lines (which amenity= doesn’t do very well). barrier= does, and they can be considered a =handrail . The next choices are highway= or man_made= .
And I will repeat this every time: cycleway= should not be a feature.
Well, amenity=bench can be used on nodes and lines, and it’s probably the closest relative to our feature, wouldn’t you say?
If we use something like amenity=waiting_aid, we either have the choice of going directly to amenity=bicycle_waiting_aid or having to add something like waiting_aid:for=bicycle. Either way, just amenity=waiting_aid sounds like a top-hierarchy class for things like benches. I’m not opposing amenity as a key, but waiting_aid as the value for this. Maybe one of the native speakers has a good suggestion, what amenity it could be?
I would ditch the barrier=-tagging as the general tag of these features. 2 reasons:
- Not all of them even act as a barrier (handles on traffic lights)
- It would make it impossible to tag them on the road itself, because it’s not a barrier for the road.
man_made, for me, is one of these “I don’t know where else to put it”-keys, but I suppose it would also be an option, although amenity seems to fit better. The highway key cannot be used on the highway itself, for obvious reasons. But I agree that cycleway=, on a closer look, is probably not the best choice. The reasoning has probably been that the value waiting_aid was immediately tied to bicycles. But a prefix or suffix solution might be equally good (sth. like amenity:bicycle=waiting_aid). Still sounds like the grandfather of the bench to me 
To me this is not a valid argument.
A motorcyclist (not talking about a mofa) already learns in the driving school that you put both feet on the ground for safety purpose when stopping and you will definitely not hold yourself to a handgrip fixed anywhere.
If mofas, scooters and other small electric vehicles use the cycleway they may use the handrest/footrest on the cycleway.
If there will be something like a mofa lane or scooter lane in far future (at the time being there are not even enough cycleways) we can add the same tag to the scooterway instead of the cycleway.
From that point of view I do not see any reason why these objects should not be tagged to the cycleway and 56% (as per today) of the votes do so as well.
Myself as a cyclist wouldn’t bother if such thing is on the left or right side of the cycleway. If I have to stop and there is a handrest to the left: fine! A footrest to the right: fine! Nothing at all: fine!
I am not native speaker, so I might be wrong. But isn’t a handrest something where you put yout hand on, but you do not grab it?
The discussed examples are for grabbing (closing the fingers around the object), you cann push and pull yourself from/to it. I guess handle would be a better term.
=bench is still one of the few examples, although it does not have the fatal flaw as cycleway= attribute abused for feature. For the functionality, should an amenity= point be created on the highway= road line? This is why I thought highway= fits better.
Why would you add a highway=waiting_aid line on the road line? You should split the road to use cycleway:*:*rest= . I mean a point feature.
barrier= is for the separate unconnected object at its physical location, based on barrier=handrail which is not added on the road either. This relates closer to the physical structure.
- What do you think about these short, almost point-like ones I asked about? Can you not add them as
barrier=handrailpoints? The Hold-tight Handrail Jamb Mount 18 is the Perfect - Etsy Ireland - As explained.
For amenity= , unmodified amenity= + bicycle=yes is good enough to me. Similar to =compressed_air etc.