I am asking for your comments on this proposal:
https://wiki.openstreetmap.org/wiki/Proposal:Shared_green
thank you
Do you know if this is the same situation as the âflashing amberâ signal for drivers in Spain? It sounds like the effect is similar - as a pedestrian, you may have a green man, but you need to be aware that drivers may see a flashing amber which allows them to proceed through the crossing. Of course drivers are then expected to yield to pedestrians but that doesnât always happen depending on visibility and so on.
More on that situation here:
maybe, if this is refering to the regular amber traffic light for vehicles, I am not aware of the Spanish situation, in Germany there would be an additional amber flashing pedestrian light, in Italy they donât have these additional lights or at least not at the crossings I looked at.
Here is a picture (accelerated):
I know flashing amber signals which is covered under flashing_lights but what the OP means is that vehicular signals turn green at the same time as the parallel pedestrian signals. The opposite scenario are leading pedestrian signals where the lights for pedestrians turns green before that for vehicles (e.g. video by NJB).
Edit: Okay, I just watched the video a bit and it isnât entirely like what I described, instead itâs more like the American HAWK signal i.e. full stop at first, then giving way to pedestrians but allowed to go[1]. Still, it is a different thing because it more describes an orthogonal pedestrian crossing while both the proposal and the flashing_lights are for parallel pedestrian crossings.
Off-topic but the HAWK signal also is fairly overcomplicated in a typical American fashion. If any Americans are in contact with urbanists and planers, feel free to show them this for at least a âdo wrong, rightâ. â©ïž
1 Like
I very much support having this information in OSM, as I agree that such intersections have significant safety differences from those with pedestrian signals. Traffic lights without dedicated pedestrian signals, where pedestrians are expected to follow the green and red of the parallel vehicular lights, are not uncommon in the US.
I will point out though that this proposal covers a similar situation as another draft proposal by @Minh_Nguyen, which proposes formalizing crossing:signals. In particular, a green light without separate pedestrian signals would be crossing:signals=shared, whereas one with separate signals is crossing:signals=separate (although as pointed out in the wiki, dedicated might be a better value).
At first glance I think I like the other approach better, as it allows explicit tagging of when you have surveyed the intersection and found pedestrian signals. I guess you could tag shared_green=no under the logic of your proposal, but that feels less intuitive to me than refining a crossing:signals value from yes to something more specific. In any case, it would be good to clarify why you favor this new attribute key over that approach, and whether any value besides yes is valid tagging.
Also, a minor quibble, but the pedestrians share the other colors beside green too. Is there a reason you went with shared_green over something like shared_signal?
1 Like
Hm, my understanding of this proposal for shared_green is differentâŠ
I took âIt is not unusual, at least in some regions, that vehicles turning right share the green light with pedestrians who cross the street. These situations are more dangerous than places where green light is not shared with pedestriansâ to mean that this indicates cases where there isnât an exclusive signal phase when only pedestrians are allowed to be on the road. (So almost all signals in Canada & US â including most of those with crossing:signals=separate â would be shared_green=yes.)
Indeed the picture in the proposal shows a separate pedestrian signal.
1 Like
Right, I think it essentially corresponds to every crossing at an intersection that doesnât have a no turn on red restriction. Most of the popular tagging approaches for these restrictions, such as restriction=no_right_turn_on_red relations, are focused on road users rather than pedestrians. Since we donât have anything explicitly relating the crosswalk to the intersection, I could see some benefit in explicitly tagging the crosswalk with whether these conflicts are possible, though the suggested tagging is a bit counterintuitive to me, as someone who usually maps in jurisdictions where turning on red is the norm.
Pedestrian leading intervals are also quite popular in the U.S. You find HAWK signals complicated, and many motorists do too, but theyâre for mid-block crossings where a conventional signal with a pedestrian leading interval would defeat the purpose of installing a signal. Green means go when going straight; it never means yield.
As discussed on the talk page, this proposal starts to get into signal phasing, an entire topic that we have a notable lack of tagging ideas about. How is it that we still donât have established tags for protected left turns or pedestrian leading intervals? If we think of âshared greenâ as a property of a crosswalk, then how will it interact with other signal phasing tagging? crossing:signals=* skirts this issue because it focuses on physical signals, while âno turn on redâ tagging generally corresponds to signs directed at motorists.
The proposal takes a stance that crossing details related to the road should go only on the highway=crossing node, not the highway=footway footway=crossing way. This distinction makes some sense in theory, but it seems kind of fussy. In practice, most mappers are simply going to keep the crossing tags synchronized between the two elements. After all, if the way is present, the node is only there redundantly for backwards compatibility. Most mappers donât realize that tactile_paving=* has different meanings depending on which element itâs on, and I think weâd want to avoid a similar situation for this proposed tag.
4 Likes
Ah, thanks for pointing this out, I think I misunderstood. I see now that this is about the signal phasing and regulations regarding right turns, not the physical infrastructure of the crossing.
In that light, I (evidently) find the tag shared_green a bit confusing, as I wouldâve expected it to mean the physical signal is shared. Additionally, if right turns are not allowed while pedestrians cross, the vehicular green forward light may still occur at the same time as the pedestrian forward signal (perhaps green in Europe, typically a white walking person in the US), but would be shared_green=no. Maybe something like shared_turn_phase=yes would be more clear? Or turning_vehicles=yes?
1 Like
I think it might even be more commonplace than that. I believe this tag would apply to anywhere where vehicles traveling parallel to pedestrians have a green light to turn right across a crosswalk where pedestrians have the signalized right of way. In the US, this would correspond to essentially any intersection without a dedicated right turn signal, or without unusual pedestrian signal phasing like a scramble where pedestrians arenât allowed to cross at all during non-scramble phases. The barbarity/innovation of being allowed to turn right on a red light across a crosswalk has probably not crossed the minds of many non-Americans 
3 Likes
The shared green light is really a shared green phase, and more specifically a shared green phase with conflict points. The best way to map this would be phase tagging, but thatâs extremely complex and can be difficult to verify (or even determine in the first place).
Nevertheless, this tag is imo better placed as part of the traffic signal. After all, itâs an indication as to how to interpret that signal. Something like traffic_signals:*
Then there is the naming itself. Does it also apply to situations where cars have a green arrow? Iâd think so since the consequence (higher risk when crossing at green signal) is the same. So is dedicated (within the traffic_signals namespace) better?
Another alternative could be traffic_signals:conflict_free. I.e. there are no conflicts (with either bikes or cars) when the signal is green. Or as a list: traffic_signals:conflicts_with=bicycle;psv.
I think I find the last idea best. traffic_signals:conflicts_with=no means no conflicts at all, i.e. dedicated phase without any green arrows. traffic_signals:conflicts_with=yes means there are conflicts, e.g. involving cars.
Do you intend to set a default? It could be wise to explicitly state that there is no default (like some other tags do) and let the router be as conservative or optimistic as they want. This basically means that it should be tagged everywhere.
We really should avoid color terms in these tags. In the U.S., the standard walk signal is lunar white instead of green. To complicate matters, the other conflicting signals may be tram signals, which typically use white lenses for both stop and go, relying on shapes to distinguish the phases. (I think this is the case in much of Europe as well, but the go signal is amber for trams in Hong Kong.)
2 Likes
& directions!
A fair proportion of the world has to worry about traffic turning left, not right.
2 Likes
I think this is an important point. We really need an established tagging scheme for signal phases, particularly protected turn phases, not only for more accurate driving time estimates but also for pedestrian safety. At a standard four-way intersection of undivided streets, a crossing pedestrian needs to watch for turning traffic from up to three directions simultaneously, even if they have a dedicated walk signal. The number of conflicts depends on a) whether turns are protected versus permitted, b) whether turns on red are permitted, and c) whether there are any slip lanes.
The following observations are based on norms in the U.S., but there are probably some commonalities with other regions.
This proposal only considers traffic turning right from the parallel street onto the cross street with a permissive green signal. A split phasing configuration would be tagged as shared_green=yes, which accurately conveys the fact that the pedestrian has to watch for right-turning traffic. However, unprotected left turns can be just as much of a hazard to the pedestrian, if not more, because the driver may dart into a gap in incoming traffic unaware of the pedestrian.
Even if all turns from the parallel street are protected, if traffic on the cross street can turn right on red, then there may still be some risk to the pedestrian. In theory, that conflict would be minimal, because the driver will have stopped at the stop line before proceeding to turn right. However, where Iâve lived, drivers usually pull forward to where they see oncoming cars, without first stopping before the crosswalk.
When an intersection has slip lanes, traffic turning right on green would cross a smaller crosswalk that only has to watch for traffic from one direction. If the slip lane has a dedicated signal, the crosswalk would be tagged shared_green=no. But usually the slip lane has no dedicated signal, just a yield sign at most, so the crossing would be tagged crossing:signals=no, thus shared_green=no. Ironically, slip lanes tend to encourage speeding and are quantitatively less safe to pedestrians than even the unprotected turns discussed earlier. Meanwhile, the longer crosswalk across the cross street would also be shared_green=no on account of the slip lane, even if left turns across this crosswalk are unprotected.
In conclusion, while I applaud the goal of this proposal, Iâm concerned that it would mislead data consumers and lull pedestrians into a false sense of safety in some common situations. I suspect we can better communicate these hazards by tagging traffic signals with their phases, but most routers donât yet analyze traffic flow within an intersection to any degree.
3 Likes
Somewhat related to this proposal, I came across the flashing light from post #3. The situation on the ground looks like this: Mapillary. The result is Relation: 18335692 | OpenStreetMap.
The way I mapped it, a relation is created (type=phase_conflict) to which the traffic lights of the potential conflict are added. The pedestrian signals are added as priority signals, the other signal as subordinate. The intuition is that if any priority traffic light allows traffic, any subordinate traffic light (which control traffic conflicting with the priority lights) might do as well.
The relation can be tagged with the remedies (like warnings or delayed start) or corresponding objects can be added (like in this example, where the flashing lights are separate objects). They apply usually to the subordinate signal (so e.g. a driver could be made aware of a flashing light facing them).
Since this approach essentially requires that every traffic light is mapped separately, itâs probably out of scope of this RFC. I still want to mention it here for its more granular mapping capability and for those who feel like the proposed tag might not be descriptive enough.
While crossing:signal= could ideally be kept clean and precise, adding =permissive (then =leading , =concurrent) , =protected , =exclusive , etc, as more specific =dedicated variant wonât be too counterproductive. At least some progress can be made. A random shared_green= doesnât look great. At first, I didnât realize itâs about signals at all. Itâs not a common standard term.
For a dumber method, thereâs *traffic_mode= , so it might be extended to crossing:traffic_mode= / crossing:signals:traffic_mode= Proposal:Separation - OpenStreetMap Wiki
Ps UK signals has the term âstageâ. Maybe itâs related to how ring & barrier diagram isnât used there.
I must admit I was not aware that some jurisdictions apparently allow vehicle traffic from several directions sharing a âgoâ-phase with pedestrians.
Generally, while I agree that mapping traffic light phases (or even better, integrating real time information) would give more information for many usecases, I think it will not happen any soon, it is hard to verify (because might change dynamically according to the traffic, hour and day, manual intervention, etc.).
Anecdotally, here is a news article from yesterday about a German city who had introduced AI-âimprovedâ traffic signals in summer and has now switched the AI off in the afternoons because it created very long vehicle queues giving âtoo muchâ priority to pedestrians
My proposal is quite simple, it just says whether the pedestrians have a walk phase together with other means of transport (also partially). It doesnât care whether the road traffic or the pedestrians get a âhead startâ or start contemporaneously, or similar details. It doesnât stand in the way of mapping traffic light phases if this will become a thing, but it also doesnât require from the mapper to know about the phases. It is just concentrating on an isolated (IMHO quite relevant) aspect of traffic light phasing.
Would you (not just Minh but all of you) be able to support such a basic tag for an isolated aspect (shared âgoâ phase of pedestrians with other vehicles), or will you prefer waiting for a complete solution (which likely will also require much more data that may not be easy to obtain)?
- I donât care about these kind of detail
- I want to be able to map traffic light phases and wonât support tag that only solves recording a part of it
- I want to map traffic light phases but would also support a tag that only covers an aspect of it
- I think tagging traffic light phases would introduce too much complexity and would make life hard for mappers without a lot of experience
- I support the idea but do not like the proposed tag name
- I support the proposed tag
- I think mapping traffic light phases would be nice but is not realistically going to happen unless we get access to official data in a suitable license
0
voters
Another case which might be instructive: Node: 12186133184 | OpenStreetMap
The main street (Frankfurter StraĂe) is signaled with a signalised pedestrian crossing. Right next to the pedestrian crossing (within the signalised intersection), two oneway streets lead away from the main street and thus arenât signalised. However, bicycles are allowed in the opposite direction, only sign-posted with a give-way sign.
Thus, the pedestrian encounters no shared green phase, but might still encounter a bicycle from the left or right.
I think part of the issue here is that it focuses too much on a particular technology (starting with the name), so the practical consequences remain unclear. Itâs also not clear whether itâs supposed to be evaluated by drivers.
To solve both issues, I suggest
cross_traffic_free=[no/yes]to be tagged at the crossing node when tagging is done there.cross_traffic_free=[no/left/right/yes]to be tagged on the separately mapped traffic signals.left/rightare relative to thedirectionof the traffic signal.
Interpretation is clear:
no: There might be crossing traffic from either side or both (no safety benefit)left: The crossing is free from crossing traffic from the left (you donât have to look left), but there might be crossing traffic from the right.right: Likeleft, but with right.yes: The crossing is free from crossing traffic from both directions.
Theoretically, one could also tag it on non-signalised traffic, though there it is easy to figure out just by looking at the crossed street (oneway or not) and is usually no. One could also invert the meaning by tagging cross_traffic.
Signalised intersections are unique in the respect that many think about them as providing cross_traffic_free=yes, but thatâs not what they usually do. Albeit that with improving technology, more and more intersections get there.
Maybe I should do my own proposal 
it could be evaluated by drivers, although it would not be clear whether there is actually a shared green (most of the traffic will likely be when there is stop for pedestrians), while for pedestrians it is more likely they will have to be cautious.
In that case, the only useful value is shared_green=no, which the proposal doesnât even explicitly mention.
2 Likes
My main problem is that it would be shared_green=yes on basically on crossings in Canada which makes it pretty useless - data users might as well assume shared_green=yes here.
Honestly, from my experience living in Berlin (innerhalb des S-Bahn-Ringes) in 2016-2018, it was shared_green=yes on most crossings there too. So why tag it and why not just assume it?
Where is shared_green=yes not the case for majority of crossings?
2 Likes