When a key has yes/no plus a number of other values, the common understanding is that all values besides no can be treated as yes if a data consumer doesn’t need the higher level of detail. In other words all the non-yes/no values subdivide the meaning of yes. The suggestion that yes and separate should have mutually exclusive meaning would deviate from this pattern.
1 Like
I guess the most direct precedent would be crossing:whistle=yes/optional/wayside, but there we avoided no because the lack of a requirement to sound the horn isn’t the same as a ban on sounding the horn.
I wouldn’t go that far with crossing:signal:*=. It just gets more complicated. Only crossing:*= or signal:*= is enough I would think.
Looking at the semantics, the button is for the signal, the sound is a signal as well as the vibration. The signal:sound for instance could be reused on another object where the meaning is a bit different without any issues. With crossing:*= or crossing:signal:*= we couldn’t do that.
And since the node or way already is tagged with *=crossing, it should be clear for users the signal is about the crossing. We also don’t tag highway:surface=*, just surface=*.
I think only one value of crossing:signals=* would be entered? A system were multiple can be true, wouldn’t be necessary in my opinion.
Exactly what is different here? A router needs to know if a pedestrian is crossing a normal traffic light or a traffic light which prioritizes busses (which probably would be green more often). Or if the light for a pedestrian crossing is standard in a blinking mode. Not seeing pedestrians as “main road users” is strange in my opinion. Also, on the wiki:
traffic_signals=pedestrian_crossing: A traffic light that only turns red to let pedestrians cross – and also in use forhighway=crossing+crossing=traffic_signalsto indicate the traffic signals for pedestrians. That means it has two different meanings depending on the context.
I understand but on the bright side it will be consistent with the railway level crossing keys.
In terms of support there isn’t as much of it actually. And those that do support it would just have to add this alternate scheme and that’s not too difficult. SC would only have to change the tag it adds.
There’s also values such as bus_priority or tram_priority which right now both could be tagged by using semicolons and from what I noticed people don’t really like to use semicolons.
More reasons were listed on the crossing:signals proposal.
You’re just talking about how it seems in theory but in practice it doesn’t have to be like that. And as I said before, a shared light might not exactly be a more specific value than yes but rather one that’s different or partially overlapping at best. The lack of another value and rarity of such places existing in the majority of the world don’t add more reason for dedicated to exist.
Normally I’m against prefixes like these and I’m a big hater of contact:* but in this case they’re necessary. What annoys me more than prefixes is the lack of consistency and that’s what we have right now with e.g. crossing:island and button_operated. Here it’s important to highlight that stuff like *:vibration is related to the signals, not about the crossing in general.
The crossing:* prefix however also signifies something – when there’s no prefix, the tag applies only to cars and road vehicles (e.g. traffic_lights=yes/no – per proposal, flashing_light) and features that refer to not only crossings (kerb, tactile_paving) whereas with the prefix the tags apply to pedestrians or cyclists (crossing:signals, crossing:continous) or both pedestrians and road vehicles (crossing:markings, crossing:island).
What could it be reused on? I’d say that this signal is exclusive to crossings, otherwise it would have a different name.
No, that doesn’t make any sense as the primary value of crossing:signals=* And as I wrote above, there could be multiple options like both bus_priority and tram_priority. I believe that other values could realistically be used simultaneously still.
In this scenario I’d consider the road users that have a far less chance of survival in a full-speed crash to be the ones who obey the crossing:* prefixed tags so that’s pedestrians on pedestrian crossings and cars on railway level crossings.
1 Like
I’m talking about an observed pattern. No, it is not a requirement, but there is value in following existing paterns for consistency’s sake.
When I say “pedestrian”, I’m specifically referring to someone crossing the street. They are traveling along the crosswalk, not along the roadway.
At this intersection, vehicular signals control road users while pedestrian signals control crosswalk users, hence highway=traffic_signals at the stop bar along the roadway but crossing:signals=yes (or separate or dedicated) on the crosswalk:
The same is true of a mid-block pedestrian signal (MPS) configuration, except that the vehicular signals only protect the crosswalk, not any cross street. This is more or less what highway=traffic_signals traffic_signals=pedestrian_signals means (apart from some regional variation in signal operation). That tagging combination belongs not on the crosswalk but on the stop bar, seen on the opposite side of the intersection in the following video:
On the other hand, in the absence of pedestrian signals, vehicular signals control both road users and crosswalk users simultaneously, hence highway=traffic_signals at the stop bars and crossing:signals=shared on the crosswalk. You probably aren’t familiar with this configuration, but it’s almost the norm in some regions:
A pedestrian rail crossing can be controlled by either a pedestrian crossing signal or a railroad crossing signal. The most obvious difference is that a pedestrian crossing signal typically defaults to the Don’t Walk phase, whereas a railroad crossing signal typically defaults to the off phase (allowing passage).
For routing, we need to consider both vehicular and pedestrian routing profiles. Some navigation applications warn the motorist when passing a crossing but don’t need to do so when passing a signalized crossing. Some pedestrian routers already use crossing:signals=yes to prefer the relative safety of a signalized crosswalk or to guess that it’ll take a little longer to cross the street there than if it were unsignalized.
A router shouldn’t assume that bus priority gives pedestrians more time to cross. But that kind of detail would be useful as part of a more general scheme for tagging signal phases and intervals.
For completeness, the following pedestrian crossing features level crossing lights, pedestrian signals, vehicular signals, and bus signal priority all at the same time. Meta recently removed any information about it being signal-controlled in order to “correct” the tags.
2 Likes
Okay, you might have convinced me that the distinction of yes and dedicated might be needed because it’s also common in Europe with the railway signals.
I’ve got a question regarding shared however – won’t a relation grouping the crossings (as well as the light(s), optionally) needed? Take a railway crossing for instance, you need two relations because there are lights dedicated to either side of the rail. I suppose both signals light on at the same time so this isn’t the greatest example. Let’s instead consider a crossing where there is a cycleway and footway which are separated from each other by a fence but there is only one signal head for both paths. Are each of these crossings’ signals dedicated or shared? If shared, a relation is required, otherwise it might be ambiguous for data consumers. If dedicated, then the tag is misleading.
I guess there might be some utility in that, but it’s a broader issue with traffic signal tagging in general. Data consumers can mostly get away with assuming the signals control the nearest upcoming intersection, but the heuristic can fall apart at complex intersections.
Maybe we could clarify that shared refers to the same signals as a highway=traffic_signals on a nearby parallel way? The main thing I want to convey is that there aren’t special signals explicitly intended for the crossing user, only a different signal that they implicitly need to observe. In the scenario you describe, the single signal is for crossing users only, so I would consider it to be a dedicated crossing signal, though I’m open to other ideas if it makes the tagging scheme more intuitive.
I considered implicit and explicit as alternatives to shared and separate, respectively, but occasionally there are signs instructing the crossing user to obey the vehicular signals, without changing the nature of the signaling:
I also considered exclusive as an alternative to separate, but I was concerned that people would mistake it for a protected signal phase, whereas the presence of a pedestrian signal head doesn’t necessarily mean crossing users are protected from turning vehicles.
And what about railway crossings? Should shared be used for those also? Or just yes/dedicated? Could a new value work in any way? Or maybe really there should just be a separate key for railway crossings (though I don’t like the name crossing:lights)?
In the case where both a road and its separately mapped sidewalks cross railroad tracks, all three would have railway=crossing/level_crossing nodes. These nodes would have crossing:light=yes if there are flashing railroad crossing signals. If the sidewalks have their own pair of crossing signals, I assume they’d have the same phases (and usually the same design) anyways. Otherwise, do we think there’s any risk of a mapper saying the crossing is unsignalized just because the sidewalk doesn’t have its own physical signal head?
I think the name of crossing:light=* is a little ambiguous but not a huge problem. After all, “crossing lights” is a common term for them. Touching that key would expand the scope of your proposal for little overall benefit.
1 Like
In this case I once again think it’s not necessary to have more than 3 values for crossing:signals:
no– there are no signals present at the crossing and pedestrians don’t need to obey any.shared– there are no signals present at the crossing but pedestrians need to obey the same signals as cars and road vehicles do.yes– there are signals present at the very crossing.
If everything is written and described well on the wiki and in templates in editors, it will work out and there won’t be any mistagging.
So what’s the plan now? Should the 2019 proposal be revived, the 2022 one soon after and then the deprecation?
1 Like
How would a mapper indicate that the crossing is signalized but they don’t know whether pedestrians have their own signal? This is not a theoretical concern. For example, here’s a typical signal-controlled intersection in Florence, Kentucky. The crosswalks are obviously controlled by some signal, since there are vehicular signals and the crosswalks cross the streets past the stop bars. However, from aerial imagery alone, you wouldn’t necessarily be able to determine that all the crosswalks have their own pedestrian signals with any confidence. (An intersection can have pedestrian signals in one direction but not in another.)
Can you spot the pedestrian signal heads?
This is already the best-case scenario for aerial imagery: 3-inch, leaf-off aerial imagery at a time of day when posts and poles are casting long shadows. Yet I’m only able to point out these signal heads because of street-level imagery:
Or the wonderful oblique aerial imagery that the state’s KyFromAbove program has released into the public domain:
Both resources are quite a luxury that we can’t expect everywhere in the world.
As of writing, these crosswalks are mapped only as highway=crossing crossing=traffic_signals nodes. Just a block away is another set of crossing=traffic_signals nodes, but those crosswalks use vehicular signals.
If we want to deprecate crossing=traffic_signals, then we need an equivalent tag to succeed it. The most obvious successor would be crossing:signals=yes. But if yes always means there’s a dedicated pedestrian signal, then such a migration would introduce incorrect data, completely undermining the new tagging scheme. Even if we refrain from a bulk migration of crossing=traffic_signals to crossing:signals=*, we’d still be unable to migrate an untold number crosswalks until we gain access to street-level imagery. In the meantime, mappers will be unable to tag crossing:signals=* on many crosswalks that are obviously signal-controlled.
3 Likes
I guess there’s no other way though I don’t like how it’s going to be the only value other than no in Europe.
Another thing I’m not a fan of is the name. I asked ChatGPT for some potential values and got: dedicated, independent, exclusive, own_phase of which independent seems like it would have the least cons. What do you think about it?