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)

If a bell is placed on a tower, man_made=bell can conflict with man_made=tower. How can this be resolved? Maybe use separate nodes and add support=tower to the bell's node? Biff (talk) 08:25, 10 August 2026 (UTC)

Or use a node relation as described in Proposal:Node? Biff (talk) 13:43, 10 August 2026 (UTC)

Automatic carillon (German "Glockenspiel")

Would it make sense to define separate tags for automatic carillons (as in https://de.wikipedia.org/wiki/Glockenspiel_(Spieluhr) ) and manually played carillons? I suppose that the listener will frequently not be able to tell the difference. Of course, an automatic carillon will typically use the tag service_time=*. Biff (talk) 09:34, 11 August 2026 (UTC)

Based on https://en.wikipedia.org/wiki/Glockenspiel_(disambiguation) the answer is no. In English it does not matter if the carillon is played manually or automatically. The next question might be how to treat combinations of less than 23 bells. It appears that sound=chime is appropriate in this case, see https://en.wikipedia.org/wiki/Chime_(bell_instrument).

Railroad crossing and similar warning bells

• 
• 
• 

I found one instance where the bell of a railroad crossing has been tagged with amenity=bell: https://www.openstreetmap.org/node/13519975759 . Above, I have added a gallery of bells that are used for such and similar purposes. The current scope of the proposal ("This proposal only covers bells that are either very visible or audible or have touristic value") does not exclude them. Maybe add bell=alarm combined with bell:purpose=warning (similar to siren:purpose=*)? The latter might be combined with warning=level_crossing (a few instances of that tag can be found on taginfo: https://taginfo.openstreetmap.org/tags/warning=level_crossing). Biff (talk) 14:44, 13 August 2026 (UTC)

Maybe bell=level_crossing as used in the example mentioned above is a better solution than bell=alarm if the bell indeed warns of a railroad crossing. bell=alarm would be too general and could apply to almost all bells. In the past, also church bells were used as alarm bells to make people aware of fires and other hazards. Therefore, the tag should be more specific. Biff (talk) 09:33, 20 August 2026 (UTC)