Proposal talk:Bench: replace seats by capacity

Recent change in the recommended usage of seats=*

I was surprised to read that the seats=* tag is also appropriate to use when there aren't marked seats, as I had recently stopped adding it to benches with unmarked seats. It looks like the recommendation was changed on 16 July, and it is now correct to use it for an inferred number of seats.

I thought that should leave a note here in case anyone else is confused in the same way. TwistedSnake (talk) 10:09, 29 September 2022 (UTC)

Thanks for pointing this out! I wasn't aware of this recent change, either. (however, it makes sense in my opinion). --Martianfreeloader (talk) 10:12, 29 September 2022 (UTC)

I do not think that was a good change by @JesseFW: as it makes the tag less objective. Discostu36 (talk) 10:37, 29 September 2022 (UTC)

I think it was a good change. 99% of bench users, when the look for a bench in their surrounding, are more interested in its capacity than its physical width. In most cases, capacity can be estimated fairly well. It is still possible to add width=* in addition if the mapper believes this is a useful information. --Martianfreeloader (talk) 11:13, 29 September 2022 (UTC)

My edit to the page was descriptive, not prescriptive, correcting a misleading description of how the tag is currently used. JesseFW (talk) 18:48, 29 September 2022 (UTC)

Not unique

capacity=* has a mixed meaning of maximum physical capacity, legal, nominal, safe, advertised, or some other measure in other features. The existence of seats=* (although not usage) is not alone, when there is rooms=* and beds=* for tourism=hotel etc accommodation and amenity=hospital as a physical unit. For precision, it is not stated how the number of rooms (what about partitions and shared rooms) and beds (only assuming double is counted as one) is counted either. Elsewhere, *_count=* and a more awkward number_of_*=* (for number_of_apartments=*) are used to be specific.

There will be no nameplate or signpost and other physical reference. eg capacity:practical=* would be better to separate personal estimations from the official number used in other features.

At the same time, something should be proposed for the actual number of physical seats to replace this, to avoid lost of information when seats=* is truly used in such meaning during update. Eg seats_count=* / seats:count=*.
--- Kovposch (talk) 10:28, 29 September 2022 (UTC)

An idea would be to keep the seats=* key for benches with individual seats. But I would give it a boolean value, for example amenity=bench + capacity=3 + seats=yes. --Martianfreeloader (talk) 11:15, 29 September 2022 (UTC)

I agree with the similar beds and also for camp sites we can qualify the kind of lot, so basically “consistency” does not seem to be an argument justifying the hazzle. Seats is clearer than capacity. —Dieterdreist (talk) 11:38, 29 September 2022 (UTC)

Can you explain which "hazzle" you are referring to? The proposal states that no retagging would be necessary. Yet, if somebody wants to do it, it would be extremely easy to automate. --Martianfreeloader (talk) 14:19, 29 September 2022 (UTC)

the hazzle is for all our data users that care for seats, they would have to also look at capacity, we should not make changes to established tagging without a clear benefit that outweighs this cost. —Dieterdreist (talk) 18:35, 29 September 2022 (UTC)

Deprecate it instead

As this tag is very subjective, I think it should be not renamed but removed. width=* should be used instead. Discostu36 (talk) 10:28, 29 September 2022 (UTC)

It is less straightforward to estimate width=*. And there is the question of est_width=*. What about when it curved, or not one-sided? --- Kovposch (talk) 10:30, 29 September 2022 (UTC)

I do not think capacity is straightforward at all. When I am standing in front of this bench I can effortlessly estimate its width (maybe about 2.5 meters). But how many people can sit there? I guess about 8 kindergarten kids or 3-4 overweight adult males. Discostu36 (talk) 10:36, 29 September 2022 (UTC)

Yes! And indeed, how many elephants can you fit on this bench? Jokes aside, I think 98% of all people would estimate capacity=4 in your example. When I'm outdoors looking for a bench on my app, the number of people who can sit on there is a much more useful information than its width. Yes it is somewhat subjective, but it is not very subjective; it can be estimated fairly well with uncertainty of max. ±1. --Martianfreeloader (talk) 11:10, 29 September 2022 (UTC)

It would be trivial for any app to calculate the capacity from a tagged width (which would also ensure that the width per person would be consistent across benches). --Push-f (talk) 12:08, 29 September 2022 (UTC)

@Push-f: So you're essentially proposing that we deprecate tagging seats=* on benches without clear separation, is that right? --Martianfreeloader (talk) 14:27, 29 September 2022 (UTC)

I am not sure. The problem with seats=* is that despite being used hundreds of thousands of times the tag has no clear meaning. So I think giving the tag clear meaning would require massive retagging (like e.g. replacing all seats=* with capacity=*). --Push-f (talk) 15:20, 29 September 2022 (UTC)

The retagging issue is addressed in the Proposal section of the proposal. Do you disagree with what is written there? What do you propose to do? "Things are a mess. This proposal is not good. Let's keep everything as messy as it is." doesn't sound like the best solution to me. --Martianfreeloader (talk) 16:10, 29 September 2022 (UTC)

I agree with your point that the current seats=* might just as well be tagged as capacity=*, however I doubt that "using capacity everywhere is more consistent" is a strong enough argument to retag 300k elements ... I am not even sure if there ever has been a mass edit to change one tag to another on such a large scale. In general I think that our effort is better spent on more important matters, such as figuring out how to tag hostile architecture, there currently seem to be at least two tagging schemes in use, neither of which seems to fully encapsulate the variety of hostile benches. --Push-f (talk) 17:21, 29 September 2022 (UTC)

seats=* can be used if they are marked. But please not capacity=*. Discostu36 (talk) 10:31, 29 September 2022 (UTC)

Statistics

Currently you show the capacity statistics, but actually the relevant stats are https://taginfo.openstreetmap.org/tags/amenity=bench#combinations 1701 with capacity and 324217 with seats. This is the amount of changes that are proposed. —-Dieterdreist (talk) 11:43, 29 September 2022 (UTC)

Thanks. This stats is shown in the Rationale section, I believe. --Martianfreeloader (talk) 11:50, 29 September 2022 (UTC)

You are right. Seems I was blended by the stats in the infobox ;-) —Dieterdreist (talk) 18:40, 29 September 2022 (UTC)

Already rejected

By the way, using "capacity" for benches was rejected by a voting: Proposed_features/Attributes. --Dieterdreist (talk) 11:48, 29 September 2022 (UTC)

If you read it well (maybe you did and didn't bother mentioning) you would see that "seats" was also rejected. --AntMadeira (talk) 12:07, 29 September 2022 (UTC)

Yep. Plus, that vote is, like, 12 years ago. --Martianfreeloader (talk) 14:17, 29 September 2022 (UTC)

Consistency

I propose for consistency reasons to retag the 1701 capacity=* on benches to seats=*. What do you think? --Dieterdreist (talk) 11:50, 29 September 2022 (UTC)

Thanks for the suggestion. I think: it would be more consistent the way I have proposed it as this is the way it is done on the vast majority of other objects (as I was trying to explain in the proposal). It appears preferable to me to avoid having several synonymous keys in use. --Martianfreeloader (talk) 14:16, 29 September 2022 (UTC)