Radio operated traffic_signals:sound

In my area, all button operated traffic signals can sound, the knock to find them, the howl to find the other side of the road. Most only do so, when a person with a special radio dongle requests that. There is a bit of talk here - Talk:Key:traffic signals:sound - OpenStreetMap Wiki

I observe a number of users tagging traffic_signals:sound=no on them. Today I asked why, as I know they can. Been told: 1) Such is against reproducibility for somebody not having the device, 2) It is only a small community that has the device.

My thoughts on: 1) Survey result will differ by chance, depending who is close there at the time. 2) The small community is actually why this gets mapped, so why disregard them?

Any suggestions how to update the documentation? Are there actual users of this information here?

1 Like

It’s not explicit in the text, but to my mind the existing tag is for sounds that occur automatically when the crossing functions. This can either be as nearby lights automatically cycle or when a light to cross is permitted through the normal means.

If the sound doesn’t happen by default but only when they detect a special device, then I think we should have a new key for that. Those not in possession of the device can then tag as normal, but if you do have access to additional information, or are able to spot a relevant logo etc. then you can add the “members only” tag.

1 Like

No user of this but to prevent a discussion on if remote operated traffic signals should be traffic_signals:sound=no or traffic_signals:sound=yes, I think remote operated traffic signals should use something like traffic_signals:sound=on_request.

Further tags can then be used to specify how this request can be made. We have already button_operated, adding remote_operated would make sense to me.

1 Like

Few months ago I talked to someone from Prague about this concept.
We ended up using traffic_signals:sound:radio_operated, on 4 nodes so far.

2 Likes

Thank you very much! I had to follow your advise. I chose a slightly different term though - traffic_signals:sound:radio_activated - Reasoning for nitpicky language: The radio does not operate the traffic signal nor which sound, it just activates sound emission.

I can add 500 in one go, my hometown uses https://langmatz.de/Produkte/Signal-Anforderungsgeräte/EK533/10-04%20Datenblatt%20EK%20533%20crossguide_en.pdf from a close by manufacturer. The yellow housing includes the speaker. The local blind/visually impaired association hands out devices to the eligible.

There are a few, that sound throughout - along very busy primary highways with no residents. I guess I rather not tag it. They carry traffic_signals:sound=yes already.

Before I start mapping, I wait a little: Please discuss here! Or edit there.

PS: traffic_signals:sound=no seems quite a tag for realtors - so to learn about quiet neighbourhoods :slight_smile:

PPS: In the past there were traffic_signals:sound:button_activated ones, feel free to add that to the documentation if that is a thing in your area and you want to map it. Here, due to abuse the city switched to the radio ones long ago. That also played into the chosen term activated above… even though button_operated traffic signals not always make a difference in switch time.

The problem with this is that the radio feature can be effectively hidden from people without the special device. There would be no way to identify the difference between “someone without a device didn’t hear anything” and “someone with a device confirmed this doesn’t support them” because both of them are traffic_signals:sound=no. The only way to tell if something has been checked with a relevant device would then be to add another tag for whether they’ve been checked for that and at that point you might as well use a separate traffic_signals:sound:radio_activated.

I do think ones with a separate button or easily identifiable keyhole to activate the sounder should probably be a value on the original traffic_signals:sound tag though.

1 Like

@InsertUser, I am fine with traffic_signals:sound:radio_activated but still the question from the start post on what then the value for traffic_signals:sound should be.

I’d say that neither yes nor no are correct. There should be some additional value for cases like this. IMO the tag traffic_signals:sound:button_operated=yes should be traffic_signals:sound = button_activated and likewise traffic_signals:sound = radio_activated. But this is just my opinion and should be discussed with the users of these tags and devices.

In my area, there are a few that always make sound. For them traffic_signals:sound=yes can be mapped with certainty. The value no though is problematic, as in most places they are silent unless activated by radio. This also affects the value yes, but much less so.

That only works as long as sound gets activated by either / or method. In Vienna the tock guide signal is always on, the cross/walk signal is button activated.

Here installations have up to three buttons plus the radio: only one of the buttons though did activate the sound (it does no longer, due to abuse.) Perhaps in other places, this button, which lots of osmappers will fail to locate still gets used. Still, this will lead to different people mapping different things.

That was part of my question in top post. Not much of them around here, so it seems. All the links on the traffic_signals:sound wiki point to projects abandoned ten years ago. The visually impaired association in my area are aware of BlindSquare.

Hi! I am the one who had started the original discussion on the wiki page. I happen to own one of those special devices, because someone gave it to me after not knowing at all what it was. I do not actually need those remotes, but having one did get me to try to learn a bit about them. I hadn’t even noticed that this forum existed, thanks for bringing the discussion here.

The French wiki page has two recordings of the two signals that French traffic signals can make:

  • On a red light, the signal says Rouge piĂ©ton (literally “Red pedestrian”) every few seconds. If it actually follows the road building codes (most don’t), then it will say Rouge piĂ©ton followed by enough information to tell which exact signal is red. In that video, the signal says Rouge piĂ©ton, boulevard Raspail to tell which street it is for. Some might also say for which half of the crossing, for those with islands, and/or a cardinal direction. That is helpful because whether a signal will hear the radio message from your remote is quite random, and sometimes you can activate a dozen signals at once around you.

  • On a green light, the signal starts making some strange melody made with bells. It no longer says the street name or any location information, though you might be able to still find the signal by guessing the origin of the noise. You can easily be confused and cross because a different signal went green.

The two videos have been recorded in Paris, where the traffic signals can both be triggered by the remote and have a button you can press. The button is under a beige box. I have been in Paris a few times and have tested both the button and the remote.

I have however never seen those buttons anywhere else in France: every other city only uses the remote. Some town halls will give you that remote for free if you have a disability card, or you can buy one online from various suppliers.

A while ago, a friend told me of a signal that he thought had a bug and was stuck with the sound always on, and that was fixed a few days later. That’s the only time I ever heard of a signal in France that permanently makes noise. So the issue of remote operated signals affects most signals in the country.

That’s my thinking too, which is why I raised the issue in the first place. StreetComplete gives this hint on the sound quest:

Hint: Look out for speakers. Not all sound signals can be activated through a button.

Only a few designs of signals will have a very visible speaker, like this one, but even some brand new signals might have the speaker be completely hidden inside of the casing. So I expect most signals to have been tagged traffic_signals:sound=no even when the remote was available. In Paris, since it does have beige buttons, it is possible that a mix of yes (yes, there’s a button!) and no (there’s a button sure but it’s not activated permanently) have been used.

To add to the verifiability issues, note that the French road building code says the signals can also be activated at set times of the day, with no way of telling what times other than hanging out at the signal for a whole day (perhaps a whole week). I have never seen this anywhere either, but that does mean that yes might not even truly mean that it emits a sound exactly all of the time.

Well here’s a new problem: There have been some roadworks around here a few months ago, and some brand new traffic signals were installed. They are exclusively to protect a crosswalk, so they never activate by themselves. You have to press a button, which does not cause a sound but actually operates the signal. Of course, that can be documented with button_operated=yes. But I discovered that using my remote will both activate the sound, and operate the signal! The light above the cross request button starts blinking and the signal goes green after a few seconds.

I suppose that’s still kind of an edge case for now, but if new button-operated signals are starting to have those systems in place, in the long term we may need to address this.

I have e-mailed this association for the visually impaired in my area to ask them about this and for any other entities they could suggest I reach out to. We’ll see where that goes…

4 Likes

On lots of crossings here, pushing the button will do nothing. Some have a white middle light in the signals column, pushing button will make it blink, but not change wait time. On others though, pushing the button will affect switching time.

Perhaps, more attributes are necessary to collect the features, for a start:
traffic_signals:radio_operated
traffic_signals:sound:button_activated

Best for sure, ask and learn what the potential users want.

PS: Curiously, Key:button_operated - OpenStreetMap Wiki is not even mentioned on Tag:crossing=traffic_signals - OpenStreetMap Wiki - From what I observe in my area, the key is mostly used to map the presence of the button, but not whether it actually does something.

1 Like

Thanks again for a very useful post about the situation in France. Now realize that you have turned to your national organization for the blind, Valentin Hauy. Our Czech VPN activation radios, the latest version, already have the European standard and it would definitely be worth trying or knowing if they work in France too.
Similar buttons with green diode light signaling are already quite common in the Czech Republic. Also, the number of sounding traffic lights is already the majority in our country.
You can find an overview of the types of buttons used on traffic lights in relation to the sound system on the SONS website.
This issue is dealt with by the Barriers department in this organization, but it does not communicate with me very much. Maybe because I expressed the opinion that another way should be found to activate the sound signaling at the traffic lights, than just through the radio for the blind. Not everyone owns it. It would be enough to program the existing traffic light button, for example, to press twice. Of course, I am not against the activation from the VPN radio.

It’s still me. I used the tag to mark nodes in Prague 9 in Hloubětín.

In Spain, several cities have the Passblue system, to remotely activate traffic signals sound.
This system gets activated just by having a bluetooth device which is visible and with a name that is whatever.DFA (see Passblue ILUNION – compartolid.es).
I was wondering if there was a way to tag that this system is the one used, and not any other radio operated remote activation system.
Thanks!

The other discussion about these sorts of systems seems to have resulted in traffic_signals:sound:radio_activated being added to the wiki page.

Tags for compatibility with various devices seem reasonable if there are multiple systems around. Preferably something a little more concise.

Should be considered holistically. There are various comparisons that can be made.

The discussion page has mentioned buttons as well. In fact, Key:button_operated - OpenStreetMap Wiki has exactly this question from the old forum. Confusion about button_operated for traffic signals
Need to remember button_operated= has some problem with its naming and verifiability. Some traffic_signals:button | Keys | OpenStreetMap Taginfo has been used before. Finland/Traffic signs - OpenStreetMap Wiki
So eventually, both it, and Bluetooth need to be covered, not only some “radio” (that’s not Bluetooth). Furthermore, the wireless control can be from a phone app, or a controller. That being said, I’m not exactly sure how a phone can emit the 868.3MHz in EU868 band for SRD according to LoRa, which isn’t in the ITU ISM bands. The publicly readable link for NF S32-002 standard is dead.

Ps Okeenea is the original radio maker in France

The other question on the discussion page is about explicitly showing it has both sounds, instead of treating otherwise unspecified =yes as both Talk:Key:traffic signals:sound - OpenStreetMap Wiki
To conclude for now, assuming there is few systems (unlike payment:*= ) , I would suggest not suffixing the system. *:ssid= from internet_access:ssid= could be reused, although it needs to be distinguished as the user device, or the meaning needs to be assumed different here. Assuming the pattern will only be prefixing or suffixing, *:ssid:prefix= & *:ssid:suffix= could be used, similar to name:prefix= & name:suffix= . As for the system, I suggest starting with eg brand= , as model= may be considered for the Bluetooth device.

  • traffic_signals:sound:authentication:bluetooth=only
  • traffic_signals:sound:authentication:bluetooth:brand=Passblue
  • traffic_signals:sound:authentication:bluetooth:ssid:suffix=.DFA

The question of buttons remains unsolved. It’s a control that would be authentication:none= . For the purpose here, as you don’t need to do anything to request the sound, automatic systems would be considered no-control, only requiring traffic_signals:sound:authentication:*= .