Questons, Comments and discussions go here.
I fail to see the advantages of this. Renderers/Webapps can sort things using whatever categories they like anyway, they don't need different keys for that. As that this is the only example of usefulness provided by the proposal, the reasoning isn't convincing. --Tordanik 17:08, 2 March 2009 (UTC)
- I find this proposal useful if I would tag healthcare facility that I am unsure of the purpose or tag facility of the type which don't have its own tag yet. This is main advantage of hierarchical tagging and is consistent with many other tags already used with yes/more specific value. Maybe the reasoning in the proposal is not very good, but the tag itself is quite useful --Vrabcak 07:37, 6 March 2009 (UTC)
- Of course the possibility of not specifying the exact type of an object is useful in many cases (as with building=*, which is often traced from aerial imagery). However, I can't think of any situation where you might not know whether something is a pharmacy or a hospital. I'd think that it's almost impossible to stand in front of an object, identify it as a medical facility, but be unable to find out what type of medical facility it is.
- About not having an own tag: You can still make one up (and document it asap).
- Nevertheless, that's an aspect I had not thought of so far. It does indeed add to the value of the proposal. --Tordanik 09:42, 6 March 2009 (UTC)
- It's not impossible at all, to identify a building as medical, but not know the list of services it provides. There are several such buildings in my city where I don't know the exact services they provide. Mostly these are just buildings in the street where doctors, dentist and others have an office but share the same reception and waiting room.
- For databases it should be faster to search and select. For humans it is simpler, more correct, more logical and more consistent. Hospitals for example are not amenities. While they are nice to have in the larger area, I don't know anyone who wants a hospital in their backyard.
Not a different tag
For those who think this is about a different tag, it's not. It is the same tags already used, but under a different category. The point is to make things more logical, consistent, simple and correct. Not all the tags that are now categorised under amenity are amenities.
- Well, maybe it's because I never used or even heard the word "amenity" before being involved in OSM, but in the OSM context I always considered "amenity" pretty much a catch-all term for "facility", "thing", whatever.
- It perfectly makes sense to have that sort of key (similar to the "type" key common for relations). "amenity" as a name for that key isn't great, but its traditional. If anything, we should rename "amenity" instead of creating more keys that don't have any value -- because nobody ever needs to use the "hospital" value with a different key. 100% of the information is in the value. --Tordanik 20:49, 17 May 2009 (UTC)
Continuation of the proposal
Due to my current lack of time to invest in openstreetmap, I welcome anyone who wants to take this proposal to the next level to take the initiative to do so.
This proposal was not approved according to the suggested rules for proposals described on Proposed Features: It failed to reach the 15 votes minimum during the regular (extended) voting period. This limit is there for a reason: A small group of mappers shouldn't be able to change widely used tagging as people are trying to do here. In fact, it is even recommended to take other factors (such as current use) into account. If anything, this should even raise the bar for acceptance of proposals that contradict existing tagging.
I don't want to start an edit war, but simply intend to inform those who have been spreading the results of this "approved" proposal all over the wiki that their actions are not properly backed by the voting result. --Tordanik 14:30, 10 August 2009 (UTC)