Add crossing:signals field to crossing/*traffic_signals presets

[tordans]

This is based on top of #1201 and should only be merged after that was merged. For that reason it is marked as a draft for now. I will rebase here in case #1201 changes. — Update: Since #1201 was merged this is now rebased and ready for review.

---

This PR adds the field and add the addTags part.

This follows the conversation during the iD Community Meetup to consider adding the tag due to the usage in StreetComplete, Routers and the general impression that the crossing:signals=yes tag is widely "in use" and accepted.

---

Closes #1118

Note: This change was also part of https://github.com/openstreetmap/id-tagging-schema/pull/1044/files#diff-b8505be38bbc0be40512bf63c04d79f36f8826808ba4f0c06f186527eddcc7b4

[github-actions]

🍱 You can preview the tagging presets of this pull request here.

[tordans]

Testing

Looks good.

For a crossing node with just crossing=traffic_signals + highway=crossing the addTags dialogue shows up as expected:

Follow up

• Cleanup the addTags to only include the tags that are not already part of tags. Which makes it a lot easier to read and maintain.

Open question…

• Do we actually want a field for this? Because the field allows to remove the "yes" value, which triggers the yellow update box (again). I think we shoudl remove the field and rely on addTags to add a tag that is only visible in the full tags part of the sidebar.
  • 

[tordans]

Next steps

• - Wait for Crossing refactoring #1201 to be ready/merged
• - Double check with Refactor crossing presets #1044
• - Decision on the open question (to not include a specific field, just use addTags)

[Dimitar5555]

If a crossing is already tagged as crossing=traffic_signals, this implies that there are signals present at the crossing. Adding crossing:signals=yes alongside crossing=traffic_signals feels redundant, as it doesn't provide any additional valuable information.

If the goal is to eventually phase out crossing=traffic_signals and replace it with a combination of tags such as highway=crossing + crossing:signals=yes, then this should be clearly stated and discussed in a proposal.

In my opinion, the focus should be on maintaining clean and efficient tagging, and crossing=traffic_signals alone already conveys the necessary information about signal presence. Adding another tag for the same purpose could cause confusion and dilute the clarity of the tagging scheme.

[tordans]

Just for reference: The draft of the proposal on this tag https://wiki.openstreetmap.org/wiki/Proposal:Crossing_signalization#Rationale

---

Lets see if we find any reason to go along with this at this point … – I am happy with benching it for the time being.

[matkoniecz]

@tordans

I am happy with benching it for the time being.

would that mean you are fine with closing this PR?

@1ec5 do you plan to go forward with https://wiki.openstreetmap.org/wiki/Proposal:Crossing_signalization ?

[1ec5]

do you plan to go forward with https://wiki.openstreetmap.org/wiki/Proposal:Crossing_signalization ?

I really want to take it through the proposal process, but I’m not confident that I’ll have time for it in the next couple months.

To be clear, the key can stand on its own regardless of this proposal. By the time I drafted the proposal, crossing:signals=yes/no was already effectively in use at about 5,000 occurrences, based on an earlier proposal from 2019. Now at nearly a million occurrences, it’s practically a de facto key, the third most common crossing:*=* key. It’s already supported by multiple editors, and more routers support it than some other crossing-related keys that id-tagging-schema does include. The purpose of the proposal, then, is to address lingering misconceptions about crossing signalization and align on additional values to distinguish the walk signal from the go signal. (As always, naming is the hard part.)

[matkoniecz]

If the goal is to eventually phase out crossing=traffic_signals

I believe that is the point of crossing:signals=* - problem with crossing was trying to express multiple orthogonal things in one key and doing it in quite confused way

In my opinion, the focus should be on maintaining clean and efficient tagging

using crossing for multiple different things is an exact opposite of that

I really want to take it through the proposal process, but I’m not confident that I’ll have time for it in the next couple months.

has it changed now, few months later?

If the goal is to eventually phase out crossing=traffic_signals and replace it with a combination of tags such as highway=crossing + crossing:signals=yes, then this should be clearly stated and discussed in a proposal.

I agree with this one and going through proposal would make changes like this safer, so I will snooze my review of this PR for few weeks

[1ec5]

I really want to take it through the proposal process, but I’m not confident that I’ll have time for it in the next couple months.

has it changed now, few months later?

The only update I have for now is that there was another discussion recently in OSMUS Slack about replacing separate and shared with less confusing keywords. I left a comment on the talk page to that effect.

To reiterate, crossing:signals=yes/no is already quite well-established. It’s easily the third most popular crossing subkey despite the lack of support in id-tagging-schema. The proposal is about extending the set of values to clarify a particular regional edge case. If it goes through, this PR would need some changes: the Crossing Signals field would go from a checkbox to a combo box, and some of the presets would need to potentially account for more specific values than yes. This wouldn’t be so complicated if we would stick to a single generic Pedestrian Crossing preset without so many specialized crossing presets.