Currently the wiki page for traffic_signals:countdown=* specifies that it is node (highway=crossing) only but I do not see why it should not be allowed on crossing ways. There has been a small amount of conversation about this in the US (mostly in PWG meetings) but it still remains unclear so I am putting this here so that others from across the world can comment. Obviously I would prefer if this is would be allowed on ways (highway=footway + footway=crossing) but I would like to see what other think on this. From how I see it, the crossing way when mapped separately should carry the information about the particular crossing that a pedestrian would need to know when traversing the crossing and whether the pedestrian has a countdown timer when traversing the crossing is important to the pedestrian and thus should be on the way.
For context, this came up as this tag is being considered to be added to the PWG schema in upcoming version 1.1 and in discussions this (in my opinion) discrepancy came up, I tried to figure this out on the OSMUS slack but that didn’t gain much traction so I putting this up here in hopes that this can be resolved.
I would expect this information on the highway=crossing node that is expected in both variants, with explicit crossing way and without.
If it is added to the PWG schema this would be on both nodes and ways, the wiki currently has it only on nodes (explicitly not on ways), the confusion is about ways. That is what I would like to figure out what the community thinks about, the idea is that it would be allowed on both ways and nodes vs the current nodes only. My explanation of “From how I see it, the crossing way when mapped separately should carry the information about the particular crossing that a pedestrian would need to know when traversing the crossing and whether the pedestrian has a countdown timer when traversing the crossing is important to the pedestrian and thus should be on the way” was primarily intended as justification for allowing it on ways, I’m sorry if that was not clear enough.
if it’s on the node it is also part of the way. I never understood why people are repeating all crossing details from the node on the way. Generally we had the approach that mappers should have it easy and data consumers should do the work if it can be done automatically. Putting all the same tags twice for the same crossing seems redundant.
On the flip side, tags like this could appear on the way but not the node when both are present. From the point of view of mappers who map crossing ways, the tagged node is mainly there as a stopgap for backwards compatibility. If mappers should have it easy, then the node would go away.
Maybe this is a conversation that could be started. I would be in favor of deprecating the crossing nodes when a crossing is mapped as a way. In the end, we are in a way duplicating crossings, which is not in the spirit of One feature, one OSM element - OpenStreetMap Wiki
Ok, I kind of disagree here, the highway=crossing does represent something, it just gets allot of tags tagged on it that probably shouldn’t be. From how I see it the crossing way represents the path the pedestrian takes through the intersection and the crossing vertex represents the crossing on the road network and thus is there for cars. So both should gets tags that are useful to both pedestrians and cars (like the fact that it is a crossing and crossing=*) (and other users of the road like PSV), there are some tags that are only useful (or only make sense (in my opinion)) to pedestrians and there is the same for cars. The tags that are only useful to pedestrians should go on the way and the tags that are only useful to users of the road should go on the node. From how I see it traffic_signals:countdown=* falls under the category of only useful for pedestrians as for pedestrians it can be important to know if a crossing has a countdown timer or not, but it doesn’t really matter to cars and other users of the road, but I do think that figuring out what goes on what is a larger issues that should be discussed separately. That is why I would much prefer to keep this on on whether or not traffic_signals:countdown=* should be allowed on ways as that would be a rather small change to make and larger changes will need allot more conversation.
I’m not so sure about distinguishing tags on nodes versus ways by intended audience. Markings are for both pedestrians and motorists, so we’d have to tag them redundantly anyways. In some jurisdictions, the pedestrian interval (WALK) and pedestrian clearance interval (flashing DONT WALK) aren’t necessarily protected from left turns. So the countdown can also help a turning motorist gauge whether they have a window of opportunity before another pedestrian enters the crosswalk.
To me, a stronger argument for allowing pedestrian signal tags on ways would be directionality. A given crosswalk could conceivably have a countdown timer in one direction but not the other. A way could express this mixed state using traffic_signals:countdown:forward/backward=yes.[1] A node would have no corresponding solution. Besides, traffic_signals:countdown=* already appears on some 7,800 ways, regardless of what the wiki “allows”.
As far as I know, the one crossing-related key that has different semantics on the way versus the node is tactile_paving=*. On the footway=crossing way, it means linear tactile paving runs along the length of the crossing, while on the highway=crossing way, it indicates that both street corners have tactile paving. In principle, the latter is imprecise and could be replaced by tags on the barrier=kerb node at either end of the crossing. As with the signal tags, this also allows us to indicate that there’s tactile paving at one corner but not the other.
Maybe someday it’ll be more normal to map a traffic signal node at each street corner and that’s where traffic_signals:countdown=* will go…
In fact, I had previously tagged two crossings that appeared to be signalized in one direction but not the other. But in both cases, it turns out I missed one of the pedestrian signals in street-level imagery. ↩︎