<div dir="ltr"><div dir="ltr">On Sun, 28 Jul 2019 at 02:36, Paul Johnson <<a href="mailto:baloo@ursamundi.org">baloo@ursamundi.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I'm on board with a state park specific tag.  I find protect class to be a clunky answer and not entirely humanly intuitive compared to something like leisure=state_park<br></div></blockquote><div><br></div><div>+1</div><div><br></div><div>I have no objections to protect_class as supplemental information that data consumers can make</div><div>use of as they wish (including ignoring it).  I have an intense dislike of numbers being used for</div><div>anything other than numeric values because they are not amenable to human inspection.  Sure,</div><div>editors can unobfuscate things by using an internal lookup table, but that isn't a complete solution.</div><div>Compare an overpass-turbo query for leisure=state_park and for protect_class=21.  Use the query</div><div>tool of standard carto and ask yourself how easy it would be to guess what is meant by</div><div> leisure=state_park versus protect_class=21.  Look at the raw tags in the editor (something I</div><div> frequently do, for one reason or another) and see if leisure=state_park makes more or less</div><div> sense than protect_class=21.</div><div><br></div><div>But if we insist that protect_class=21 is a sensible solution, then so is replacing all existing</div><div>top=level tags with things like object=Q1234 and object=Q9876.  Well, that doesn't cope with</div><div>values, so we'd have to replace building=house with object=Q1234 + Q1234=Q9876.</div><div>Obviously (I hope) this is not a sensible solution, but it is merely a logical extension of</div><div>the thinking that gives us protect_class=21 as a top-level tag.</div><div><br></div><div>-- <br></div><div>Paul</div><div><br></div></div></div>