Hi all,
I wrote an overview of what is wrong with the current way we map crossings.
In concreto, I would like to:
traffic_signal-nodescrossing_refcrossing=marked|unmarked|controlled|uncontrolled|zebra alltogetherAny idea?
It’s all very well saying you’d like to deprecate it, but what do you propose as a replacement to allow data consumers to differentiate between the UK’s pelican, puffin, toucan, pegasus, zebra and parallel crossing types? These probably ought to have a country code prefix, but you need a more developed proposal than “this tag isn’t useful in my country, therefore get rid of it everywhere”.
No problem there. It’s been so thoroughly skunked by iD and Rabid tag “upgrades” that it should go. [EDIT: although you’d need to know how data consumers process the tag and discuss alternatives before consigning it to oblivion.]
Agree with @rskedgell. You should keep in mind, in some countries the paint on the road is just paint on the road (aka you just want to map it, so a renderer can draw a realistic pattern) and in other countries there are different rules and they are indicated eg. by the paint style (and other things).
I would think you also want to add some words behind, which information should be added to the crossing way and which information should be available on the crossing node. For me it doesn’t make sense to tag duplicate information.
Like the painting on the road would belong to the crossing way, as well as all the access. Other crossing specific regulations might be added to the crossing node. Like all the uncontrolled/traffic_signal/crossing_ref.
IMHO:
traffic_signals=separate). On the node intersecting the road and the crossing, at most highway=crossing should go. All other information is available in the more appropriate objects.crossing_ref indeed might indicate an ensemble of properties in some countries (such as the type of road marking + lights + …). Perhaps we should see crossing_ref as something that is only used in the UK and the US?
Maybe it’s a bit confusing.. Are you proposing to have those information on the actual crossing-node or at the location, where the traffic signal is? In your blog post it sounded more like on the crossing node, above more like a separate node wherever the physical traffic light is.
Reading through the details, there are a couple more things about which I’m more than a little dubious:
button_operated=reduce_wait_time and button_operated=fake raise problems with verifiability. When I press the button at the toucan crossing opposite my local station, which is part of a traffic light controlled three way intersection, it might feel like it hasn’t done anything, but I can’t prove it. I suppose I could send a freedom of information request to Transport for London and hope that they answer and that they release the answer under the Open Government Licence (NB there are no circumstances under which I would do this).
button_operated=broken if it’s short term, like a broken street light, I’d report it to the council rather than tag it in OSM. If it’s long term, I might use disused:button_operated=yes and a note or fixme.
If you have a requirement to update some crossing data in OSM, I’d suggest that you:
I absolutely agree that the combinations of tags used in OSM for crossings is an absolute mess, but I wouldn’t start by suggesting deprecations - I’d suggest by demonstrating that a simpler schema is possible.
What tags will you use
The crossing_ref can be replaced with crossing:markings, which has been in use for a few years now. Except in the US and UK, it is still valuable
IMHO, the other tagging is mostly fine, but should be put on different objects.
For an example, see OpenStreetMap , especially the cycleway going north-south next to the railway bridge.
I’d be surprised if you encounter many? In the whole of Belgium there are less than a couple of hundred (there are rather more values in use worldwide). If in Belgium a crossing_ref=zebra implies only crossing:markings=zebra and you say "I’m going to tag the new crossings that I add as crossing:markings=zebra, that’s absolutely fine and not at all controversial.
This is like step 14 or 15 in the evil plot to drive the crossing zoo animals to extinction. 
But yes, I think it’s inevitable that someday we’ll be talking very seriously about tagging pedestrian signals as first-class objects in OSM rather than merely alluding to their presence.
The tricky thing is where exactly to map the feature. At best, even highway=traffic_signals is located at the “stop line”, not the physical signal device, except in countries where the signals are mounted before the intersection. I sometimes micromap man_made=traffic_signals for informative purposes and even sometimes do that for pedestrian signals when they’re set back so far that another mapper might miss them. But I’m under no illusion that any software will use them.
So let’s suppose we map highway=crossing_signals at the “stop line”. Would that be at the curb, where a traffic_signals:direction=* tag would be ambiguous because of the transition between two highway=footway ways? Or would we set it back by exactly one step? I can just imagine an especially detail-oriented mapper quietly editing the wiki to codify a particular shoe size. And then someone will belatedly notice that it’s measured in Paris points instead of the British barleycorns that would be expected of a proper OSM tagging scheme.
So you can see why I settled for crossing:signals=* for now.
Some of these values have been skunked ever since the Potlatch 1 days, maybe even before my account was born, but back then we had only ourselves to blame for the mess.
If your crossing signalization proposal from 2022 were to be revived and developed, it’s something I’d be likely to make use of when mapping crossings.
crossing:signals=yes/no was already in use by 2022 (about 8,000 occurrences). These days it’s even more entrenched: about a million occurrences in the database, and more software support than most of the crossing=* values.
My proposal is mainly about the additional distinction between the 
walk and 
go signals. That distinction is probably less important on your side of the pond, but more global examples couldn’t hurt. As always, the holdup is just finding a pair of keywords that we can live with.
The tag which I feel would be useful here in the UK is crossing:signals=shared. We have some pedestrian crossings at traffic light controlled intersections which may even have crossing:markings=dots, lowered kerbs, tactile paving, etc., but no separate pedestrian signals, buttons, etc. From a pedestrian point of view, it could be useful to know that you may have to wait for the traffic signals to stop cars before you can cross safely.
I think crossing:signals=separate needs to be a bit more fine-grained. With older pelican crossings, the signal is on the opposite side of the road and above head height (crossing:signals=opposite?). With puffin crossings, it’s on the button box on your side of the road (crossing:signals=near_side?).
before you say something doesnt work, well, talk to people from other countries.
On say this example OpenStreetMap try to explain what is hard for you to understand there.
That’s the first thing that came to mind when this thread came up, talking about the physical locations of signals. When you brought this up previously, the part that I got stuck on was that the physical location of a signal is orthogonal to whether the pedestrian observes their own signal.
Here in North America, standard vehicular traffic signals are usually mounted over the middle of the intersection or over the far side, and frequently there’s an additional signal on the near side, off to the side. Occasionally, though, the overhead signals are mounted on the near side instead, similar to the norm in some European countries. None of these configurations guarantee a separate pedestrian signal head. If one isn’t available, the pedestrian observes the vehicular signals, whether they’re located on the near side, the far side, smack-dab in the middle, overhead, to the side, or all of the above.
I don’t think we should force a mapper to choose between indicating the physical location and indicating the traffic rules. After all, that’s how crossing=* ended up such a mess. The only reason I’m glomming the walk/go distinction into the same key as yes/no is that, otherwise, different mappers will tag the shared signal as yes or mistakenly as no depending on their personal familiarity with shared signals. This is similar to why traffic_signals:sound=* can be set to locate/walk instead of just yes/no.
Whenever a signal’s location is remarkable, I bust out man_made=traffic_signals traffic_signals=signal for each stop/go signal head and man_made=traffic_signals traffic_signals=pedestrian_crossing for each walk/don’t walk signal head. I’d suggest that approach to anyone who wants to micromap all the signal head locations in their neighborhood.
I haven’t proven it, but in my experience it’s always possible to reverse the ways such that it’s unambiguous.
Still, I agree that crossing:signals=yes is much better than traffic_signals=separate on the crossing way.
In the German forum, I’ve detailed my practice of tagging pedestrian signals. That reminds me, I still have a revert to do…
In the simple case, yes, though it gets tricky when a curb ramp meets two crosswalks forming a Y and that pattern repeats all around the intersection. (This is probably the most common configuration here in California.)
In Metro Detroit it’s quite common the traffic lights for the road are hanging across or even diagonal across the crossing and usually the posts are used as well for communication/electricity lines. So mapping the exact location of the traffic light will be quite challenging. As well it’s common that the button to operate the pedestrian lights is not mounted to the same post of the (opposing) traffic light. Sometimes, both buttons (for the two directions) are at the same post, sometimes each of them has a dedicated post.
I would think if you want to actual map all of that in the “correct” location, you will need to get creative with relations.
Thank you for bringing this up, @Pieter_Vander_Vennet ! I am all in favor of cleaning up this mess.
Your blog post is long and this thread will get long soon. I am afraid it will be hard to follow. I am a fan of images to help understand the text better. Could you please post an image of a simple crossing (lets say a footway crosses a street) with all tags you would put on which nodes/ways?
In Nederland, all crossing_ref=zebra crossings have been checked and crossing:markings=zebra has been added. We didn’t remove the crossing_ref tag altogether, because some mappers still believe it contains or could contain valuable information.
This couldn’t be that it’s a UK-type zebra crossing, we don’t have those, and we have no official list of named crossing types. It’s more like an “official zebra” with the appropriate zebra sign, while many zebra crossings are “non-official” zebra’s.
