Refactor crossing presets

[arch0345]

This PR is an attempt to simplify crossing presets. As explained in this thread on the OSMUS Slack, the current options for crossings can be quite confusing.

I've made specific crossing presets with crossing=* tags unsearachable, with the only searchable options now being Crossing, Pedestrian Crossing, Cycle Crossing, and Cycle & Foot Crossing. I've also introduced a preset for path=crossing

[github-actions]

🍱 Preview the tagging presets of this pull request here: https://pr-1044--ideditor-presets-preview.netlify.app/id/dist/#locale=en.

[tordans]

Note to self: Read up on what the matchScore does when the preset is unsearchable? I assume it can be removed...

[arch0345]

I believe matchScore is also used to tell which preset name should show up in the feature menu when two presets have similar tags (ie Cycle Crossing and Cycle & Foot Crossing)

[1ec5]

For context, every now and then a less experienced mapper asks what the difference is between a “Pedestrian Crossing” and a “Marked Crossing”, especially since there’s also “Pedestrian Crossing With Traffic Signals”.

This change will continue the progression in #837 and #889. Reducing the number of “Crossing” presets will allows mappers to rely on the recent preset list without each slight variant of a crossing pushing another preset off the list.

For those who have become accustomed to the more specific presets, the loss of these presets may add to the number of clicks required to fully tag a crossing, but I don’t expect it to lead to a noticeable decline in tagging crossing details, because iD already has rendering rules and validation rules that encourage applying crossing subkeys. There has never been a fully complement of specific presets for styles of railway crossings, but crossing:* is very commonly tagged on them, maybe even more commonly than on pedestrian and cyclist crossings.

With this change, it’ll also be more straightforward to create regional variants of a smaller number of presets. #1030 only had to touch some templates, but some regions have well-known names for specific crossing configurations that go well beyond markings. It’s always been difficult to support these configurations because of the sheer number of crossing presets.

[tordans]

@Bonkles I think I remember rapid has a shortcut to cycle through crossing presets. (Or maybe this is facebook/Rapid#1154?) — Will this update to the preset affect this feature?

[bhousel]

Will this update to the preset affect this feature?

Yes this is facebook/Rapid#1154 / facebook/Rapid#1160
It is still under development, but when finished it will cycle through whatever the presets are, as identified by their presetID.

If the presets change, we can always override them, per facebook/Rapid#1182 - don't worry, I'm paying attention and thinking ahead 👍

[tordans]

@bhousel

when finished it will cycle through whatever the presets are, as identified by their presetID.

Great, it looks like those can be specified regardless of their searchable status so the changes here will not conflict.

[tordans]

FYI the next iD Community Meeting is earmarked to talk about the crossing presets https://wiki.openstreetmap.org/wiki/ID/Community_Chats/2024-02-28

Can you join @arch0345 @1ec5 so we can maybe get topic untangled?

[1ec5]

Unfortunately, I probably can’t make it at that time due to a conflict, but I think folks know how I feel about the various crossing tags by now. To clarify my comments in streetcomplete/StreetComplete#4886 (comment), I continue to think additional, non-Boolean values of crossing:signals=* would be worthwhile, but those values would benefit from a proper community discussion or vote. In the meantime, a checkbox would be fine; iD is perfectly capable of showing the raw value when it’s something other than a Boolean.

[tordans]

After #1201 was merged the presets for crossings should be structured better. This draft has now too many conflicts to be worth resolving. I would also suggest that we try to work with the new – hopefully complete(?) – setup of full presets for a while to see if that works better.

Personally I am open to the idea of this PR – as I understand it – to only show one crossing preset (searchable) and have detailed presets selectable in a second step as a field.

I will close this now but am happy to reopen.

[tordans]

One part of this PR was to add the crossing:signals to the presets which I did in a follow up PR #1203 of the now merged crossing refactoring. ==> Please have a look at #1203 and the open questions given there.