The problem is that it’s still needed, it is there, it holds a lot of information, it still has support with mappers and data users. Calling it deprecated does not remove that.
Also, if (eventually) the markings element is out of the key (ie completely replaced with crossing:markings=… and/or crossing_ref=*), the crossing key will only represent traffic light control, thereby removing the need to move to crossing:signals=…
The support doesn’t change. Data consumers can do whatever they want. If they already supported crossing=*, I recommend them to support both schemes until the usage of the old one narrows. The point is that it could be slowly changed to the better scheme. If someone mapped crossings a certain way in a local area, they could maybe do a semi-automated edit updating the tags exactly how they view the previous tagging relates to the new scheme.
I’m not sure what you’re trying to say. We want to deprecate both usages (and other ones like island also).
The major issue with the crossing key is that it mixes several different aspects in an utterly inconsistent way. Take the markings aspect out, and you have only one aspect for the typology in the crossing key: whether or not the crossing is controlled by traffic lights. With the inconsistent mixed use removed, why would one support deprecation of the remaining values (no, uncontrolled, traffic_lights) or even of the key itself?
No, for a few reasons:
crossing:signals=separate and =shared which would be an addition on top of more general value of =yes.I personally agree with all four points, but that’s not the problem. The issue is how to get things done. From that perspective, less is more.
The counterarguments:
I expect these (and comparable) arguments to block effective cleanup. I could be wrong, of course.
That’s just making a strech and using the crossing tag only for the sake of using it. Why not use crossing:signals, especially if your version still requires implementing a totally new tag (which is also kind of ambigous – controlled by what?).
And it has to be based on something. Here using the presence of traffic signals is rather arbitrary and conflicting with the idea of using crossing=zebra, for instance.
It’s unnecessary to have overlapping tags like this and we usually try to stay away from them when creating new OSM tags. There is a need for overlap if the key’s name changes based on the other tag’s value.
But why wouldn’t markings be more important? This subjectivity is part of the reason why the crossing=* tag shouldn’t be used.
This discussion is rather pointless by the arguments I showed. crossing:signals=* started being used for a reason. In case somebody has similar issues, they can read this thread.
Seeing the votes on the previous proposal, I think this one will only get more votes of approval but I guess we’ll see.
I’m waiting to get subscribed to the mailing list to restart the RFC and after 2 weeks we can begin with the voting process.
That’s fine by me, as long as mappers at least use yes when there’s no pedestrian signal head so pedestrians wait for the main vehicular signal head instead. One mapper briefly stealth-edited the wiki to say it doesn’t count as a signalized crossing. This was incredibly misleading and pedantic. I suspect they were simply unfamiliar with the configuration and would quickly agree with yes if they ever saw it in person (or got injured by their assumption).
As long as adopting crossing:signals=yes/no doesn’t preclude more specific values such as shared, I have no objection to promoting the crossing:signals=* key further. But then I don’t know what else we’re waiting for. This id-tagging-schema PR is stalled because of feedback that crossing=uncontrolled/traffic_signals is somehow cleaner and more efficient than crossing:signals=yes/no. Obviously I disagree because that approach prevents us from extending the tagging scheme further, and also because it looks absurd.
On the other hand, I avoided breaking out a separate proposal for just the Boolean crossing:signals=yes/no values in isolation, because on their own they’re vulnerable to the critique about changing tag syntax for no tangible benefit. Does this mean our only option is to take the full crossing:signals=* proposal to a vote?
Both crossing=traffic_signals and crossing:signals=* enjoy substantial support among slightly different sets of software packages. The fragmentation means that mappers technically must add both tags to get the desired behavior everywhere. This creates a potential for mixed states, compounded by the still-widespread practice of mapping a crossing as both a way and a node simultaneously.
Well the proposal doesn’t say anything in terms of that. What mappers should do is just use the proposed crossing:signals=shared scheme. Even most basic data consumers should be treating any value other than no just like yes if they don’t support those other individual values.
To he honest, I’ve never seen those shared traffic signals in real life. I live in Europe so it might be very rare for those to occur here. So I’d suggest for the value of yes to be used instead of separate and shared would be its own value. Just because I think it’s unnecessary to change the whole scheme in the rest of the world where shared lights are uncommon.
This is why I want a deprecation – because it will be a very good reason for developers of editors to finally accept the new scheme. If they somehow still decide to oppose it, it will be even more scandalous than the busway situation. But I think it’s unlikely because they already support crossing:signals.
I think this version of crossing:signals is fine. It already has quite a bit of support so it’s not just a negative change. It also allows for the other crossing:signals proposal to be just focused on adding new value(s) to the key.
The proposal uses yes to indicate that there’s some signal but we haven’t specified which one the pedestrian waits for. This kind of ambiguous state is useful for something like StreetComplete, allowing it to break up a quest into multiple simpler questions.
I’m wary of assuming that pedestrian signals are the normal “default” way to control a pedestrian’s crossing movement, since the shared configuration is so commonplace in the U.S. and presumably less developed countries. The risk is that a European armchair mapper unfamiliar with this possibility would jump to conclusions, saying no just because yes means something specific to them that they don’t see in street-level imagery or in shadows in aerial imagery. This is my takeaway from how European mappers reacted to the examples I posted on the wiki.
That said, is there any precedent for crossing-related tags to have three-way options for “yes”, “no”, and “yes with caveats”?
That’s is up to interpretation though. It could also mean that there is a signal present at the very crossing. I understand that yes is usually the unspecific value but in this case there is an option to view shared lights as lack of signalization at the crossing. This is why I think shared would work better as an option different from yes instead of a suboption. Also separate sounds like the traffic signals are mapped as a separate object which is misleading.
This issue is fixed by having the shared value available, doesn’t matter if separate is also a value or not.
I suggest writing stuff about crossing:signals=shared on as many wiki pages as needed since there isn’t even a need for approval. But we can work on the proposal right after this one still.
I agree. I got stuck trying to come up with better terminology. Your suggestion is to not bother with a separate value, which does skirt around the issue.
This assumes the user is presented with a set of options to choose from, but many mappers still choose to map without the benefit of presets and GUI fields (think JOSM).
Note that a vote with many yes and no votes usually means there is much opposition and discussion, even if the threshold says it’s approved.
Personally, I’m done with crossings. Most crossings are sufficiently
represented by the node where a path crosses a road or a higher order path, needing no tags at all.
I have one request outstanding with a renderer for displaying zebra’s at high zoom levels, and I may get a new update of all zebra’s in Nederland detected from aerial photography, which we will process to check and set the crossing:markings=zebra tag. Challenge there is true removals vs false negatives. Of course, the official data set has different filters, which means a lot of OSM-zebra’s are not in the data set, but they are not removals and should stay in OSM.
Visible zebra marking is a good reason to add highway=crossing and crossing:markings=zebra to the crosing node.
This is moving the goalposts to something like the English Wikipedia’s consensus process. In theory, administrators there close debates weighing the relative strengths of arguments given by either side and declare no consensus (no action) if both sides reach an impasse, regardless of numbers. In practice, you end up hoping the closing administrator is someone you ideologically agree with, and there’s usually a period of post-vote litigation.
If you think this is a model we should adopt, it’ll need to be a bigger discussion, not just something we institute ad hoc because the outcome was unexpected for some. Approvals can have caveats, like being so old that they no longer reflect current thinking, but the mere existence of outspoken opposition isn’t very decisive.
Hm, I just noticed the issue of inconsistency with other already used keys such as traffic_signals:sound=* which is left behind by crossing=traffic_signals. These tags should be ported to crossing:singnals:sound=*, etc. for consistency but that obviously comes with lots of issues with support.
dedicated has also been proposed. Does that seem less misleading to you?
And what about tags such as traffic_signals=bus_priority? Because those (traffic_signals=*) are also used on crossings about 11K times.
Maybe we should take some tags over from level_crossing? There is a tag crossing:light=*. Those could be used with a no, yes, shared/dedicated(?) value. Or signal:light?
And the sound and vibration tag can be changed to crossing:* or signal:* instead of traffic_signal:*.
Then we could also add signal:reason=bus_priority (not sure about a good sub-key for this).
The button_operated, sound and vibration are all in de facto state. If we want to change the way crossings are tagged, I think we should create a complete scheme where everything has somewhat the same layout.
And signal=separate should be an option I think, for mappers who want to map the pedestrian signals as a separate node on the physical location.
I suppose that’s a litte better but I still don’t see the point in having this be the value of 95% of the instances of the tag instead of yes. If there were more values than just shared then maybe I’d reconsider.
Hmm, if we wanted to port it over then the right call would be crossing:signals:bus_priority=yes.
Good point, there’s also the family of subtags for railway=level_crossing. I propose we merge them together as they behave similarly and some could be tagged on both pedestrian crossings and railway level crossings.
I don’t really like crossing:light=* though. The tag’s name seems like it should have a similar definition to lit=*. In my opinion those crossings should also use crossing:signal=* which fits better in every way.
Yeah, that would be crossing:signal:sound and crossing:signal:vibration. All of the values of traffic_signals commonly used on crossings should be ported over to crossing:signals:*=yes/no.
Yup, that I think that button_operated should also be moved to crossing:signals:button_operated because you can use the button to operate the crossing’s signals, not the whole crossing.
Thanks for pointing these out, in this case I’m not sure if it’s worth it to do any deprecations as of yet before making a full proposal standardising crossing:signals:*.
I guess this can be added on top of Proposal:Crossing signalization - OpenStreetMap Wiki
Edit: I see this has already been partially proposed Proposal:crossing:signals - OpenStreetMap Wiki so I suppose this proposal could be revived.
No, it’s just looking at the meaning of votes in OSM. It’s not a legal democracy where the majority determines the law. Many no’s means there are many objections, and less chance of success in the long run. I keep remembering the many rounds in the wood vs forest debates…
OSM tag keys are just identifier strings. It would be nice if they followed a consistent naming scheme, but there is very little benefit and a lot of downsides to deprecating and renaming a key just because it doesn’t fit nicely into a (new) naming scheme.
The meaning of traffic_signals:sound=*, etc… is just as clear as if it was called crossing:signal:sound=* and all that renaming it would do is to break data consumers.
crossing:signals=* is about the signals that a crossing user waits for. The various traffic_signals keys and tags are about signals that keep the main road users from running into crossing users.
crossing:light=* is different and indeed poorly named. A railroad crossing signal can occur at the very same intersection as a pedestrian crossing signal, but not necessarily, so we shouldn’t try to combine the two aspects. The poor naming is unfortunate but I’m willing to live with it, just as we cope with crossing:whistle=* in an age when actual whistles are rare.