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.
handle= is unfortunately already used for the control interface of =water_wall etc. I did consider it. It’s not for controlling anything here.
Are you sure that https://community-cdn.openstreetmap.org/uploads/default/original/2X/b/b3501a7c33251ed75ccd56b6a6bafd13ffd3ae44.jpeg would be referred as handrail?
Especially on higher traffic cycleways it is not really possible to use left side one. It someone would use this data to spot places where such infrastructure is missing (is there other viable use for that info?) then side info would be also useful
only if the cycleway is oneway=no which is not very common in some regions
OK, in this regions it would not be a large problem.
The object in pic 2 would be called handhold or hand grip but in some cases the waiting aid would be a hand rail where you can get a hold. So a more generic tag like “handrest” and “footrest” is a better choice imho for easier tagging.
FYI: I reworked the proposal for these waiting aids and have adopted the results of this and previous discussions: Proposal:Cycleway=waiting aid - OpenStreetMap Wiki
The proposal suggests cycleway=waiting_aid on a node on the cycleway, and the subtags footrest, handrail and handgrip (can be used with side prefixes, e.g. footrest:right) to specify different elements (and the side).
6 Likes
Do you want to switch to a discussion about this specific proposal, or should we rather do that in the wiki from now on? I’m asking, because some prefer to work on their proposals alone at this stage, and just update them when something new comes up in another (this) discussion.
I just started the RFC process to “open” the discussion to a new stage. You can discuss further on the wiki page, or use the new RFC thread.
I’m tending strongly to change the tagging to highway=cyclist_waiting_aid (instead of cycleway=waiting_aid), even if the initial vote in this thread goes in a different direction. Notes/considerations on this topic can be found on the wiki talk page of the proposal. Maybe we can discuss it further there if there is a need.
But I wanted to report it back here, since presumably only a few of those who have participated in the discussion here also read/monitor the wiki proposal page.
I’m tending strongly to change the tagging to
highway=cyclist_waiting_aid
isn’t this too generic? This tag could also represent a roadside book case, take a book and it’ll make waiting easy 
I just find the wiki a very clumsy place for a discussion. You can tell that it wasn’t made for this sort of thing 
2 Likes
Absolutely. Feel free to continue the discussion here and I’ll feed it back to the wiki talk page 
Are you using Convenient Discussions already? I find the lack of threads in Discourse worse than wiki. Replies, quotes, and jumping between comments are “clumsy” for a multi-topic issue.
I used to think that threaded reading is a great idea, but nowadays, I don’t like it that much any more. In theory, it’s great, but in practice, people tend to read all threads anyway and sometimes reply to 2 different thoughts/threads at the same time, so naaa… I like the classic linear forum structure. But I prefer if people are quoting what they are referring to, so I don’t have to jump around and search. The links in discourse make this less of a hassle, though. Well … just my personal opinion. On the wiki, it’s hard for me to spot who is actually saying what and on active pages, you tend to get conflicts when 2 people are trying to reply at the same time. Happened so often to me. Got frustrated. Would not recommend. 1/5 
On wiki, go to preferences. In the “Gadgets” tab, enable Convenient Discussions. It resolves the conflicts for you, among signature, threading, and other things.
For a proposal, it at least Github Discussion’s structure for different comments with replies to them. Ie similar to Discourse’s Q&A help format. Then those topics should be able to be marked “Resolved” etc (that however wiki discussions don’t usually follow).
In Using the forum as the main discussion platform for tagging for example, there is reference to Web Discussions: Flat by Design where the conclusion favors limited and localized display of threading following Twitter. In Reddit, you can still manually get a “context” view of the thread of each comment. Hacker News has a useless one.
Ooh, that’s already much better. Still not a forum, but definitely a leap forward. Thank you! 
FYI: I have reworked the proposal again and added a simpler and more intuitive concept to tag the side on which a waiting aid is located. The previous approach of defining this e.g. via footrest:left could lead to misunderstandings and was difficult to interpret, especially on bi-directional ways when the waiting aid is used in backward direction (where the side of the way is different from the side of use). Instead, it is now proposed to use a simple side tag, which indicates on which side of the user a waiting aid is located (left or right, rarely both). In this case, the side is clearly defined from the user’s perspective, and not from the perspective of the OSM way element.
(The literally first use of the proposal in the wild had exactly this interpretation problem).
3 Likes
@Supaplex030 I really like the state the proposal is in now! Thanks a lot for this great work. It has gained a lot more clarity and simplicity in the course of the discussion. I especially like the simplification of the side topic. And also the short summary of how you came to suggest the tags/values your are using, which makes a lot of sense to me (especially the part about amenity vs. highway).