<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 9/4/2020 6:24 PM, Mateusz Konieczny
via Tagging wrote:<br>
</div>
<blockquote type="cite" cite="mid:MGQD8N3--3-2@tutanota.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div>Sep 4, 2020, 18:19 by <a class="moz-txt-link-abbreviated" href="mailto:tagging@openstreetmap.org">tagging@openstreetmap.org</a>:<br>
</div>
<blockquote class="tutanota_quote" style="border-left: 1px solid
#93A3B8; padding-left: 10px; margin-left: 5px;">
<div>node and discovered the shelter_type=rock_shelter subtag,
but the map in<br>
</div>
<div>question didn't render it any differently. Revisiting the
site in fair<br>
</div>
<div>weather, I found a tiny crack under a ledge that *might*
have kept a<br>
</div>
<div>child dry. It was very satisfying to delete that node.<br>
</div>
</blockquote>
<div>This seems to be a clear case of incorrect tagging of
something that\<br>
</div>
<div>has not actually existed.<br>
</div>
<div><br>
</div>
<div>natural=rock_shelter and any other tagging of rock shelter
would be equally<br>
</div>
<div>incorrect</div>
</blockquote>
<p>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.</p>
<p>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.</p>
<p>Jason<br>
</p>
</body>
</html>