[Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Tobias Knerr]

On 08.05.19 01:30, Nick Bolten wrote:
> Would it be fair to say you're suggesting something along the lines of
> crossing:marking=*, where * can be yes, no, or a marking type? You make
> a good point about the simplicity of avoiding a subtag for markings.

Yes, this is pretty much what I'm suggesting. And I believe it would be
an useful tag no matter whether we make crossing mapping fully
orthogonal or just mostly orthogonal.

Taking a step back to explain my thoughts on splitting off signals...

The core of the issue seems to be that there are two conflicting
mindsets: Mapping "types" of crossings versus having a "construction
kit" of several tags which each describe one facet of the crossing.

If we want to have "types of crossings" at all, it would be highly
unexpected to ignore the presence of traffic signals for that purpose.
And the crossing=* key clearly seems to be intended for mapping the type
of the crossing. That meaning is suggested by the name of the key
itself, not just the current set of values, so I believe it's
counter-intuitive to turn it into just one of several equally important
orthogonal keys.

What else could we do with crossing=*? In theory, we could just get rid
of it entirely, but realistically, that's not going to fly, and I'm not
even sure if it would be desirable. People _do_ tend to mentally put
things to categories, and describing the most common crossings with just
one tag is certainly convenient.

So what I would probably do is mix the two approaches instead of going
for a conceptually pure implementation. Use
crossing=unmarked/marked/traffic_signals
for a basic classification of the crossing's type, and then add
orthogonal subtags like crossing:island=*, crossing:marking=* etc. as
needed. It lacks the elegance of full orthogonality, but covers all
practical use cases.

Tobias