> 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.
I agree, this is the central issue behind the tags being non-orthogonal: crossing=* implies the "type" of crossing whereas the values often describe (or are interpreted as describing) a "construction kit". The crossing "is a" type (unmarked, uncontrolled, traffic_signals) vs. "has a" properties (markings, signals, etc). I'm open to the idea of crossing:markings=yes/no/* rather than crossing=marked/unmarked. > 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. I agree that deciding the "type" to be markings is semi-arbitrary and acknowledge that many think concepts like signals or "controls" take precedent. These two proposals could have gone with crossing=traffic_signals/unsignaled + crossing:markings=yes/no/* and still solve the core issues. > 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. I tend to prefer least-resistance / compromise options, and this sounds like it's in that direction. If I'm understanding it right, these would be taggable: crossing=unmarked/uncontrolled/traffic_signals/no crossing:markings=yes/no/* crossing:signals=yes/no/* One downside to allowing both approaches is the amount of redundancy in tagging crossings: not only do we tag both the node on the street and a way (if available), we can be tagging something like crossing=traffic_signals and crossing:signals=yes/no/*, crossing:markings=yes/no/*. Personally, I would never map or consume crossing=traffic_signals because it's frequently unknowable what the mapper intended, so we'd have a system of competing standards. I would also be tempted to convert crossing=* into the crossing:* namespace tags whenever possible, due to the many problems listed on these proposals. But, for the sake of having an option, what do others think about this approach? New subtags for markings/signals, old tags still allowed? On Wed, May 22, 2019 at 8:39 AM Tobias Knerr <o...@tobias-knerr.de> wrote: > 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 > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
