Proposal:Tag:shelter type=rock shelter

Tag:shelter_type=rock_shelter
Proposal status:	Rejected (inactive)
Proposed by:	aharvey
Tagging:	shelter_type=rock_shelter Data item
Applies to:	, ,
Definition:	A rock shelter is a shallow cave-like opening at the base of a bluff or cliff, which may be used as a place to protect against bad weather conditions
Statistics:
Draft started:	2020-09-04
RFC start:	2020-09-04
Vote start:	2020-10-12
Vote end:	2020-10-26

Proposal

shelter_type=rock_shelter is currently in use with 757 occurrences as of Sept 2020 according to https://taginfo.openstreetmap.org/tags/shelter_type=rock_shelter. It is currently documented as "A rock shelter is a shallow cave-like opening at the base of a bluff or cliff" and to be used as a subtype of amenity=shelter which is "a small place to protect against bad weather conditions".

The intent of this proposal is to formally accept this tag by the community (and if not accepted then ideally come to an agreement of an alternative).

Rationale

While the current tag is documented on the amenity=shelter page and in use 757 times, there is significant community resistance to using this tag on talk-au and further discussed on tagging, and these features are extremely frequently mis-tagged as natural=cave_entrance.

For examples concerns raised by the community are that a natural feature like a rock overhang shouldn't bet tagged as amenity, though I disagree with this point. amenity=shelter never claims it's only for man made features and rock overhang is mostly used as "a small place to protect against bad weather conditions", so this is a perfectly fitting tag. shelter_type=rock_shelter further classifies that it's a rock overhang to help distinguish from other types of shelter like a bus shelter or gazebo in a park.

Furthermore natural=cave_entrance is wrong as this is "An entrance to a cave: a natural underground space large enough for a human to enter", a rock overhang is not like a cave, which is essentially an enclosed cavity with a small entrance opening. A cave you might need a torch to explore, a rock overhang is not like that.

Commonly these rock overhangs are named as "foobar Cave" and that may be why many are mis-tagged as cave entrances, but the name shouldn't have any input into the tagging. There are many other examples within OSM where we don't consider the name. eg McDonalds Restaurants are tagged as amenity=fast_food and not amenity=restaurant even though they might have "restaurant" in the name.

Examples

https://www.flickr.com/photos/136319147@N08/35519846196

External discussions

https://lists.openstreetmap.org/pipermail/talk-au/2019-April/012578.html https://lists.openstreetmap.org/pipermail/tagging/2019-April/044554.html

Comments

I'll leave this page open here for discussion for a few days, and then move to open voting to formalise this tag, but please refer to the existing discussions for further context.

Please comment on the discussion page.

Voting

Voting closed

Voting on this proposal has been closed.

It was rejected with 8 votes for, 8 votes against and 2 abstentions.

no clear consensus

• I approve this proposal. --EneaSuper (talk) 10:13, 18 October 2020 (UTC)

• I approve this proposal. I support this proposal to formalise the existing documented shelter_type=rock_shelter as the way to map rock overhang shelters, important to prevent current widespread misuse of the natural=cave_entrance tag and to aid bushwalkers in locating these important features. --Aharvey (talk) 23:32, 11 October 2020 (UTC)

• I approve this proposal. Good idea --Fizzie41 (talk) 00:01, 12 October 2020 (UTC)

• I oppose this proposal. I don't think natural, shallow cave opening should be mapped as amenity=shelter since that feature is normally man-made, and a rock overhang or shallow cave opening is a natural geological feature. I would recommend use of natural=cave_entrance plus length=* and depth=* in meters, or perhaps a new tag like cave=rock_overhang, instead. --Jeisenbe (talk) 05:59, 12 October 2020 (UTC)

Also, if some of these features are clearly not a cave entrace, then a new natural tag like natural=rock_shelter would be better. --Jeisenbe (talk) 06:00, 12 October 2020 (UTC)

How would you tag a rock shelter that then goes into a larger cave cavity, ie. both a cave entrance and rock shelter? Measuring out the exact or even rough length and depth is very difficult and makes it too hard for most mappers to tag these features. cave=rock_overhang would also then need cave=cave so you can then distinguish rock overhangs from cave entrances. Absolutely it's a natural feature but it's still an amenity for humans to use as a shelter. --Aharvey (talk)

Re: "How would you tag a rock shelter that then goes into a larger cave cavity" - as natural=cave_entrance, certainly. It's the entrance to a cave. --Jeisenbe (talk) 05:00, 13 October 2020 (UTC)

But the actual cave entrance might be locked by a gate so access=private, but the rock overhang which leads to the actual cave entrance with the gate is open. So you'd need to map these as two different objects in OSM. I guess you could add one on the cliff way, and the other slightly inside the cliff. --Aharvey (talk) 00:16, 19 October 2020 (UTC)

• I oppose this proposal. The WikiData tag is facility. This is a subclass of artificial geographic entity, which is defined as opposite of natural geographic entity. This inclines me to think that we should use a tag based on natural=*. Based on the wikipedia articles for Cave and Rock Shelter, I propose natural=rock_shelter. There is however a precedent for a feature which is both natural and an amenity. See amenity=public_bath and natural=hot_spring. Note however that even in this case there is still considerable emphasis placed on the distinction between whether a particular hot spring is man-augmented or not. For example, a hot spring with no signage or other man-made additions would be tagged as natural=hot_spring, but a hot spring with a fence and showers and a sign would be tagged as amenity=public_bath. --Daviewales (talk) 12:32, 12 October 2020 (UTC)

" The WikiData tag is facility. This is a subclass of artificial geographic entity, which is defined as opposite of natural geographic entity" - why wikidata classification (that is full of various kind of problems) would be relevant at all here? Mateusz Konieczny (talk) 09:31, 12 October 2020 (UTC)

• I approve this proposal. I see no problem with using amenity=shelter for features that are 100% usable as shelter and not man made, like I am ok with using natural=beach for man-made beaches --Mateusz Konieczny (talk) 09:33, 12 October 2020 (UTC)

• I approve this proposal. A data consumer would expect a query of amenity=shelter to return all features that can be used for shelter. As such, rock shelters do appear to be a subcategory of all shelters. Tagging the fact that this natural feature provides the human benefit of shelter does not prevent it from being futher tagged with some form of natural=* to additionally describe the type of natural features present. ZeLonewolf (talk) 17:31, 12 October 2020 (UTC)

Re: "expect a query of amenity=shelter to return all features that can be used for shelter" - that is a bad assumption. Most objects that can serve as shelters are tagged building=* in OpenStreetMap, including many building=roof features which are similar to purpose-built shelters in some way. Natural rock shelters and cave entrances are a very small part of the roofs and buildings which are currently not including in this tag. --Jeisenbe (talk) 04:58, 13 October 2020 (UTC)

I don't understand your logic, as a user if it starts raining and I ask "hey OSM where is the closest shelter" then I don't care if it's a natural feature or man made, if it's used as a place of shelter I want to know about it. --Aharvey (talk) 05:03, 13 October 2020 (UTC)

The fact that some types of amenity=shelter can also be tagged with building=* is irrelevant. These tags do not conflict. If an object in the real world has the amenity of a shelter - as described - "a small structure designed to protect against bad weather conditions", it seems reasonable that it can be tagged in that way, regardless of what other physical properties it may have, and regardless of whether the structure is a human-constructed structure or a naturally-occurring structure. ZeLonewolf (talk) 05:24, 13 October 2020 (UTC)

• I oppose this proposal. As per Daviewales's comment, the word shelter hints at a man-augmented feature. I would prefer to see a rock shelter with a natural=* tag. 501ghost (talk) 18:50, 13 October 2020 (UTC)

• I have comments but abstain from voting on this proposal. The given sample image already looks more like a cave than a shelter to me. Maybe with a big entrance and not very deep, but if I am looking for caves, I would like to see the given example. It is even called "Cox's Cave". --Shaun das Schaf (talk) 11:06, 16 October 2020 (UTC)

They are still quite different to a cave that you enter, and would be pitch black inside or need to crawl through. This aids to help distinguish the different types of "cave" like features. All highway=* values are still roads and you could also argue we should just use a single tag for all classifications, but more detail is better. Yeah, here they are all named as XXX Cave, but I mentioned this in the proposal. It's called McDonalds Restaurant but we don't tag them as amenity=restaurant just because of that. --Aharvey (talk) 14:44, 16 October 2020 (UTC)

• I have comments but abstain from voting on this proposal. This tag supplements amenity=shelter, but does not affect natural=cave_entrance per sé. An open rock overhang that is not really a cave might very well be tagged natural=cave_entrance, amenity=shelter, shelter_type=rock_shelter, even if it's not really a "cave entrance". I agree that amenity=shelter suggests (to me) something man-made, so it seems incorrect to apply to a natural unmodified feature, but I can't say it's intrinsicly wrong. (Should we also propose shelter_type=cave?) I think it's worth proposing natural=rock_overhang or natural=rock_shelter separately to disambiguate open "caves" from deep, dark caves. --pkoby (talk) 11:24, 18 October 2020 (UTC)

natural=cave_entrance is described as "cave (natural underground space large enough for a human to enter)." the key point being underground, so by that I've been assuming natural=cave_entrance is not for simple rock overhangs, but only proper underground cave. These rock overhangs are commonly used as a place of shelter, but the whole point was to use the tag which is already in use and already was documented on the wiki. I'm not against using natural=rock_overhang, but it would be extremely frustrating to take that to a vote and have neither proposal reach the required 70% approval mark. The only issue with natural=rock_overhang is it doesn't support distinguishing a cave entrance with a rock overhang at the entrance from without, because the single node can't have two natural keys, whereas as a shelter_type it can. --Aharvey (talk) 12:36, 18 October 2020 (UTC)

• I oppose this proposal. As per other votes above I think it implies a man made structure. I prefer Jeisenbes suggestion of cave=rock_overhang for the features of this type I have recently observed --Ralley (talk) 18:19, 18 October 2020 (UTC)

• I approve this proposal. --P3tr0viCh (talk) 03:21, 19 October 2020 (UTC)

• I oppose this proposal. For the reasons others have noted, I'd prefer this to be categorized under natural=*. --Carnildo (talk) 03:54, 19 October 2020 (UTC)

• I oppose this proposal. I agree that this should not be a subtype of shelters, which are man-made. natural would be a better match. --Nop (talk) 18:24, 19 October 2020 (UTC)

• I oppose this proposal. For the same argument as Jeisenbe, pkoby (and others) I propose a different solution. There is real gap in tagging of natural shallow-cave features like this, that might or might not be usable as a shelter. It would be wrong to tag all of them like they were a shelter. So instead I propose to use natural=rock_overhang or natural=shallow_cave. In case it can be used as a shelter some can also add shelter=yes and shelter_type=rock_shelter there. Thanks for striving for agreement here, this is very valuable! --SLMapper1 (talk) 11:56, 20 October 2020 (UTC)

• I oppose this proposal. A natural rock feature should be natural=*. If it is desired to distinguish shallow overhangs from deep caverns, this could be achieved using depth=* (metres). --Roger Browne (talk) 20:11, 20 October 2020 (UTC)

With using depth=* you are easily back in the "we don't map caves" discussion (the entrance has no depth): How to correctly measure the depth, is height and width also important,... --SLMapper1 (talk) 00:16, 21 October 2020 (UTC)

• I approve this proposal. --Dieterdreist (talk) 21:57, 20 October 2020 (UTC)

• I approve this proposal. --Rtbk (talk) 05:52, 22 October 2020 (UTC)

• I oppose this proposal. I think mapping the use of a real-world object is secondary to mapping what the object is. To do so I would support a tag like natural=rock_overhang. That way amenity=shelter is implied, and if this an "popular" shelter (i.e. if it has a name or infrastructure) one can add amenity=shelter and related tags. --Gileri (talk) 12:18, 25 October 2020 (UTC)

Gileri's suggestion seems like a very workable solution. --Roger Browne (talk) 07:01, 26 October 2020 (UTC)

But by voting no you've directly said you shouldn't tag these rock overhangs as amenity=shelter, this proposal never said you can't also tag these features with a natural tag like natural=rock_overhang as an additional tag, it just said that it's valid to mark ones which provide shelter, including popular ones with a name and other infrastructure like wood logs for seating as amenity=shelter. If you wanted to also use amenity=shelter on the popular ones together with a natural=* tag then you should have voted yes to approve this and then later on worked on a natural=* which can be used together. --Aharvey (talk) 07:13, 26 October 2020 (UTC)

Gileri's suggestion was very specific about using "natural" for natural features, and restricting the use of "amenity" to specific cases where an amenity is provided or designated, which is consistent with what I had advocated in the discussion. As for how I "should" have voted, I consider the status quo to be better than the proposed change, which would have introduced inappropriate uses of "amenity". Although this proposal has not passed, the work put into it is not wasted because it has helped to clarify many of the issues surrounding these overhangs. --Roger Browne (talk) 08:28, 26 October 2020 (UTC)

Okay, usually my rule of thumb for designated is signposted, certainly many of these rock overhangs are commonly used for shelter, but not usually signposted as such, but there could be some like that so I see where you're coming from. --Aharvey (talk) 09:05, 26 October 2020 (UTC)

That's exactly what I think :) --Gileri (talk) 13:28, 26 October 2020 (UTC)

@Aharvey thank you for the effort you spent in making this proposal. In my opinion the outcome says: We first need to have a natural feature describing rock overhangs / shallow caves. After/along with this we should discuss how to tag such overhangs that are / can be used as a rock_shelter as a special form of the first (not the other way round like done here). Question: As I am not familiar with this: Is it desirable to have a natural=* and a amenity=* on the same object? Or should only "weak keys" (not sure if such a concept even exists or all keys are treated the same) be used like shelter=yes and shelter_type=rock_shelter --SLMapper1 (talk) 08:51, 26 October 2020 (UTC)

@SLMapper1 yes this is the conclusion I came to and therefore created Proposed features/Tag:natural=rock overhang and seeking feedback on that draft before opening it for voting. I don't see a problem with having both natural=* and a amenity=* on the same object. I wouldn't want two tags for the exact same thing, so long as we can distinguish them and they are for slightly different things (even if overlapping) that should be okay. --Aharvey (talk) 09:05, 26 October 2020 (UTC)

Thank you Aharvey for both proposals and furthering the debate. --Gileri (talk) 13:28, 26 October 2020 (UTC)