- `standard` might indeed be confusing, but I haven’t seen a better alternative pop up. I’m all ears. `traffic_sign` is IMHO quite clear. `road_surface_bulb` and `road_surface_strip` are IMHO also typical designs, the devices simply are made to be placed in the road surface.
- This is the first time `light:flash` is mentioned in this thread. You also link to a proposal that has been lingering for fourteen years. When I’m doing a proposal, I cannot reasonably base that on some vague proposal that has been lingering for so long. You are the one who are complaining about that “flashing_light” should be “de facto”; imagine the blowback I’d receive if I based my proposal on something that is but a proposal. Please, don’t put the burden on me to “do more research”!
- crossing:light seems fitting. I’d love to see a tagging proposal to broaden “crossing:light” to be used in road crossings as well, the ambiguity cleared that it doesn’t mean that there is a light highlighting the crossing and then retag everything.
I’m not sure either. In the latest revision of the proposal, the definitions are inconsistent with the examples. Originally the proposal used standard for the most common type of flashing crossing beacon in the U.S., which is mounted above a sign, but now the examples indicate that we’d tag it as traffic_sign.
The definition of traffic_sign seems to describe something different. Flashing red LED diodes are integrated into the following stop sign:
In the following example, stop beacons are hung over the intersection, and embedded flashing LED diodes are embedded in the stop sign:
Flashing yellow LED diodes illuminate the following crossing sign:
The following sign resembles the speed limit sign you give as an example, with flashing yellow lights embedded in an assembly, but the “integrated” lights are actually the red 
around the speed limit. I don’t think it’s as important to distinguish whether the yellow lights have a metal frame around them. That said, I’m not sure if the actually flashes; this could be luminous=yes.
flashing_lights=* is already being used on traffic_sign=* nodes and will continue to be under the proposal. flashing_lights=traffic_sign is a bit of a tautology in this context.
If it isn’t too late to make an adjustment, I’d suggest returning both traffic_sign examples to standard and renaming standard to beacon. So beacon, belisha_beacon, and rrfb would all explicitly say they’re beacons, and the other values would be for smaller flashing lights.
=standard,=traffic_sign: Basically the same light is used in both the=standardand=traffic_signstop sign photos. The stop sign light is quite different from the school school speed light integrated in the plate.=road_surface_*: My suggestion was they should be split intosupport=/lamp_mount=/*mount=ground+=bulbvs=strip, and similarly for=traffic_sign(but that needs to further considered as being on a pole on ground already)light:flash=: Ok sorry I might have mistyped it with other parts. But you should know wiki is bad at searching, especially colons.light:flash=is mentioned on multiplelight:*=articles (all listed in=street_lamp), as well asflashing_lights=, and it only takes you an exact search to find the proposal. Can you notice it’s 5th result in the non-exact search you linked too? Key:flashing_lights - OpenStreetMap Wiki
Who should I ask other than the proposer? You didn’t reply to many other questions, and started voting before all debates are settled.
Fundamentally, flashing_lights= has many problems compared to light:*= and light_source=
light:*=:flashing_lights=actually doesn’t describe flashing lights itself proper, only how it’s activated, meaning it’s overlapping withlight:lit=, which independently allowslight:flash=to further describe how it flashes. Another critical distinction not discussed yet is single blinking (crosswalk, stop sign) vs an alternating pair always displaying yellow (school zone speed).light_source=: Particularly here, you have further mentioned theflashing_lights=attribute can be used ontraffic_sign=, but that would be duplicating thelight_source=feature when thetraffic_sign=is a standalone point at its physical position
I have already held back more complicated cases for enhanced =belisha_beacon before the above questions are solved
- Halo of many small LED around the globe File:TWM DayBright Plus (Full Compliant LED Enhancement).png - Wikimedia Commons
- Or partial halo LED Belisha Beacon Zebstar Plus – Portland Traffic
- Ring of a few light around the globe File:TS2300 High Visibility Belisha Beacon.jpg - Wikimedia Commons
- A visor making it resemble normal lights more File:BelishabeaconLED.jpeg - Wikimedia Commons
- Lights along the pole, which may be used on non-Belisha lights Illuminated Pedestrian Beacon (OlympiadIPB) - Fisher & Company
.png){kind=link}
light_source= would solve 1, 2, 3, and 5 with light:count= and semicolon in other attributes. 4 may be changed to light:shape=directed , while this doesn’t describe the exact layout.
Another fundamental doubt I have is mixing generic (=*bulbs , =*stripe ) with specific designs (=belisha_beacon , =rrfb ). As how I worded, Belisha Beacons are referred to as globes, although that would be covered by light:shape=spherical already. I have don’t have a better naming yet. But in terms of 4, it might be eg *:design=globe + light:shape=directed (the globe is converted to directed light by the visor) + *:architecture=belisha_beacon (from building:architecture= )
Indeed I don’t like flashing_lights:design=traffic_sign + traffic_sign= either for one same reason. It describes nothing more.
Is traffic_signals=blinker different from =beacon ? As in the Intersection Control Beacon term.
Yes and no. highway=traffic_signals traffic_signals=blinker does refer to an intersection control beacon, which is a warning beacon that occurs at a stop-controlled intersection. As I explained earlier, I think highway=traffic_signals fundamentally misrepresents this kind of beacon. Functionally, it doesn’t upgrade a highway=stop to a highway=traffic_signals and it certainly doesn’t upgrade a highway=priority to a highway=traffic_signals. Nothing supports highway=traffic_signals traffic_signals=blinker correctly and everything supports it incorrectly, so I’m eager to get the troll tag deprecated.
This proposal would implicitly provide a better alternative, traffic_sign=stop flashing_lights=standard (or, preferably, beacon), except that the examples currently imply that it would be flashing_lights=traffic_sign just like a flashing illuminated traffic sign.
1 Like
Yes, in fact, the flashes. So this is an example of both a flashing beacon and flashing lights integrated into the traffic sign. A different Australian state provides an animation of a similar sign:
I’d suggest tagging this as traffic_sign=AU:QLD:R4-Q01 flashing_lights=yes flashing_lights:design=beacon;traffic_sign.
Yes, I have actually used some traffic_signals= without highway=traffic_signals , as the latter seems bad on them. Then I want to ask *:design=blinker vs =beacon
Well, flashing is blinking. I was suggesting a distinction between beacons (easily discernible lights that convey their own message) versus lights that illuminate or outline some other object (like a sign or marking).
=beacon: Ok I simply thought it’s more familiar to reuseblinker=traffic_sign: I thought it should mean lights framed inside the sign plate. As mentioned,luminous=already exists, which can be used where the sign symbol itself have lights. That seems preferable.
I disagree that flashing_lights:design=traffic_sign should mean an ordinary beacon that’s part of a standard sign assembly. In the following illustration, the black areas around the flashing beacons are high-contrast backplates that enhance visibility against whatever is behind the sign. The backplates are not part of the flashing light. If you’re tagging a traffic_sign=* node, the backplates are a property of the sign rather than the beacon, and they’re probably implied by the sign code anyways.
Most of my city’s traffic signals have a black or yellow backplate, which I’d be more inclined to tag as something like man_made=traffic_signals backplate:colour=black/yellow so we can distinguish them from the traffic signals that lack backplates.
The following turn restriction sign is illuminated but doesn’t necessarily flash. This should be traffic_sign=US:R3-1a luminous=yes flashing_lights=no:
The following crossing sign is also illuminated but doesn’t flash, and there’s a flashing beacon below it. This should be traffic_sign=CZ:IP-6 luminous=yes flashing_lights=yes flashing_lights:design=beacon. Unfortunately, the current proposal calls for flashing_lights:design=traffic_sign, which is misleading.