Proposal talk:Bell

+1 to this

• +1 to this proposal. I know of some bell/carillon sites in Spain, and mapping them would be nice!
• +1 Sturm (talk) 00:19, 12 February 2018 (UTC)
• +1 Agree. --Iagocasabiell (talk) 23:04, 28 January 2019 (UTC)
• +1 OSMRogerWilco (talk) 20:04, 29 September 2021 (UTC)
• +1 Rapunzel (talk) 07:15, 24 January 2023 (UTC)

Attributes feedback

• multiple=# ... I'd prefer count=# semantically and the tag is more established:

multiple=* More details at taginfo

count=* More details at taginfo

• sound=yes/no ... I'd prefer operable=yes/no semantically (especially because yes is defined as "it is possible to ring the bell").
• strike_tone=* ... according to taginfo this should be set to the note name, so I'd prefer strike_note=*. It is unclear how the note names should be tagged exactly (e.g. f, F, F5, f5 or F_5), so that should be clarified.

Otherwise the proposal looks good to me.

--Push-f (talk) 06:16, 9 June 2022 (UTC)

Thanks for the good feedback. Please excuse the late response, I was busy with other things. Here are some answers and ideas to improve the proposal:

• count=* is indeed better. Of course, if multiple bells are present then some guidance needs to be given how to tag the individual information of each bell. I suppose that a semicolon-separated list would be useful. For example, the names of two bells in the same place might be given as name=Maria;Joseph.
• sound=*/operable=*: I don't see any other feature that uses operable=*. The proposal for "sound" was taken from traffic_signals:sound=*. The description should be changed to "the bell makes a sound" (or similar).
• Combine sound=* with the proposed values of bell=* to sound=no/yes/ring/carillon, with "yes" as the default value? This would leave bell=yes/no to indicate the existance of a bell as in crossing:bell=*. (Do we need to think of door bells?)
• strike_tone=*/strike_note=*: wikipedia:Bell uses the terms "strike tone" and "named note". Whatever key we use, it might be quite complicated to specify values. The same tone (or note) has different names in different languages (see File:Octaves_notation.png). Additionally, it can be difficult to determine the strike tone of a bell, see wikipedia:Strike tone, but I suppose that a mapper would take the value from some written information that is provided for the bell. (To get an impression of the complicated set of parameters that might be provided for a bell, see the first column "Petrus" of the table on page 181 of this document. I think that in this example the relevant information for the strike tone is provided as "h°±o" in the row "Schlagton / Nominal".) Maybe ask mappers to provide source:strike_tone=*?
• We should think about cases where the bell is a sub-feature. For example, the main tags could either be historic=memorial combined with memorial=bell or man_made=tower combined with tower:type=bell_tower. Detailed information could be provided using bell=yes, bell:strike_tone=* or bell:weight=*.
• If the bell rings at given times (e.g. every full hour), then it is typically combined with a clock: clock:chime=bell, bell:service_times=* ? See also Talk:Tag:amenity=clock#Sounds.

Biff (talk) 14:07, 5 May 2026 (UTC)

"amenity" vs "man_made"

I'd prefer man_made=bell, because bells isn't "amenity" in strict sense. Something B (talk) 12:08, 20 June 2023 (UTC)

By now, both amenity=bell and man_made=bell appear to be in use. Which properties makes a feature an "amenity"? For example, it appears that public clocks are tagged with amenity=clock. Such clocks provide a visual time signal. A bell frequently provides an audible time signal, so why is it not an amenity? I don't really care which key is used but would like to write down a robust rationale for the decision. --Biff (talk) 12:04, 5 May 2026 (UTC)