Proposed features/Objects generating audible cues

From OpenStreetMap Wiki
Jump to navigation Jump to search
Objects generating audible cues
Status: Voting (under way)
Proposed by: bkil
Tagging: audible=*
Applies to: node area
Definition: Indicate the kind of steady audible noise generated by an object
Drafted on: 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.

Optional

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:

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

Other existing intermittent sound sources

Rendering

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

  • Ear (example).svg
  • Ear noun 42647 cc.svg

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 I approve this proposal.
{{vote|yes}} --~~~~
  • I oppose this proposal I oppose this proposal. reason
{{vote|no}} reason --~~~~ Replace reason with your reason(s) for voting no.
  • I abstain from voting but have comments I have comments but abstain from voting on this proposal. comments
{{vote|abstain}} comments --~~~~ If you want don't want to vote but have comments. Replace comments with your comments.

Note: The ~~~~ automatically inserts your name and the current date.


  • I approve this proposal I approve this proposal. --EneaSuper (talk) 11:03, 4 October 2020 (UTC)
  • I abstain from voting but have comments 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 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 I approve this proposal. --Dr Centerline (talk) 00:39, 18 October 2020 (UTC)
  • I approve this proposal 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 I approve this proposal. --Rtbk (talk) 05:53, 22 October 2020 (UTC)
  • I approve this proposal I approve this proposal. --Luke (talk) 15:44, 24 October 2020 (UTC)
  • I oppose this proposal 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 I approve this proposal. --Lejun (talk) 06:34, 25 October 2020 (UTC)
  • I approve this proposal I approve this proposal. --Dieterdreist (talk) 12:22, 25 October 2020 (UTC)
  • I oppose this proposal 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 I approve this proposal. --Hauke-stieler (talk) 13:30, 25 October 2020 (UTC)
  • I oppose this proposal 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 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)