Talk:Tag:amenity=bench

Rendering proposal

This should probably be rendered as a symbol overlay, similar to the current toilets or recycling nodes.

• 

Looks like a capacity=1 bench, a/k/a seat. Jidanni (talk) 05:11, 16 September 2023 (UTC)

More details

I had some ideas for more details to put into subkeys. (Maybe I should say this in the Proposed_features/Bench_detail page, but that seems to be in the voting stage already.)

• Some benches are dedicated to the memory of some person. I always find it interesting to read those. Is it an idea to create a tag for that? It might be useful for identification of the bench too. Or are there privacy issues? Anyway, just an idea.
• Perhaps more useful piece of information: some benches have been made anti-homeless, i.e. bars across the bench that prevent people from lying on it (e.g. here). I find those less comfortable usually. Also, it's not as nice to sit on it with two people, and some people might not fit on them if the bars are too close to each other.

Mtcv 11:20, 24 April 2009 (UTC)

Oh no! More "rich people" that show how much they detest poor people! They detest them so much that in their ignorance they make bad benches for themselves with no backrest! Logictheo 18:28, 28 September 2009 (UTC)

Mtcv, there's a project called OpenBenches which has its data licensed as CC BY-SA 4.0. --Reuben (talk) 08:53, 17 April 2019 (UTC)

backrest=yes/no, a great idea

I just wanted to say that the backrest option is a great idea. I have problems with my back, and other parts of the spine too. Logictheo 06:08, 29 June 2009 (UTC)

What is implied by default? --Pander (talk) 07:24, 7 October 2013 (UTC)

When it's not given, with 300 000+ benches already entered, all we can say is backrest=unknown. However, every third bench has the tag. Alv (talk) 07:56, 7 October 2013 (UTC)

picnic tables

How about picnic tables with benches? It's in a way more than only a bench. --Kslotte 18:56, 15 July 2009 (UTC)

I believe there's already an extra tag for that with amenity=picnic_table. Not too sure anymore though, better research it.

Yes it exists. --Kslotte 15:29, 23 January 2010 (UTC)

I can confirm too. I think it makes sense to add bench property tags to the picnic_table. --nicorikken 07:44, 12 July 2020 (UTC)

leisure=picnic_table exists and allows bench=* but the page states that picnic tables are assumed to have seats so this would generally be unecessary. Bompstable (talk) 16:43, 15 May 2024 (UTC)

Why only as node?

The current feature only allows benches to be tagged as nodes. However, I recently came across a very long bench (~50 m I guess) which would be more suitable tagged as way. Are there any cavets to look for? I couldn't think of any, apart from the rendering issue of course. What would have to be done to make this open for suggestions (the approve/oppose scheme, I'm new to map features voting). Xeen 20:06, 4 January 2010 (UTC)

I agree, sometimes there are very long benches ... maybe its possible to tag an line as bench  ?? --Gauron 11:36, 4 October 2010 (BST)

Well it seems to be documented as node, way, or area now (a bench as an area??) I'll write a sentence stating that it would normally be suitable to map it as a node though - Harry Wood 11:04, 26 December 2011 (UTC)

There is a "bench" in the town where I live. It's actually a hexagonal structure. Not six benches arranged in a hexagon but a continuous, unbroken hexagon of bench. In the interior is a plant container with a shrub in it. Half a mile from that is a tall square stone structure (serving no apparent purpose) with a stone ledge that serves as a bench around the perimeter. Some benches are complex. Brian de Ford (talk) 11:22, 9 August 2018 (UTC)

I would also like to map it as an area. Proposal? --Lectrician1 (talk) 20:26, 11 November 2020 (UTC)

Council rings

here we have council rings, which would be a C-shaped way bench. Alas, way benches are currently not rendered. Jidanni (talk) 16:02, 12 August 2023 (UTC)

osmarender yes

in osmarender, currently (2011/08) it is render ok.

Render on OSM

Hello.http://wiki.openstreetmap.org/w/index.php?title=Talk:Tag:amenity%3Dbench&action=submit#

All nodes with this property are not displayed on OSM map.

Why ??

--ComputerHotline 16:03, 6 May 2012 (BST)

They are, but only at the tightest zoom levels. I think they need to be displayed a couple of levels lower. I've wasted lots of time logging positions of benches (and bins) that didn't show on screen when I surveyed, only to find later that they're already mapped but had not been rendered. If anybody knows how to pass that on to the renderer team it would be good if they could do so.

--Harg (talk) 08:32, 23 June 2016 (UTC)

direction=north

Please note, that there is now a key direction. I assume (not mentioned) that direction=north means that a person sitting on this bench will look northwards. Could anybody, please, confirm this; and possibly add this hint to this lemma?

Thanks --RalfG (talk) 22:13, 6 March 2014 (UTC)

I can confirm that this assumption is correct. A mention of the key has been added to the page since. --Tordanik 03:28, 10 August 2018 (UTC)

inscription=...

Many benches, especially in parks, have an inscription such as "Donated by..." or "In memory of..." Should we have an optional inscription=... tag, or maybe more specific tags such as donor=... or memorial=... ? --Harg (talk) 08:41, 23 June 2016 (UTC)

I am looking for such a tag as well (this bench). There was a proposed feature for inmemorium. I don't see any fit in the names-category. Memorial does not feel right ("too important"). Inscription does not feel perfect, but kind of the best fit here.

"allows room for several people"

So, a seat in a public place that holds only one person should not be mapped as a bench? There are many one-seater benches in Queen Elizabeth Park, London and we don't have another tag to describe them.

Actually most dictionaries define "several" as "more than two but fewer than many". So in theory even a seat for two doesn't qualify as a bench.

Rather than invent a new tag, I'd suggest changing this to "allows room for one or more people".

--Harg (talk) 06:23, 2 April 2017 (UTC)

I agree. Chrabroš (talk) 01:09, 3 April 2017 (UTC)

Yeah, in the lead photo of the article, imagine it being squeezed into just a one-person version. That is just a good old-fashioned chair. Therefore we need a way to map chairs! Therefore a chair is simply a one person bench! So please somebody mention that on this article. Jidanni (talk) 23:58, 15 December 2022 (UTC)

Chair, Seat

So a chair, or (single) seat, is a capacity=1 bench. OK.

But iD prompts for seats=*... Jidanni (talk) 05:13, 16 September 2023 (UTC)

seats=* is the de facto way to specify the number of people that can comfortably sit on the bench. Use of capacity on benches is deprecated in iD's schema.
https://taginfo.openstreetmap.org/tags/amenity=bench#combinations shows 410,347 usages of capacity and 2, 221 of seats. At present, this page's top-level description of seats=* contradicts the more up to date information in Key:seats. Bompstable (talk) 14:15, 15 May 2024 (UTC)

I have updated the page to make this clear and have removed the capacity key. Bompstable (talk) 16:45, 15 May 2024 (UTC)

How to detect benched without separted seats?

The tag seats implies arm rests in between the seats on a bench. Usually to prevent people laying down. How can one differentiate in OMS between a bench doesn't have individual seats and a bench for which this details hasn't been mapped? Define for example seats=unified/undivided/unseparated ? Pander (talk) 13:17, 27 August 2017 (UTC)

Some people in France uses armrest=yes/no to say if there are armrests. --PanierAvide (talk) 13:24, 27 August 2017 (UTC)

Thanks. Some benches without separate seats, do have armrests only at the end, so this might be confusing unless more strictly defined. Pander (talk) 14:05, 27 August 2017 (UTC)

Maybe by refining this armrest=* tag with more precise values, like "individual", "extremities" or whatever provides a clear description of where they are located ? --PanierAvide (talk) 16:55, 27 August 2017 (UTC)

Disagree that the tag seats in any way "implies" armrests. A bench which seats 3 people still seats 3 people even if there are no armrests. A separate armrests tag is needed if we want to make it clear that a bench has armrests. The tag seats should imply only that a certain number of people can sit on it simultaneously.--Harg (talk) 07:07, 28 August 2017 (UTC)

Some benches are too short to usually allow laying down on it. So it seems that we need an explicit way to indicate whether one can lay down on a bench or not. Like in the following discussion. --Tuxayo (talk) 10:38, 3 April 2019 (UTC)

Per this discussion, I'm removing the line on the page that seats=* should only be used when there are separators. That doesn't seem to be how various presets use it, or most of the existing uses. It's certainly not how I understood it. JesseFW (talk) 23:43, 16 July 2022 (UTC)

sleeping=yes/no

Considering the growing number of homeless people in cities all around the world, I realise it's laking a complementary tag for benchs. Since it already has many deeply descriptive additional tags at https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dbench#Optional
wouldn't it be usefully informative, also with a social commitment imprint, if it could be added a tag like
sleeping=yes/no or, alternatively (if it might be in conflict with outside slepping local laws), perhaps just
continuous_seat=yes/no . Or sleeping_barrier=yes/no, homeless_barrier=yes/no. What do you think? Sergio (talk) 11:00, 24 January 2018 (UTC)

I think when choosing the tagging, we should consider two factors: It has to be verifiable, and the best tags also allow for more than one use case (as that means people with different reasons for gathering the data will be able to join forces to get better coverage).

So instead of sleeping=yes/no, it might be better to stay closer to directly observable properties. For example, this bench has gaps between separate seats, and has armrests. I would suggest to capture these facts as they are, for example using armrests=yes + separate_seats=yes. --Tordanik 14:55, 27 January 2018 (UTC)

What about benches that are too short to usually allow laying down on them? (like the all the benches of all bus stops of Marseille (2nd/3rd city in France))

--Tuxayo (talk) 19:21, 3 April 2019 (UTC)

length=*? The value doesn't need to be super precise, and it should even work for benches that are only too short for tall people. --Tordanik 19:59, 4 April 2019 (UTC)

Multiple materials

Some examples of material=* with multiple, semicolon-separated values have been added to the page. As is often the case with the semi-colon value separator, I believe this is less useful than just tagging the predominant material. A data consumer faced with iron;wood has no idea which parts of the bench are made of iron, and which are made of wood. As the seats of the benches in the example images are made from wood, I would tag them as material=wood. If people also want to map the material of other parts of the bench, I would prefer separate keys for that: material:legs, material:backrest and so on. --Tordanik 21:08, 24 January 2019 (UTC)

My fault :) Just wanted to show some practical examples and not only a simple gallery without tags. Didn't thought about that. Seems good to me using only the seat material. Zermes (talk) 12:45, 25 January 2019 (UTC)

I have specified that material=* should relate to the seating and simplified the values.--Supaplex030 (talk) 12:36, 2 September 2020 (UTC)

How to map special types of benches?

How to map this type of bench?

maybe a bench=*-Key or we could maybe also work with the backrest=*-Key. Maybe backrest=rounded?

Maybe this is a bit similar like amenity=lounger ?--MalgiK (talk) 17:59, 6 May 2020 (UTC)

Could be an edge case for bench:type=lounger without amenity=lounger really being applicable (one cannot really lie down, rather "sit in a lying manner")?--Supaplex030 (talk) 12:41, 2 September 2020 (UTC)

There are actually 133 more descriptive bench=wave_lounger instances.

bench=wave_lounger

		$1%
		$1%
		$1%
		$1%

More details at taginfo

More details at taginfo

--- Kovposch (talk) 06:46, 26 January 2022 (UTC)

Some other weird benches: https://imgur.com/46mmMSr https://i.imgur.com/WbqCxKZ.jpg (https://www.openstreetmap.org/node/9552854466) Pietervdvn (talk) 12:17, 29 March 2022 (UTC)

Add bench:type to "see also" section

There is Key:bench:type (which did not have a wiki page until now) with nearly 900 uses. I would like to add it to the "See also" section. Any objections? --Tordans (talk) 20:05, 1 September 2020 (UTC)

I propose a chapter "Advanced properties" (or similar) for this, e.g. with bench:type=*, armrest=*, length=* or special cases such as memorial benches with inscription=* etc.--Supaplex030 (talk) 12:49, 2 September 2020 (UTC)

For this we could also look through the thread "Benches and hostile architecture" on tagging mailing list.--Supaplex030 (talk) 12:51, 2 September 2020 (UTC)

Material vs. surface

How to tag a concrete bench with a wooden surface (example)? I thought about material=concrete + surface=wood (analogous to how the material and surface of bridges are tagged), but the wiki says material=* is for the material of the seating. So how to tag the main material of a bench then? --Dafadllyn (talk) 20:25, 10 May 2021 (UTC)

It may be intended for the material of the seat body vs the legs. Your tagging should be fine. ---- Kovposch (talk) 06:51, 11 May 2021 (UTC)

 Agree. --Lectrician1 (talk) 00:19, 14 May 2021 (UTC)

Thank you both! I've documented surface=* and added a tagging example of this bench. --Dafadllyn (talk) 20:17, 14 May 2021 (UTC)

bin=yes

Why adding bin=yes or bin=no to a bench? They should be mapped as separate objects. We could also add it to any other object, like building=yes+bin=yes, leisure=park+bin=yes, etc. I suggest removing it from tags. maro21 22:49, 25 June 2022 (UTC)

Well I just knew about Key:bin and when I added two benches yesterday I though I'd check that article and it says "Presence of a waste basket at/in a facility like bench=*, shelter=*, public_transport=platform." a bench is even listed in the examples so I thought it would be a good idea to have that tag also in the benches article. But if this is general unwanted, it should be documented in the bin article too. I think buildings and leisure parks are to big facilities for this tag but a highway=street_lamp could be fitting on the entrance=main of a building. -- Deus Figendi (talk) 03:20, 26 June 2022 (UTC)

I'd say bin=yes/no is still ok for public_transport=platform (because the bin is in the bus stop area), but I don't see how the bench is related to the bin. I think they are usually separate. maro21 10:51, 26 June 2022 (UTC)

Okay, in fact I don't care if I map them seperate or in one node. Or just in one node if the waste basted is mounted to the bench or whatever. My intention was to keep the wiki consistent so if the bin=* article says it should be used on benches than the amenity=bench article should also represent it or both should not. Now I just read Wiki_guidelines#Conflicting_information and it says "Tagging recommendations should ideally match actual tagging practice, unless there is a valid reason not to do so." so I checked taginfo and it says bin=* is mostly used on benches. So I tend to keep it there because it represents current practice. -- 12:38, 26 June 2022 (UTC)

Of course you're right the Wiki articles should be consistent.

bin=* is not mostly used on benches - the link to taginfo you gave lists bench=*, not amenity=bench - they are both used with highway=bus_stop.

My point was that the fact that there is a bin next to the bench is not a property of the bench (but may be a property of the bus stop). maro21 13:23, 26 June 2022 (UTC)

You're right, I've been a little in rush when interpreting the taginfo. the other way around shows that only 0.35% of all bin=yes are combined with a amenity=bench, this is pretty few. So I agree, the combination should be removed from both articles. I'm not familiar with the rules and the conventions on this wiki, is a voting common or even needed? Or can just one of us do this? -- Deus Figendi (talk) 14:37, 26 June 2022 (UTC)

Voting is used only for proposal process, to describe actual tag use simply edit page Mateusz Konieczny (talk) 14:43, 26 June 2022 (UTC)

Meaning of line direction

Did not find it on wiki, so I propose to define left side of a bench (when it is mapped as open or closed line) as a back (backrest) side. And on the right, respectively, the front (side from which you need to sit down). Benches with backrest=no sometimes also have pronounced front and back side.

Use two_sided=yes, if bench can be used from both sides. --Richard Try (talk) 14:36, 20 January 2023 (UTC)

A possible problem with that is existing data (which didn't pay attention to the line direction). There are over 27,000 lines tagged as benches -- how are we going to confirm they are correctly tagged according to this? Instead, I think using Key:direction is likely a better idea, as it's already supported, and can be added incrementally. But using Key:two_sided does seem like a good idea. JesseFW (talk) 15:07, 20 January 2023 (UTC)

If existing line is tagged with Key:direction, let's use this value. Otherwise, no information is provided, so this proposal can not brake something.

Key:direction is useful for nodes, but is can't be extended for long complex benches which usually uses lines instead of nodes.--Richard Try (talk) 17:25, 20 January 2023 (UTC)

The problem is that all existing (over 27k) benches-as-lines already DO specify a line direction; it's just been (up till now) meaningless. So without an additional tag (or by looking at when it was created, which is unusual to do), we can't tell if the specified line direction is intended to define the side with the backrest or not. JesseFW (talk) 19:04, 20 January 2023 (UTC)

I agree. But do we need to know if the sides is not specified? This knowledge will be used by 3d-renderers primarily, and it will draw backside randomly anyway.

Backward-compatible variant is to use side=left/right/both for sides opened to sit. Tag:two_sided=yes is not needed in this case (surprisingly 0 uses of this bench+side combination according to overpass turbo). --Richard Try (talk) 21:14, 20 January 2023 (UTC)

Ah, Key:side is a much better solution. Well spotted, please add it to the page! JesseFW (talk) 16:00, 21 January 2023 (UTC)

Closed ways too!

Just like barrier=fence often surrounds things, many benches surround trees, fountains, artworks, etc. as circles and squares etc. Jidanni (talk) 23:01, 30 January 2023 (UTC)

I'm not sure if those would be better handled with multiple separate points, though? If we want renderers to support closed ways, we need to think further about exactly how. JesseFW (talk) 16:14, 31 January 2023 (UTC)

I would support closed ways for benches, too (and already used it for large benches around trees, which consist of one part – there is simply no other way to draw it clearly, at least not with nodes). I actually think it's pretty obvious how to handle this: the default should be that closed ways should be interpreted like open ways of a bench, and if you want to draw a bench as an area (which should also be possible, I think, e.g. for bench:type=platform), then you should add area=yes. That would be my suggestion anyway (or if you want, you could also add area=no for a closed way which isn't an area) ... Should this perhaps be documented in the wiki? --Goodidea (talk) 06:13, 14 October 2024 (UTC)

Benches with pedals

Image	Tags
	amenity=bench armrest=yes backrest=yes material=wood seats=2 (the pedals make it difficult for more people to use this bench) pedals=yes

@Davileci recently added an example for a bench with pedals tagged with pedals=yes. There is no page for the pedals key and https://taginfo.openstreetmap.org/keys/pedals#overview shows only one usage of the pedals key, used in combination with amenity. This is presumably a bench, but given this tiny usage, I'm not convinced it is worth including in the examples. How many benches actually have pedals in the real world, and would it not be better to record this as outdoor gym equipment anyway? Bompstable (talk) 11:27, 18 May 2024 (UTC)

I might say it can be amenity=bench + leisure=fitness_station unfortunately, if it is not signposted. You could be free to sit on it as usual, or you can exercise on it.
The example can be moved here until there is a solution. But edge cases are still within scope.
—— Kovposch (talk) 10:38, 19 May 2024 (UTC)

I have moved the example here in the mean time. --Bompstable (talk) 12:21, 19 May 2024 (UTC)

Material of the substructure of a bench (and other parts?)

Since 2020/09, material=* has been defined in the wiki as the material of the seating, which makes sense, because according to the definition of material=*, it is intended to indicate the “main material of a physical feature”. The seating can be seen as the decisive factor in a bench and thus declared the “main material” (although there are, for example, benches made of a solid concrete block with a narrow wooden seat, where one could intuitively consider the concrete as the “main material” – see example in “Material vs. surface” on this page). But to keep it simple, I don't think that the definition of material should be changed again.
However, if you want to describe the entire material that a bench is made of, then something crucial is missing (in most cases) – the substructure (and perhaps another material for the armrests?). This could be feet and a frame for the seating and the backrest, or, as in the example of the concrete bench with a wooden seating, a stone block or something similar. The first idea I had was material:substructure=* (or substructure:material=* – because “material” is usually used as a suffix, like building:material=*). Or maybe bench:substructure:material=* (but too complicated?). I found other keys for benches like material:fundament=*, but I don't think that's as good. And If you want to go on with micromapping, perhaps also material:armrest=* (or armrest:material=*)? Or does anyone have a better idea/better wording? I am not a native English speaker, but I think “substructure” would not be a bad term (and easy to understand). Goodidea (talk) 08:17, 14 October 2024 (UTC)

I didn't discuss it in the last post https://community.openstreetmap.org/t/benches-material/100491/
There was an example of surface=* from that topic, which was removed in the recent significant editing https://wiki.openstreetmap.org/w/index.php?title=Tag:amenity=bench&type=revision&diff=2710046&oldid=2685371
What I meant in 2021 is focused on the horizontal slab supporting the seat vs legs vertically. So the "seating" may refer to the body below, rather the sitting surface per se.
Eg this has wood inside a metal frame on metal legs https://www.amazon.de/-/en/Outdoor-Stainless-Anti-Corrosive-All-Weather-Backrest/dp/B0C623FF69
It can't be concluded that all the material=* on amenity=bench necessarily refer to the seat surfacing. Many of them is likely a single material. Then the use material=wood is influenced by wooden planks on metal legs, for the "main" material. It hasn't exactly been decided whether it's "main" , or the surfacing. There are mostly assumptions. So the case hasn't been made for wood-plank-on-stone-block. Another potential limitation is if you see one afar (eg street imagery), but didn't have a close view, you may not clearly see the seating on top, or embedded inside.
I might only use material=* when it has a very clear main identity, or even all the same. It can be considered unspecific.
support:material=* raised previously is mismatched. support=* can refer to either where the load is transferred to, or the joining structure. This can be seen in support=wall (however again, the meaning can't be assured) vs support=wall_mounted where they are attempted to be differentiated. Then does support:material=* refer to the walls, or the connecting frames?

• Cantilever bench along the side of a wall https://www.astrastreetfurniture.com.au/london-bench-wall-mount/
• Seating on top of a dwarf wall or block https://www.commercialsystems.com.au/product/wall-mounted-bench/
• Even seating on frame on top https://wishboneltd.com/site-furnishings/commercial-benches-and-chairs/wall-seating/item/bayview-wall-top-bench

It's a reason why I don't like support=* , besides how there's another word in lamp_mount=* , camera:mount=* , lit:mount=* , post_box:mounting=* , etc. But the meaning is still all mixed up and inconsistent.

• Talk:Key:support#Mounted instead of support ?
• Talk:Key:support#Mixing support and actual features

I would prefer clearly separating them. And suffixing.

• bench:structure=*
  • bench:structure=frame
  • bench:structure=solid
  • bench:structure=column
  • bench:structure=cantilever
• bench:material=*
• seats:structure=*
  • seats:structure=solid
  • seats:structure=planks
  • seats:structure=perforated
• seats:material=*
• backrest:material=*
• armrest:material=*

bench:type=* has a meaningless suffix. It doesn't conflict with bench=* . Overloading is widely done.
On an unrelated note, I wonder whether all the material=wood are accurate. There are recycled plastic resembling wooden planks.
—— Kovposch (talk) 12:59, 14 October 2024 (UTC)

Hello Kovposch! Thank you for your long and detailed answer. I'm sorry that I'm replying so late. I basically agree with what you wrote. Basically, I think:

• material=* is defined in the Wiki as follows: "describes the main material of a physical feature". This should probably also be applied to benches - and I would not be opposed to seeing the seating as the main thing and therefore the main material in a bench. (Even though I have previously tagged typical benches with a metal frame and wooden beams as the seat with material=metal;wood.) That would then correspond to the current Wiki definition (and would not need to be changed).
• And as for the problem you mentioned, that you don't know, for example, whether a bench tagged with material=wood means a bench made entirely of wood or just with a wooden seat (and, for example, a metal frame), I would say: that's correct, but I think that with a single value for material you can always assume that (at least) the material of the seat is made of this material, so you could leave this definition as it is. And of course, nothing can really be said about the overall materials of the bank in such a case – this could then be supplemented by new, additional tags. The material=* tag would then only need to be changed (or checked) for benches with multiple values such as material=metal;wood – in the majority of cases this will probably mean that the seat is made of wood and the frame is made of metal. In theory, of course, it could also mean that the seat is a combination of metal and wood, or that the frame is made of wood and the seat is made of metal. Or that the bench is made of wood but has metal armrests. Or or or ... This can probably only be resolved/clarified by individual checks on site, ideally with subsequent microtagging with new detail tags. I don't see a better solution... (By the way: it would be best to mention in a definition for the material that small parts such as screws or nails should not be taken into account – perhaps a note like "please don't do nano-mapping with materials of small parts like screws and nails".)
• I think new tags would be very useful and important for microtagging all other parts. All we really need to do is agree on their names, cover as many possible cases as possible and of course define exactly what is meant by them (ideally directly derivable from the tag names). I don't think your list of possible tags is a bad starting point, but I have a few questions:
  • What is your definition of bench:structure? Does that mean the type of overall structure of the bench or the type of the structure below the seat and/or a backrest (which I would rather call "substructure")? And if you mean the overall type: what exactly do you have against bench:type=*? (I didn't understand your comment "bench:type=* has a meaningless suffix" – do you mean that you could just use bench=* for the type?)
  • What exactly do you mean by bench:structure=solid? Does this mean that the entire bench is made of one solid material, like a seat carved into a tree trunk? Or a stone block (without a wooden seat on it)?
  • What exactly do you mean by bench:structure=column?
  • Why such an unusual term as "cantilever" (not very self-descriptive)? Wouldn't bench:structure=frame + support=wall_mounted be better (in a case like that: https://www.astrastreetfurniture.com.au/london-bench-wall-mount/)?
  • What does bench:material=* mean according to your definition? A list of all the materials that a bench is made of? I would probably argue for doing without this tag because it clashes with material=*. That would be too confusing for mappers.
  • What should the tag be for the material of a metal frame (= very common case)? bench:structure:frame:material=metal? Or frame:material=metal? Or something else? Because what I'm most concerned about is exactly the material tagging for the most common type of bench in my city: benches with a metal frame with wooden planks as a seat (with or without armrests).
  • How would you tag a bench made of wooden planks that are mounted directly on a block of stone? So: bench:structure=? + material=wood for the seat – and how to tag the stone block? (With a support tag like support=stone?) Wouldn't my idea with bench:substructure=stone also be helpful here?
  • How would you tag the material of the substructure if it is a metal frame that is mounted on a stone block like in your example: https://wishboneltd.com/site-furnishings/commercial-benches-and-chairs/wall-seating/item/bayview-wall-top-bench? Especially for a case like this, I thought my idea substructure:material=* was not bad (here, for example, substructure:material=metal;stone), because, for example, frame:material=* is not ideal here (or not sufficient).
• What I would not use is the key surface=* for the surface of the seat (I know you didn't suggest that either, but it is or was used that way), because so far in the whole wiki surface=* has only ever been defined as the surface of roads/ways – with values specified and defined quite precisely for that. I would not be happy to misuse this for a surface material for benches.
• I also think the support=* key is only of limited use for benches, but on the other hand it is very clearly defined and can be used if you want – in some cases it might be helpful! For most benches support=ground would probably be the appropriate tag ("The feature is directly put on the ground"), for the "cantilever" bench you linked to I would use support=wall_mounted. There may also be support=fence and others. And I agree – I also wouldn't use a key like support:material=*! This is too unclear and ambiguous.

For the next step, I think it would be a good idea to look for photos of benches on Wikimedia Commons (which you could also use on the Wiki page, unlike manufacturer photos) that cover as wide a range of possible cases as possible and then make suggestions for the most suitable tags. Here is a gallery of some photos from Wikimedia Commons (with a few special cases) – you might be able to choose some from them for tagging examples, and some could perhaps be used for the wiki page:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

• 

  Suggestion for microtagging of material(s) and optional bench type/structure/support:

Last question: Should this be discussed further in the forum, or can we come to an agreement here ... or would it have to be an official proposal? --Goodidea (talk) 01:45, 5 January 2025 (UTC)

However you all decide to define the parts, the *:material=* suffix is probably the best solution for unambiguous micromapping.
seat:material=* + backrest:material=* + armrest:material=* + leg:material=* + etc...
I would expect that most mappers intend the material=* and surface=* tags they've added to be equivalent to seat:material=*. Lumikeiju (talk) 02:14, 5 January 2025 (UTC)

@Lumikeiju: For me it is quite clear that a *:material=* suffix is the best solution - that is what I wanted to express above. And what you wrote, that the tags material=* and surface=* are to be regarded as equivalent to seat:material=*, I also wrote - but that is only correct for single values such as material=wood and no longer for material=metal;wood, for example! For further questions that arise with single or multiple values for material, see above... The key questions that we would really have to agree on are:

• Should we stick to the current definition of material=* for amenity=bench, that this means the seat material/surface? If so (and that is probably the most likely), then a tag like seat:material=* would perhaps be superfluous or redundant.
• Or should the material=* key be viewed as a "skunked tag" where we no longer know what the value is supposed to mean (= that is, strictly speaking, the current situation)? And a review/possible correction according to the current definition seems unlikely given the sheer number of use cases (number of nodes/ways with amenity=bench)? Or that multiple values should simply be left as they are (= unclear what they mean)? Then clearly defined additional tags such as seat:material=* and others for the frame/substructure would make sense... And that was perhaps the approach of Kovposch and the reason for suggesting seat:material=*. @Kovposch: perhaps you could clarify that - including how you imagine how the material key should be handled (particularly with multiple values)?
• What tag before the *:material=* suffix should be used for the “load-bearing components” of a bench (which could for example be a metal frame, concrete legs, a stone block and so on – see photos above)? For me, this is the most important thing that is currently missing. Tags for the material of the armrest or backrest, on the other hand, are quite clear and easy to define. So far I don't see any good suggestion for that (which covers all cases of substructures). I had suggested a term like "substructure" as a general and neutral word – the final tag could be substructure:material=* – but there was no feedback on it yet. I would not use leg:material=* – that would be only one special case of a substructure. Or would something like load_bearing:material=* be appropriate? What do native English speakers say?
• General question: should we use bench:*=* as a prefix for some (or all?) detail tags in order not to invent new main tags, e.g. bench:substructure:material=*? Here again: armrest=* and backrest=* and even seats=* already exist, so I don't see any problem or it would be obvious to use armrest:material=*, for example. But the substructure is a different story... That's why I think it would be a good idea to focus a little on that.

For a better basis for discussion, I used Overpass Turbo to check how many cases of material=* with single values vs. multiple values there are globally. Result: 871055 nodes+ways with single values, only about 10036 cases with multiple values (usually a metal value + wood, or concrete|stone + wood) – that's just a little more than 1% of the single values! However, it can look different regionally. In my city (Saarbrücken/Germany) it is the other way round: 504 single values (mostly wood) and 2005 multiple values (mostly metal;wood). This could be caused by me... Here are the Overpass turbo links: Single values global (Warning: > 200 MB data; Overpass turbo reaches its limits) / Multiple values global. --Goodidea (talk) 19:10, 5 January 2025 (UTC)