Proposal talk:Highway=cyclist waiting aid

Feature

As I have emphasized, hard no on using cycleway=* , which is an attribute. Various problems including for cycleway=asl already mentioned. Votes don't explain why this should be allowed.
Your explanation doesn't consider the existing usage. Are other cycleway=* without a side suffix a feature now? Is highway=cycleway not good because a "highway" is not for bikes? Obviously amenity=bicycle_parking is not for cars, and highway=escape is not for bikes. No changes are needed because the feature has limited applicability.
—— Kovposch (talk) 14:21, 29 September 2023 (UTC)

I would also strongly discourage using cycleway=* for this tagging scheme. Just because it's intended for cyclists doesn't mean it has to be stuffed into an attribute key for cycle paths. Woazboat (talk) 15:01, 29 September 2023 (UTC)

I think that highway=cyclist_waiting_aid or similar would be better alternative. Something B (talk) 23:30, 29 September 2023 (UTC)

I am not "hard" again using cycleway=*, but I also do not know the various problems including for cycleway=asl, a link would be nice. The goal here is to get a tag for a bicycle waiting aid and just indicating you do not like a certain proposal is not helpful I think. I have two questions: 1) Do you think this should be tagged at all and if so 2) what do you propose instead of cycleway=waiting aid -- Emvee (talk) 09:51, 1 October 2023 (UTC)

Still missing the link to the explanation what kind of problems cycleway=asl has that something with highway=* wouldn't have. --Nadjita (talk) 07:12, 3 October 2023 (UTC)

I indicated very clearly it's a no on cycleway=* . Within the lines, highway=* and amenity=* are common alternatives.
Apparently https://community.openstreetmap.org/t/tagging-cyclist-footrests-handles-merging-and-widening-previous-discussions/103995 hasn't been linked in Proposal:Cycleway=waiting_aid#External_discussions yet. That's the missing context.
—— Kovposch (talk) 10:53, 2 October 2023 (UTC)

Thanks for linking the topic on the forum. Your opinion is clear, I however see no problems with using the cycleway key. I see it is an attribute of the cycleway and only in second place an attribute of the highway. I do not like amenity=waiting_aid as it is not clear that this is "for the cycleway", that also somewhat true for highway=waiting_aid -- Emvee (talk) 14:04, 2 October 2023 (UTC)

thinking out loud:

Originally I prefered amenity=* as the appropriate namespace, but I can also live with highway=* or cycleway=*. I chose cycleway=* because the majority of participants in the forum poll favoured it. In it's use proposed here (as a node on a way), it would - like asl - be a homonym, and not a cycleway attribute, which need not be a problem imho, but might have disadvantages. Probably not everyone in the poll was aware of this.

amenity=* or highway=* would have the little disadvantage that it would not be clear that it is a cycling feature and misunderstandings or misuse could occur - unless we choose an oversized value like the mentioned cyclist_waiting_aid. (I'm pretty sure this kind of feature doesn't make sense for other vehicles, including scooters or motorcycles, for physical and safety reasons.)

highway=* would maybe have the advantage over amenity=* that one does not necessarily expect a stand-alone feature, but - as with traffic signals - the street furniture is not mapped at its actual location, but at the place of its "effect" on the route.

Looking across these considerations, I would actually choose highway=cyclist_waiting_aid.

--Supaplex030 (talk) 20:41, 1 October 2023 (UTC) (sorry for late response, was busy for last days)

Ok sorry, when I mentioned scooters, I was thinking about the kick-scooter size, and maybe unicycles too. Motorcycle has been answered as not useful. In fact, your example photo 3 File:Cyclist footrest 02 Flickr SDOT Photos.jpg already shows a skateboard using it.
—— Kovposch (talk) 12:13, 2 October 2023 (UTC)

FYI: I have now renamed the proposal highway=cyclist_waiting_aid. --Supaplex030 (talk) 09:43, 6 October 2023 (UTC)

Resolved: Key cycleway=* is no longer used. --Supaplex030 (talk) 19:56, 16 October 2023 (UTC)

Hands

What happened to handrest=*  ? If handrail=* is used, this means barrier=handrail can be used separately, as their problems have been discussed.
—— Kovposch (talk) 14:24, 29 September 2023 (UTC)

handrest=* seems to be a good choice instead of handrail=*. With that, you could probably also merge handrail=* and handgrip=*, which makes it easier overall. I adjusted the proposal to use footrest=* and handrest=* as typical subtags.

--Supaplex030 (talk) 20:41, 1 October 2023 (UTC)

Resolved: Key handrest=* has replaced handrail=*. --Supaplex030 (talk) 19:56, 16 October 2023 (UTC)

semicolon

when using this tag on a highway, the handrail will always be in the same location as the ASL. So should we use cycleway=ASL;waiting_aid? --Kylenz 20:37, 29 September 2023 (UTC)

This is an excellent question. Which is why I suggested to start with attribute only for the associated functionality first, then propose the routable functionality on line and separate physical feature later. It will be mostly uncontroversial to add *rest=yes to highway=traffic_signals , cycleway=asl (regardless of its appropriateness) , etc to show they have such resting devices. The benefit is no conflict, or the suitability of adding a feature to another feature needs to be considered.
—— Kovposch (talk) 08:45, 30 September 2023 (UTC)

In the case of an ASL with waiting aid, I would place the node separately slightly behind the ASL - at the locations where both would be mapped in every other case too: The point of the ASL at the stop line, the point of the waiting aid at the first "waiting position" (i.e. usually about 1-3 metres behind it).

However, the purpose of an ASL is that you do not have to wait at the curb, but can drive into the middle of the lane - while a waiting aid invites you to wait at the curb. In practice, the combination ASL + waiting aid is likely to be an exception.

--Supaplex030 (talk) 20:41, 1 October 2023 (UTC)

Sorry for the delayed reply, in my city a significant proportion of our ~370 ASLs have handrails and sometimes footrails. Since the structure often has a similar length to the ASL, it would be good to add your explaination (above) to the proposal. Otherwise it won't be clear where to put each node. --Kylenz 02:30, 6 October 2023 (UTC)

Another possible situation that could introduce a semicolon is a waiting_aid on a refuge island, which is also common where I live. This could be a problem because the crossing might already have cycleway=crossing? --Kylenz 02:30, 6 October 2023 (UTC)

Thanks for bringing up this cases! I added a section about avoiding shared/merged nodes and illustrated how to deal with typical cases and the cases you mentioned. I wasn't aware of the case with the refuge island. I think there are two possibilities here: Map the island in more detail, i.e. separately with surrounding road segments, or place the waiting aid node slightly next to the crossing node. Merging them in one node seems to be unfavorable I think. Supaplex030 (talk) 09:13, 6 October 2023 (UTC)

Resolved: Not necessary, as the key cycleway=* is no longer used. Notes on tagging other edge cases added. --Supaplex030 (talk) 19:56, 16 October 2023 (UTC)

Tagging on traffic signalk

Originally, on the forums, it was suggested to have tags for the highway=traffic_signals that simply describe that there are foot/hand rests – in addition to those tagged at the highway. The current proposal doesn't mention this tagging any more. I would find the information very useful, for routers and queries alike. Would you consider a reduced tagging in the style of cyclist_waiting_aid:handrest=* or cyclist_waiting_aid=handrest;footrest to be added to this proposal? Nadjita (talk) 14:03, 3 October 2023 (UTC)

In OSM, we aim to avoid duplicate data, which is why this idea does not appear in the proposal (or did I misunderstand you?). Even if evaluations become more complicated - due to the geographical location and the joint connection with a highway line, it should be possible. --Supaplex030 (talk) 18:26, 3 October 2023 (UTC)

I know, but in case of traffic signals, we tend to have a lot of information multiple times, and it's going to be complicated for data consumers to guess for which traffic light a waiting aid is meant, because there is no agreed on location where exactly to map traffic lights. Nadjita (talk) 20:09, 3 October 2023 (UTC)

I would rather not support this "bad habit" of multiple information :) Also to avoid blowing up the complexity of this scheme even more... It's difficult for me to construct cases where the waiting aid and the traffic light are not on the same line (or on a following line with shared attributes) and therefore cannot be clearly related to each other, if somebody wants to exactly evaluate this.

One could also argue that the waiting aid should simply always be mapped without an own primary tag at the traffic lights, but there are waiting aids that are not located at traffic lights (but e.g. at stop lines that are independent of traffic lights). Imho this would again lead to inconsistencies and make evaluations even more difficult. --Supaplex030 (talk) 08:57, 4 October 2023 (UTC)

Resolved: Proposal focussing on/strongly suggest tagging as a separate node and not as an attribute of traffic signals. --Supaplex030 (talk) 19:56, 16 October 2023 (UTC)

count vs capacity

In the example-mapping for count=2:

I find this information completely misleading. I would encourage the use of count=* only for single-person waiting aids, like handgrips on poles, so that the meaning of count=* and capacity=* is interchangeable, with the exception that count=2 would mean: 2 devices with 1 person each and capacity=4 means: Any amount of devices, but in total, 4 people can use it. Or ditch the count=* altogether, it might just be misleading. Nadjita (talk) 10:11, 6 October 2023 (UTC)

From my own mapping practice, I only know "count" from the context of bicycle parking, where "count" indicates the number of objects (e.g. number of stands) and "capacity" the number of bicycles that can be parked at the same time. "count" is rarely used because "capacity" is the more interesting information for most use cases and for stands, for example, it only differs from "capacity" / 2 in edge cases. Moreover, "count" is undocumented and therefore not necessarily clear what is actually intended to be expressed.
But here it is meant in a similar way as for the bicycle parking: "count" indicates the number of waiting aid devices, no matter how many people can wait at each device at the same time. I'm not sure if the default "one person per waiting aid" is valid - can't there also be two people waiting at the same time? I have some arround here – have to try it out :) But to avoid this ambiguity, I thought it would make sense to simply specify the number of devices instead of the number of people, which may be difficult to derive. An exception would be devices for which the capacity is clear, e.g. the handle. This should be explained in more detail in the proposal, if this distinction makes sense.
What do you think? Supaplex030 (talk) 10:29, 6 October 2023 (UTC)

I've never seen count=* being used on bicycle parking, only capacity=*. I don't think it's a helpful indicator without capacity=*, which is the only thing I'm really interested in.
But as for the other question: The devices in the above picture look like each could be used by 1-2 people, all 2 of them by 3 for sure, 4 if they know each other ;) At least from the perspetive the photo was shot. Again, I think I would only use count=* if it is identical to the derived capacity=*, so only for handles. For everything else, capacity=* seems the more useful tag, but I'm open to other people's opinion. We could give guidelines regarding the estimated capacity, same as there are for bicycle parking and the number of stands. Nadjita (talk) 12:22, 6 October 2023 (UTC)

Exactly thats the problem: In contrast to bicycle stands, you can't really specify the capacity=* (of people that can use the waiting aids at the same time), because it strongly (much more than for bicycle stands) depends on cyclist behavior and spatial arrangement. So we could simply tag the count=* (=number of devices). But I'm also very interested in other opinions about that! Supaplex030 (talk) 12:45, 6 October 2023 (UTC)

Resolved: Added notes below the examples to explain how to use count=* and capacity=* in this context. --Supaplex030 (talk) 19:56, 16 October 2023 (UTC)

Why not amenity=cyclist_leaning_rail?

Personally I'd go with documenting tag that is already used (23 worldwide) instead of inventing completely new one. I also believe it's more amenity, not highway. Kubahaha (talk) 15:14, 6 October 2023 (UTC)

My thoughts why highway=* have some little advantages over amenity=* can be found in the first section (primarily to avoid misunderstandings because we don't map the exact device, but it's "effect" on the highway line).
amenity=cyclist_leaning_rail was the first name of this proposal, there is also cycleway=footrest in use. Both terms aren't very well, so we discussed a better value to finish this proposal and waiting_aid was the result. I'll retag all amenity=cyclist_leaning_rail I'm aware of. Supaplex030 (talk) 16:03, 6 October 2023 (UTC)

Thanks, I missed that part earlier. It's good point that features tagged as highway nodes should differ somehow. However it can be on highway=*, path=* and cycleway=*. Now I'm thinking if it should not be separate node. But I agree, someone has to decide. Thank for explanation. Kubahaha (talk) 19:58, 10 October 2023 (UTC)

Resolved: I would prefer a separate node as well, but a poll in the forum has clearly pointed in the other direction. I can live well with both. --Supaplex030 (talk) 19:56, 16 October 2023 (UTC)

Clarification requested

> If there are several such devices in a row, place the node at the "first" waiting position.

Does "first" mean closest to the traffic signals or the first one you encounter when cycling up to the signals? —M!dgard (talk) 10:56, 10 October 2023 (UTC)

Thanks, I made that more clear by adding the explanation "closest to the e.g. traffic lights/front of the queue". Supaplex030 (talk) 12:34, 10 October 2023 (UTC)

Resolved: Clarified section. --Supaplex030 (talk) 19:56, 16 October 2023 (UTC)

missing file

https://wiki.openstreetmap.org/w/index.php?title=File:Cyclist_waiting_aid_handle.jpg&action=edit&redlink=1 (in gallery) Mateusz Konieczny (talk) 15:59, 25 October 2023 (UTC)

I know – I'll replace it with a self-made drawing or collage when I find some time, as I don't know of any location where I could get a photo of it and so far I haven't managed to get permission to use an existing photo. Supaplex030 (talk) 21:04, 25 October 2023 (UTC)

Resolved: Image replaced. --Supaplex030 (talk) 13:16, 7 November 2023 (UTC)

direction=both?

I could imagine waiting aids on a traffic island that is used in both directions. How would you specify direction? direction=both? Discostu36 (talk) 08:35, 28 October 2023 (UTC)

Mhm, direction=both is the most common value, along with forward and backward, even if it is not documented (if I see correctly), so it seems to be a good choice to me. However, imho this proposal is not the place to mention that (but that should happen at direction=*). Supaplex030 (talk) 19:49, 29 October 2023 (UTC)

Resolved: direction=both is in use. --Supaplex030 (talk) 13:16, 7 November 2023 (UTC)

Advocacy and analysis of situations where these bicycle waiting supports could be installed with some benefit

- These "waiting aids" could help cyclists to stop at red lights. In a number of situations, cyclists are inclined to run red lights ?
- In addition to serving as a waiting support, this equipment can also act as a separator between motorized traffic and active traffic (bicycles), in which case it should not be on the side of the pedestrian sidewalk, but rather on the side of the roadway.
- These devices are best suited to situations where there is no bicycle box (or 'advanced stop box' [cycleway=asl]) at the traffic light, as they would force cyclists to move to the right-hand side of the carriageway instead of occupying the center of the carriageway, as the bicycle lock allows.
- This type of equipment is useful when traffic flows are not very high, as it does not have a high capacity: only 2 or 3 cyclists can use it (twice as many if there are two pieces of equipment).

In any case, some disadvantages:
- These facilities are not suitable for recumbent bikes.
- These facilities lack of automatic shoe-shine service !

Barnes38 20:48, 19 November 2023 (UTC)