Conversation
|
🍱 Your pull request preview is ready Please use this preview to check your changes. Ideally use the test documentation template and document your test results by commenting on the PR. This will speed up the review process for everyone. FYI, once this PR is merged, you can use the iD Editor Preview to test your changes in interaction with all other changes. |
|
In 2015, 96% of it was mass added. The |
|
I have read about the mass addition, but still. |
|
|
tordans
left a comment
There was a problem hiding this comment.
I agree the tagging schema can be approved in this area and we should…
But I think the status quo is still too chaotic to add the change currently proposed here.
If we add the type as a field, users will be very motivated to fill it out. For the majority of benches, that will not add any additional information so it is useless added data and costs time. But even worse, I don't see a real "that is a normal bench" value in https://wiki.openstreetmap.org/wiki/Key:bench:type#Common_values … so what would users pick for a regular bench.
We could look for a way to work around this by building the UI in a way that shows the default as "regular bench" and provides a nil value. But I don't think the combo type can do that (can it?).
Another thing that I think we need to resolve is, that we have https://github.com/openstreetmap/id-tagging-schema/blob/main/data/presets/amenity/lounger.json as a preset for lounger. In this case, iD would recommend two ways to map the same thing… The data for lounger is still hugely in favor of the separate tagging https://taghistory.raifer.tech/?#***/amenity/lounger&***/bench%3Atype/lounger — And given the difference in usage, I think that will not change.
What we could do to improve this, is…
- …create separate presets for the most important additional types. But given that all those variations have less than 1k usage and some are pretty new, I am not sure we want to do this. Also, it would require to know what you are looking for when you search for the preset; which is not ideal
- … use a checkbox UI to say "this is a swing" and maybe an additional "this is for standing" which then applies the tag (see schema repo for docs)
- … use a combo dropdown but only provide curated value options
|
also, for https://wiki.openstreetmap.org/wiki/File:Swinging_Bench_in_Towson_Manor_Park.jpg I would tag it as I was not aware that it could be tagged as a bench |
seems unsolved so I plan on closing this PR as rejected |
|
closing per above |
I have been mapping benches for years, and did not have any idea how to map swing benches. Until somebody in the chat hinted at bench:type=swing. And I was like, why this is not in the presets?!
This PR adds a bench type field to the
amenity/benchpreset. No predefined options for this combo, like in other*:typefields: everything should come from Taginfo, and the values are pretty self-explanatory.The wiki page mentions a controversy with the
*:typetags. I believe there is not the case with benches: thebench=*tag almost universally is used to mark a presence of a bench (likeshelter=*andatm=*), so we don't have any other options. Alsobench:typetag has been used on ~3k benches, which is a lot, considering it's not in any presets.Finally, I have added the field into the main fields list, because to me it's pretty important, on par with bench material, or any other feature types, e.g.
crossing=*.