[Tagging] Feature Proposal - RFC - Tag:shelter_type=rock_shelter

Andrew Harvey andrew.harvey4 at gmail.com
Sat Sep 5 02:57:36 UTC 2020

All good feedback so far, it's pleasing to see I'm not the only one
interested in tagging these features.

On Sat, 5 Sep 2020 at 11:38, Jmapb via Tagging <tagging at openstreetmap.org>

> Assuming that I located the correct crack, it was undoubtedly a case of
> overzealous tagging. The problem I see is that the definition of rock
> shelter is subjective enough that this sort of tagging will happen from
> time to time. Some mappers will stretch the definition because they just
> love adding features. And since rock shelters are currently a subtag of
> amenity=shelter, people looking for amenity=shelter -- with the possibly
> live-saving properties that implies -- will be misled.
> Tagging a rock shelter any other way -- natural=rock_shelter,
> amenity=rock_shelter, whatever -- and we're no longer bound to fulfilling
> the existing expectations of the parent tag.
That's why it's a good idea to use the shelter_type sub tag, to provide
further detail on the type of shelter here and provide further information.

amenity=shelter alone shouldn't have an expectation that it's anything more
than a place to escape a storm to provide some protection. Plenty of bus
shelters in a big storm you'll still get soaked if it's windy as well.

Not all rock shelters / overhangs / endogene caves are the same size, I
guess you could try to tag in meters how far it goes into the rock as an
indication of size.

Overzealous tagging can happen regardless of what the tag is though, even
natural=rock_shelter can be abused for even the most minor feature, same
goes for waterfalls, cliffs, peaks and most natural features.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20200905/8f981189/attachment-0001.htm>

More information about the Tagging mailing list