Proposal:Objects generating audible cues

Objects generating audible cues
Proposal status:	Rejected (inactive)
Proposed by:	bkil
Tagging:	audible=*
Applies to:
Definition:	Indicate the kind of steady audible noise generated by an object
Statistics:
Draft started:	2020-09-25
RFC start:	2020-09-26
Vote start:	2020-10-17
Vote end:	2020-10-31

Proposal

We should have a unified way to specify the kind of noise that is generated by an object. The sound should ideally be clearly audible by average pedestrians in normal conditions (like from a 1 meter distance) when standing on property not closed to the public. The most useful ones are those which are right beside a footway and which is clearly audible when walking by.

The existing documentation for man_made=street_cabinet should be updated to deprecate sound=* and the few existing OSM occurrences for this tag combination along with power=* should be changed to use audible=*.

The following mistaggings of traffic_signals:sound=* should also be eliminated manually: sound=* (in the right combination), crossing:signals:sound=*, crossing:sound=*.

Usage, Tags and Values

How to map

Add the below tags to the node or way of the POI that produces the noise.

A single approximate measurement should almost always be sufficient, but for highly anisotropic sources, you may map the POI as a way and add multiple measurements as separate nodes on that way (like one on each side).

Required

• audible=no - if this kind of object usually gives out a sound, but this instance is not audible (for example, a huge transformer that is well maintained or went offline)
• audible=yes - the object is definitely generating audible noise, please elaborate on the kind of mechanism generating the noise
• audible=intermittent - the object is sometimes giving out noise, unknown recurrence
• audible=timing - specify operating hours in audible:timing=* as per opening_hours=* syntax
• audible:mechanism=* - what generates the noise, what does it sound like, how can laymen describe/discern it?

List of mechanisms

As for all keys and values in OSM, laymen should be able to discern these without instruments or much training. You may combine multiple items in this list with semicolon delimiters if it makes sense - most street cabinets produce audible:mechanism=tone;fan.

• audible:mechanism=liquid_flow: creeks, mostly laminar and calm
• audible:mechanism=liquid_fall: highly aerated and turbulent, like a waterfall, when opening your tap or at certain manhole covers
• audible:mechanism=murmur: the low frequency dominant "calm", non-water like sounds heard at certain manhole covers or conducted by water pipes towards taps or fire hydrants
• audible:mechanism=fan: turbulent airflow and sliding or ball bearings of air cooling for electronics (typically inside a street cabinet) or on the side of external units for air conditioning and heat exchangers
• audible:mechanism=gas: flowing of gaseous material at a pumping station
• audible:mechanism=tone: usually low frequency humming around transformers, higher pitch whining of other electronics
• audible:mechanism=bird: produced by sonic avian deterrent devices by playing back bird calls or other deterrent tracks from loudspeakers (Bird_control#Methods)
• audible:mechanism=wind_chime: usually made out of metal or wood that gives out sharp sounds like a percussion instrument (Wind chime)
• audible:mechanism=motion_controlled_light: intermittent loud clicking sound of a power relay when a motion sensor operated lighting turns on or off (after a minute) (Lighting control system)
• audible:mechanism=security_pir: more quiet, intermittent relay clicking sound of a motion detector on every movement (Motion detector)
• audible:mechanism=combustion_engine: running stationary engine within an aggregator for example

Optional

• audible:fundamentals=* - comma separated list of frequencies in Hertz that contribute the most to the noise (usually 1 or 2 fundamental can be easily discerned, for example audible:fundamentals=50;150) or a dash separated range where most of it lies (for example audible:fundamentals=200-300) This along with audible:mechanism=* should help "preview" noises at home using the map. Can be assumed to be the line frequency of the country by default. (TODO define "top contribution", perhaps 6dB?).
• audible:waveform=* - shape of the fundamental tone waveform, can be one of: sine (default), square, triangle or sawtooth.
• audible:spl=* - how loud is the sound? In standardized dBA (A-weighting#Environmental_and_other_noise_measurements, Sound_pressure#Examples measured at 1 meter towards a direction where most users will pass the object). A calibrated smartphone app should be sufficient - this is mostly used to discern between very faint (30), moderate volume (40) and loud (55) noises.

Some example sound pressure levels from the range of interest:

• 10: light leaf rustling in the distance, calm breathing
• 13: light bulb hum
• 15: pin dropping on solid floor from 1m
• 20: rustling leaves on a tree
• 30: whisper
• 40: babbling brook or creek, computer
• 48: small desktop USB fan
• 50: refrigerator
• 55: rainfall, electric toothbrush, coffee percolator
• 60: conversational speak, sewing machine
• 63: air conditioner, washing machine
• 65: electric shaver

Applies to

Most commonly:

• man_made=street_cabinet - deprecate sound=*
• power=transformer
• man_made=pumping_station
• manhole=*
• advertising=*
• highway=elevator - if a constant whining or humming noise can be heard from outside when it is stationary (instead, if it is announcing levels via speech on the inside, use speech_output=*)
• tourism=artwork - like wind chimes
• highway=street_lamp - should imply that it is not usually audible when not powered on (i.e., during the day)
• waterway=drain / waterway=waterfall - should also evaluate intermittent=* / seasonal=* on the object as well.
• man_made=air_conditioning / air_conditioning=* - outdoor units are usually very loud and can be heard from across the street, but it is implied that they may not always be turned on
• amenity=drinking_water / man_made=water_tap, emergency=fire_hydrant - only if they produce an audible noise when not in use as well (by conducting sound from the underground pipe system)
• man_made=mast - the attached transformer can by audible nearby
• amenity=clock - if it chimes

Occurrences

audible=*:

Rationale

Those with vision impairment should also have the right to explore and map their surroundings in ways appropriate for them.

Note that we can not reuse the established noun sound=*, because an elevator shaft for example can give out a distinctive humming noise on the outside that can be heard from the distance, but it may very well be able to do sonification on the inside at the same time, i.e., telling you the current floor by speech. A talking clock could also have a humming power supply.

Existing aids for the visually impaired

• surface=* - can be differentiated by a cane
• tactile_paving=* - can be used to find crossings, public transportation platforms or steps
• tactile_writing=*
• speech_input=*
• speech_output=*
• information=tactile_map / information=tactile_model - can be referred to for an overview of the area
• traffic_signals:sound=*
• traffic_signals:vibration=*
• texture=* - not widespread and lacks documentation, but wanted to convey the surface of a street cabinet
• blind:description:en=* (Disabilitydescription)
• OSM for the blind#How to map for the blind

Other existing intermittent sound sources

• seamark:fog_signal:category=*
• tower:type=bell_tower, amenity=bell, man_made=campanile
• emergency=siren
• man_made=flagpole - depending on construction, it may squeak upon turning, the cloth may flutter and metal parts may chime or click on movement
• a weather vane - may also be squeaking as it turns
• loudspeakers (those would be the most useful which broadcast often or play ambient music, probably needs cleanup): railway=speaker, speaker=*, loadspeaker=*
• door=*, entrance=* - doors of high traffic POI open and close a lot and the fundamental type of door can be easily told apart by sound (hinged, revolving, sliding)

Rendering

Something that could be indicate visually impaired users like a probing cane or sounds, volume bars, a horn, speaker, an ear.

• 
• 

Comments

Please comment on the discussion page.

Voting

Instructions for voting

• Log in to the wiki if you are not already logged in.
• Scroll down to voting and click 'Edit source'. Copy and paste the appropriate code from this table on its own line at the bottom of the text area:

To get this output	you type	Description
I approve this proposal.	{{vote|yes}} --~~~~	Feel free to also explain why you support proposal.
I oppose this proposal. reason	{{vote|no}} reason --~~~~	Replace reason with your reason(s) for voting no.
I have comments but abstain from voting on this proposal. comments	{{vote|abstain}} comments --~~~~	If you don't want to vote but have comments. Replace comments with your comments.

Note: The ~~~~ automatically inserts your name and the current date.
For full template documentation see Template:Vote. See also how vote outcome is processed.

• I approve this proposal. --EneaSuper (talk) 11:03, 4 October 2020 (UTC)
• I have comments but abstain from voting on this proposal. Have anyone tried using this tagging? I am skeptical about usefulness and "This key does not appear in the OSM database." suggests that noone tested this proposal on even a small scale Mateusz Konieczny (talk) 08:55, 5 October 2020 (UTC)

I've copied the question and moved the answers to the discussion page -Bkil (talk) 14:22, 14 October 2020 (UTC)

• I approve this proposal. While I am not planning to use it and I am a bit dubious about usefulness - it is mappable and it is nice to have tag documentation Mateusz Konieczny (talk) 16:39, 17 October 2020 (UTC)
• I approve this proposal. --Dr Centerline (talk) 00:39, 18 October 2020 (UTC)
• I approve this proposal. We got a town-wide chime from a clock on a church --Tesla (talk) 14:14, 21 October 2020 (UTC)

How would you use the town-wide sound for determining your position?--Polarbear w (talk) 22:52, 24 October 2020 (UTC)

• I approve this proposal. --Rtbk (talk) 05:53, 22 October 2020 (UTC)
• I approve this proposal. --Luke (talk) 15:44, 24 October 2020 (UTC)
• I oppose this proposal. Sorry but the proposal is immature and insufficiently tested. I support the idea behind and would be in favour of most of the basic tags in the "required" section. However you put a whole tagging system for voting, and that has a number of significant flaws. It is overly complicated and sometimes requires knowledge of an audio engineer to map, not the laymen being hoped for. Specifically, in the order of listing:
• audible=timing - should that be "timed"?
• audible:timing=* as per opening_hours=* - as the name suggests, opening_hours focus on time frames in the order of hours. Some examples given further below are in the order of milliseconds (e.g. relay click), the proposal does not make clear if timing means that e.g. such click could only be heard at such hours of if that is to describe its duration. Otherwise duration is missing completely.
• audible:mechanism has contradicting values. The example "gas" is the medium, while "wind_chime" is the device (which medium is gas (air)). The example "gas" is nailed to pumping stations. Other values describe the action of the medium, like "liquid fall". "murmur" is more the characteristics of the sound than a mechanism. "motion_controlled_light" and "security_pir" is the same sensor principle in very different wording. Abbreviations should be avoided (wikipedia lists 30 disambiguation lines for 'pir'); passive infrared is apparently meant. All the examples are too episodic and need to be systematized.
• audible:fundamentals - how do you expect the frequency to be measured? As the name suggests, the fundamental is the base frequency of a tone, how can there be more than one? Or are you describing sequences of different tones, which has not be mentioned so far.
• audible:waveform - how do you expect the waveform to be measured? Do we carry oscilloscopes? The description is physically wrong, the fundamental is always a sine; the different waveform comes from the mixture of harmonics being added (for continuous waves) or other component frequencies for non-continuous.
• audible:spl - abbreviation again, apparently meaning sound pressure level. Again how to measure, and in particular how to verify the distance from the source, which might at an unreachable distance (see your example "security_pir" - that might be on the fenced property you pass). The distance is utterly important since the sound pressure drops with the square of the distance. A verbal description (loud, faint, ...) would be more acceptable. Have you tested measuring the SPL of the relay click?

--Polarbear w (talk) 22:49, 24 October 2020 (UTC)

• I approve this proposal. --Lejun (talk) 06:34, 25 October 2020 (UTC)
• I approve this proposal. --Dieterdreist (talk) 12:22, 25 October 2020 (UTC)
• I oppose this proposal. For the reasons Polarbear explains. This tagging scheme starts from a good idea but loses itself when asking for technical measurements that nobody will be able to accurately provide, and has "audible:mechanism" with weird values. --—M!dgard [ talk ] 13:08, 25 October 2020 (UTC)
• I approve this proposal. --Hauke-stieler (talk) 13:30, 25 October 2020 (UTC)
• I oppose this proposal. I would be happy to approve but audible:mechanism describes a mechanism... or something else. On top of that, what is the added value to say that 1 meter away of a lift you can hear the lift? That, close to expansion system of a gas power station, you can here the gas flowing? Will you tag roads? They can be very noisy. --Nospam2005 (talk)
• I oppose this proposal. It is a good idea to provide basic generic information about the sound that can be expected from a feature, so I think your motivation is good. However (as others mentioned) your proposal is over-detailed, overambitious, immature, in my opinion. To give specific comments:
• I'm very unclear as to what is the proposed distinction between "sound" and "audible". Is the distinction that some sounds are deliberate/unintentional? Constant/intermittent? Despite your examples, I'm not convinced there's a consistent distinction that mappers will tend to agree on.
• "audible:waveform" - I strongly oppose this since it's un-measurable to most people, and could become filled in with meaningless guesswork. Many things might "sound like" sawtooth, but that does not mean that they are.
• "audible:mechanism" - this would be better as "audible:type" and remove some of the excessive detail. "bird" is not a good value for a sound that is generated by loudspeaker not by birds. A "motion_controlled_light" is not a mechanism either - it's the power relay that makes the sound. "tone" is not a mechanism either. "murmur" is not a mechanism, it seems to be a refinement of liquid_flow. Please simplify this whole scheme to more generic sound types such as "audible:type"="loudspeaker"/"mechanical"/"fluid".
• Since you're proposing details such as "waveform", should we perhaps think about how to consistently link to external pre-recorded sound clips?

Overall: please simplify this proposal to its core meaning, and aim to grow from there. Don't imagine you can get all the detail right on first attempt. --Danstowell (talk) 20:41, 25 October 2020 (UTC)

• I oppose this proposal. I mostly agree with Polarbear and Danstowell. The core idea is good, but the rest is overcomplicated. Those tags are too technical in my opinion, and of little use. --Phaerrax (talk) 09:58, 27 October 2020 (UTC)
• I oppose this proposal. This was a difficult vote for me, because as many said you idea is great, but you over-complicated your proposal. All your optional keys need an audio engineer to fill them correctly. Just a few people have an SPL meter. Why instead of being quantitative you have a qualitative scale. The description of your audible mechanism must be reevaluated, for example transformers dont'n make a tone sound, they make a hissing or cracking noise as it ionizes the air due to the corona effect for high voltage systems. Are you defining the sound they make or the mechanism? --Meme (talk) 03:57, 4 November 2020 (UTC)

Voting closed

Voting on this proposal has been closed.

It was rejected with 9 votes for, 6 votes against and 0 abstentions.

1 abstention turned into a yes. 9/15 = 60% failing the 74% mark. The "No"-votes have serious concerns.

Rejected.