Proposal talk:Crossing signalization

Signal use

Ok I see this now. I will respond here. Primarily crossing:signals=* is in unclear use now, so I wanted to start fresh to avoid any confusion with it. crossing:markings=* chose not to follow crossing:marking=* either. I wanted to follow crossing=traffic_signals, so I split it off to crossing:traffic_signals=*. If following crossing:signals=* is more advantageous here, I can agree with it.
I haven't completely thought out the exact usage. Will pass on the mid-block case for now.
I continue to hold the opposition to *=separate. How about using *=dedicated? This is a standard technical term as well.
However, how should bike signals be handled? It might be worth considering. --- Kovposch (talk) 04:48, 18 November 2022 (UTC)

@Kovposch: Fortunately, we don't need to worry about conflicts with existing usage in this case. This proposal is mostly a rehash of the much-discussed Proposed features/crossing:signals, which coined crossing:signals=* back when that key was still unused, so I'm pretty confident that existing usage of yes and no are consistent with this proposal. I recently coined shared and separate, and others in OSMUS Slack latched onto it. However, I don't think anyone is particularly attached to these literal values; folks were just excited to be able to make this distinction at all. Usage is low enough that we can transition to whatever comes out of this process.

I liked the simplicity of separate but recognize that it could be misinterpreted to mean that the signal has been mapped separately. (Oh how I'd like for there to be a tag for a signal head, but alas that's out of scope.) dedicated is not a bad option at all, though eventually we need a moratorium on D words; it must be challenging for non-native English speakers to juggle dedicated, designated, designation, denotation, and destination! :^) Most sources refer to a pedestrian signal head versus a vehicular signal head, so I considered foot and vehicle, and perhaps bicycle for the separate bicycle signal heads common in some places. However, I was concerned that people would confuse these values with access tags and start nitpicking about how bicycles are vehicles too.

 – Minh Nguyễn ^💬 06:38, 18 November 2022 (UTC)

I agree that the use of *=separate is problematic and also thought of *=dedicated as an alternative. I have no strong opinion on either though as the values are useless where I live, I've never seen a shared signal and I think it's the same in most of Europe. As such, there is no point in mapping anything other than yes/no. --Riiga (talk) 18:39, 18 November 2022 (UTC)

@Riiga: I think that makes sense, since the objective is to allow mappers to tag another level of complexity where it's warranted. Similarly, I assume some countries will be tagging only crossing:markings=yes rather than the more specific values. – Minh Nguyễn ^💬 08:26, 19 November 2022 (UTC)

Although I don't see a huge problem with separate, I agree that dedicated is probably a better option. Mappers could easily get the wrong idea about separate given how sidewalk=separate is used to mean a separately mapped sidewalk. shared seems fine and I don't have any suggestions for a clearer value. -- Ezekielf (talk) 17:12, 29 June 2023 (UTC)

Looking at it again, I realized another issue with crossing:signals=* is traffic_signals:*=* already being used with crossing=traffic_signals and listed together. --- Kovposch (talk) 05:26, 30 June 2023 (UTC)

@Kovposch: traffic_signals:*=* exists in part because of iteratively refining crossing=traffic_signals. But I don't think it's a good idea to coin further keys that refine crossing=traffic_signals. For one thing, it makes it more difficult to iteratively refine highway=traffic_signals without confusing collisions like traffic_signals:countdown=*. – Minh Nguyễn ^💬 01:05, 2 July 2023 (UTC)

Another problem with traffic_signals:*=* is that we need to keep the tagging options for highway=crossing and railway=crossing as consistent as possible, but traffic_signals:*=* doesn't make much sense in the context of a railway=crossing. – Minh Nguyễn ^💬 22:38, 4 July 2023 (UTC)

Deprecating crossing=*

DECLINED:

Deprecating crossing=* is out of scope for this proposal but could be considered in a future proposal. – Minh Nguyễn ^💬 23:03, 4 July 2023 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

@Riiga: You mentioned in Talk:Proposed features/Highway crossing cleanup#Lossy deprecation that you'd like to see crossing=* deprecated. This proposal would make crossing=traffic_signals redundant and thus make crossing=* fully redundant. Do you think we should tackle deprecation in this proposal or separately, perhaps as part of Proposed features/Highway crossing cleanup? I think an important first step would be to compile a list of all the editors, renderers, routers, and QA tools that currently do something special with crossing=traffic_signals. Tyr recently added this tag to id-tagging-schema, but at least in that case we've been discussing a migration path for some time. Are there other data consumers that distinguish the various crossing=* values? – Minh Nguyễn ^💬 09:48, 27 November 2022 (UTC)

I'm not sure what the best approach is. I think some people won't approve crossing:signals=* while crossing=* is still in use as some of the use will be redundant. On the other hand, some might not want to deprecate crossing=* fully while approving the use of crossing:signals=*. I could modify my proposal to try out the former approach leaving this (your) proposal to be approved should there be debate on whether the deprecation should be part of the proposal. --Riiga (talk) 07:49, 28 November 2022 (UTC)

@Riiga: Unfortunately, I think taking your proposal as written to a vote would be a strategic mistake. Although the circumstances have changed somewhat since the original abortive proposal for crossing:signals=*, your proposal amounts to only a refactor of the tags. It’s a refactor I would welcome wholeheartedly, but it’s vulnerable to criticism from mappers who cling to the old crossing=* tags for simplicity or nostalgia. If you believe strongly that crossing=* needs to go away, then let’s clean up this proposal to introduce a meaningfully superior crossing:signals=* key (even if the superior elements don’t benefit you personally); then it will be more apparent to the community why deprecation is warranted. Staging the proposals in this order will reduce the fallout from a vote that fails for some reason. – Minh Nguyễn ^💬 16:09, 28 November 2022 (UTC)

Proposed features/Highway crossing cleanup wound up going to the RfC stage independently of this proposal. Unless things change decisively in that proposal's favor, I'm going to consider deprecation out of scope for this proposal. – Minh Nguyễn ^💬 04:15, 1 December 2022 (UTC)

---

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

values other than yes and no

To be honest, I do not really understand the other values other than yes and no. Do they matter? Why? --Westnordost (talk) 20:16, 29 June 2023 (UTC)

Yes, they are different. One of the complaints against crossing=traffic_signals is it being used when there are no pedestrian signals, only vehicular signals. Although crossing:signals=* itself improves on the implication, there can still be further clarifications. --- Kovposch (talk) 05:11, 30 June 2023 (UTC)

@Westnordost: I added some diagrams to the "Tagging" section to hopefully explain the situation better than I could in words. Let me know if I need to adjust anything to avoid confusion.

The distinction between vehicular and pedestrian signals is relatively significant in the U.S. Studies on the safety impact of pedestrian signals overall have been inconclusive in terms of the number of injured or killed pedestrians [1], but every element of a crossing – curb ramps, signage, markings, dedicated signals – can potentially contribute to pedestrian safety, depending on the situation. In some regions, each of these treatments is completely optional; highway departments have to prove they're necessary [2] and even have to prove that installing them won't inconvenience motorists. [3]

A pedestrian router could factor these tags into a profile that optimizes for low-stress routes without overstating the safety benefits. Eventually, I'd like to also introduce tagging for other aspects, such as the countdown time and leading pedestrian intervals [4][5], which could only make sense if we have this level of detail too.

 – Minh Nguyễn ^💬 00:11, 5 July 2023 (UTC)

Potential confusion from separate/shared

Figure 1: Types of foot and bicycle signals

Pedestrians and cyclist share a signal

Pedestrians and cyclists have separate signals

My first impression of crossing:signals=shared was that the signals have shared signals for bicycles and for pedestrians while crossing:signals=shared have separate signals for bicycles and pedestrians crossing the road. While for me its not a huge issue, but perhaps another tag name could be better to avoid this confusion in the first place. See Figure 1. (Note that this is in the context cycle/footpaths crossing a road. On street cycle lanes with separate bike signals are not `highway=crossing` in the first place.) --Popball (talk) 19:37, 30 June 2023 (UTC)

I was about to write on this. I mentioned traffic_signals:*=* for traffic_signals:sound=* and traffic_signals:vibration=* etc above. The in-use traffic_signals:bicycle=* and traffic_signals:foot=* (there is also traffic_signals:motor_vehicle=* perhaps for separate bike and motorized vehicle signal) may not be good enough, as it seems unable to unhandle mixed traffic or bike lane on the road being crossed. Besides, traffic_signals=* have special details for *=blinker , *=blink_mode , etc, that may be extended to crossings.
I thought about *way:traffic_signals=* yesterday. Proposal:Crosswalk_clean-up#Traffic_control
That being said, you may still have some *:bicycle=shared . This doesn't show what it is shared with yet. A more complicated format would be to use eg footway:traffic_signals=* + footway:traffic_signals:bicycle=yes for bikes following pedestrian signal; or crossing:traffic_signals:bicycle=footway for my original idea (with crossing:traffic_signals=carraigeway v crossing:signals=shared for vehicular signal only), however this proposal pointed out *=all is not good.
I believe we should decide whether traffic_signals:*=* or crossing:*=* should be used fundamentally. Although crossing:*=* seems to be a obvious solution, signalization affects multiple modes including vehicles and bikes as seen here, and traffic_signals:*=* has merit to be consistent with traffic_signals:sound=* and traffic_signals:arrow=* widespread.
Other attributes to be considered:

• traffic_signals:countdown=* (how to indicate for pedestrian and vehicle separately?)
• traffic_signals:minimap=* (has other probelsm)
• traffic_signals:detector=* (may apply to pedestrians as well)

Kovposch (talk) 09:44, 1 July 2023 (UTC)

@Popball and Kovposch: I think inevitably people will eventually want to micromap the signal heads themselves (man_made=traffic_signals?). This would absolve us of having to come up with just the right subkey for the different permutations of signals even before we have a consensus on how to deal with things like red turns. In that scenario, the most obvious tag on the crossing would be crossing:signals=separate, which would badly conflict with the separate definition that I've proposed here. This to me is the strongest argument in favor of a different value. Hopefully calling it something other than separate will allow us to kick the can down the road about these other considerations. I agree that they're all worth consideration, but I'm reluctant to weigh down this proposal with even more reasons for people who are content with the current tagging scheme to nitpick. – Minh Nguyễn ^💬 23:50, 1 July 2023 (UTC)

Renaming separate

I've liked the mnemonic that shared is shared between vehicles and pedestrians, while separate is a separate pedestrian signal head. However, I agree with commenters above that separate is problematic because of its association with sidewalk=separate, cycleway=separate, ramp=separate, etc., which are meant to contrast with the very kind of tagging-the-related-feature mapping that this key is all about.

So far, dedicated has been proposed as a replacement. That would preserve the mnemonic, since "dedicated pedestrian signal" is even more memorable. There is also precedent in smoking=dedicated (which contrasts with... smoking=separated) and parking:placement=dedicated in an old, deprecated syntax for street parking. However, crossing:signals=dedicated would not be without its own confusion. For example, Key:religion#Values for religion describes a dedicated_to=*, and there is some usage of dedicated=* and dedicated:wikidata=*. This makes me suspect that some mappers read this word as "has had a dedication ceremony". As I mentioned above, we also have way too many "de…" and "d…ed" words as values.

I think I can live with dedicated, but just to make sure we end up on vocabulary that we can live with, here's dedicated along with some other possibilities:

The crossing user approaches the crossing and waits for the…

Vehicular signal	Pedestrian signal	Cyclist signal	Equestrian signal	Tram signal	Notes
shared	separate			N/A
shared	dedicated			N/A	Consistent with smoking=dedicated
vehicular	non-vehicular			N/A	But horses are considered vehicles in some places…
vehicular	pedestrian	cyclist	equestrian	N/A	Per-mode values seem redundant to highway=*; now we have to think about bike+ped signals too…
vehicle	foot	bicyle	horse	N/A	Will lead to nitpicking about legal access restrictions
go?	walk	cycle?	ride?	N/A	Consistent with traffic_signals:sound=walk and everyday English but otherwise kind of tacky

Whatever we decide on, we'll have to retag the 900 or so existing occurrences of crossing:signals=separate, 85% of which are my doing.

 – Minh Nguyễn ^💬 22:34, 4 July 2023 (UTC)

That's why I thought about *way to focus on the side of crossing. Avoids issues with using individual modes. If bikes goes through a sidewalk, there's footway . If bikes or horses ride in mixed vehicular traffic, it could be carriageway .
If pedestrians and bikes share explicitly, maybe path if acceptable, probably not. That's the problem in example 1 File:Wien,_Marienbrücke,_Ampel_--_2018_--_3063.jpg https://goo.gl/maps/wtcrBDsWzgmutxSe6 using a combined light for both the sidewalk and sidepath. So that's the limitation of single val. Worse, there's even a bike (?) left-turn signal. Reminds me of traffic_signals:turn=* , which uses traffic_signals:turn:bicycle=* for bike lanes.
One easier solution is to make crossing:signals=dedicated default to meaning crossing:signals:foot=dedicated / footway:*=dedicated . Use crossing:signals=dedicated as the standard, only adding crossing:signals:foot=* and crossing:signals:bicycle=* as needed, ie crossing:signals:bicycle=shared here. Unfortunately, this is still not clear what it is "shared" with, with pedestrians or vehicles.
Another hacky solution is crossing:signals:segregated=* , if such terminology can be used. Concern is it being an "unsegregated" signal for segregated sidepath/crossing. On the contrary, apparently "shared" toucan signals can have split lights File:Toucan_crossing_red_aug_2021.jpg ie "segregated" signal for unsegregated crossing. Remains to be confusing and unsatisfactory.
@Popball: I'm thinking if we can ignore the issue by posing crossing:signals=shared as external, not how the crossing signal is "shared" or "dedicated" internally. The light indication don't matter, only the side on crossing or road.
@Minh Nguyen: Or *=shared can be changed to *=mixed , and *=dedicated to *=exclusive ? This may be confused with unprotected and protected crossing though.
--- Kovposch (talk) 06:31, 5 July 2023 (UTC)

@Kovposch: Thanks for these additional insights. I mused about some per-mode options in the table above, but I'm not certain they're necessary, because they don't add information beyond what's on the parent way, and a signal shared between two modes becomes awkward anyways. I think edge cases like bike+ped and segregated toucan signals will eventually solve themselves, once we become accustomed to mapping highway=traffic_signals nodes at the "stop lines" of inbound sidewalks and mapping man_made=traffic_signals nodes at the signals' physical locations for good measure. However, I'm not ready to propose that yet. I'm focused on this vehicular/pedestrian signal distinction because it can and often does result in different timing intervals and a different "level of stress", which would be concretely valuable for routing, not just for the most detail-oriented of renderers.

The issue I see with mixed is that it could be misused to indicate mixed signalization on one side of the intersection versus another, or across one carriageway versus another, by mappers who use one closed way to represent all the intersection's crossings. (This isn't a good practice in my opinion, but it is fairly common.) I agree that exclusive would likely be misinterpreted as protection from turning vehicles – which is enough of a misconception among pedestrians that highway departments sometimes put out reminders that pedestrian signals don't necessarily offer this protection. The most elegant terminology I can think of would be what I've been using in prose: vehicular and pedestrian. However, I'm concerned that it would lead mappers to nitpick about, say, an equestrian signal counting as a vehicular signal because horses are legally classified as vehicles in some regions.

 – Minh Nguyễn ^💬 07:32, 5 July 2023 (UTC)

I wanted to minimize new keywords, and avoid using different word forms ( vehicular vs vehicle ) to distinguish.
How will it allow solving shared bike & ped light later though? After all, it's more likely to have confusion about bikes being treated as vehicles, than horses. So it's worth considering.
--- Kovposch (talk) 10:09, 7 July 2023 (UTC)

@Kovposch: Yes, that's exactly the downside to vehicular and vehicle, that mappers would associate it with an access restriction when all it refers to is a hardware category. So after considering these options, I can't think of a better one than shared and dedicated. – Minh Nguyễn ^💬 23:24, 7 July 2023 (UTC)

Verifiability problem with shared/separate

You write

> A task-based editor like StreetComplete could ask whether a crossing is signalized, offering a "Don't know" option. A followup question could ask which signal head pedestrians must obey at the crossing.

I understand that you imagine that the depending on the users' answer to that follow-up question, "shared" or "separate" is tagged. This is an issue because this question would go against the quest guidelines.

> Users are no experts: No knowledge about OpenStreetMap or any other background knowledge must be necessary

This includes traffic rules. This is also why StreetComplete does not ask its users to enter the default maxspeed if there are no signs.

Europeans not acquainted with US traffic legislation that see this crossing would think that there are just no pedestrian traffic lights (and thus other rules would apply, depending on whether the left road is a priority road), hence give a wrong answer to that follow-up question. No, actually, "clueless" Europeans will not even get to that follow-up question, because when asked whether that pedestrian crossing has traffic lights, they will just answer "no". And that would be wrong already, by what you propose. (So, in a sense, the definition of the in-use tag crossing:signals=no would be changed implicitly by introducing shared/separate values) (Every US state has its own traffic legislation. Couldn't it be that even Americans from some states could be "clueless", because in their state the lack of dedicated crossing signals for pedestrians means something different?)

So, I think this is a general verifiability problem with these extra-tags. They mix in knowledge about legislation into what is there on the ground. Meaning, a question in SC would need to be "Are there any traffic signals at this intersection that pertain to people [i.e. pedestrians but also cyclists] using this crossing?" instead of "Are there traffic signals at this crossing?".

I'd prefer if we recorded just what's on the ground, i.e. recorded whats physically there. So in the picture, it would be crossing:signals=no for that particular crossing. What the lack of dedicated crossing signals for pedestrians (at a crossing that otherwise has traffic signals) then implies according to legislation is nothing I would expect to see tagged in OSM, unless it is explicitly signed (i.e. its not the default whatever is valid according to the law).

Now, I understand that this would make it harder for data consumers to determine if any particular crossing is governed by (nearby) signals or not (at least in the US and countries with similar legislation). I can offer no good solution to this - at least none where I would think it is worth the effort and reasonably simple / non-error-prone to maintain --Westnordost (talk) 22:01, 1 February 2024 (UTC)

@Westnordost: Thanks for the additional perspective. I acknowledge that the distinction I'm trying to make, however it's spelled, would be lost on laypeople from regions that don't have such distinctions. When I originally included this photo in Key:crossing:signals, Kovposch annotated it with a question about whether it would even count as signalization. The potential for confusion from armchair mappers abroad is one reason I believe we need a tag like shared.

The photo is taken from the vantage point of a pedestrian standing on a sidewalk along Clay Street, about to cross Wayne Street when there's a green light. But what you can't see is that there is also a traffic signal to the left, out of view, that controls traffic going eastbound on Wayne Street from right to left. When the signal for Clay Street turns red, the unpictured signal for Wayne Street turns green. I expect that a StreetComplete user would turn their head to see the full situation, unlike an armchair mapper suffering from tunnel vision as they look at a street-level photo.

Vehicular signals at a four-way intersection

The one traffic law you need to know is that green means go – that is, if Wayne Street is being told to go, then you on Clay Street must stop. This is one of the few traffic laws that is totally consistent across the 50 states, and I'm pretty sure it's consistent with the laws in Europe as well. I think the diagram at right illustrates the situation better than the photo, but I included the photo so that readers wouldn't think I'm making this up.

I would support a local community's decision that yes and no are good enough for their country. However, I disagree that even a clueless European visiting the States would fail to pick up on the meaning of the vehicular signals at an intersection – mainly because they won't make it back to Europe in one piece if they don't learn very quickly. Perhaps StreetComplete could avoid confusion by asking whether the crossing is at an intersection with either vehicular or pedestrian signals. You can include and pictograms for clarity.

As it stands, I am not in favor of applying crossing:signals=no to one of these intersections. This is too literal an interpretation for no tangible benefit. We might as well tag physical signal heads themselves instead of what they control (map the signs).

 – Minh Nguyễn ^💬 02:38, 2 February 2024 (UTC)