<div dir="ltr"><div>@Paul,</div><div><br></div><div>Agree on the confusion and difficulty in using those blasted protect_class numbers. Let those issues be resolved in the boundary tag. I'm already tagging using protect_class along with the boundary tag and for insurance toss in the boundary:type tag. It's a lot of tagging that could be simplified immensely if we could just settle on one. IMO, boundary=aboriginal_lands says it all.<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 25, 2018 at 8:23 AM Paul Allen <<a href="mailto:pla16021@gmail.com">pla16021@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">On Sun, Nov 25, 2018 at 12:40 AM Alan McConchie <<a href="mailto:alan.mcconchie@gmail.com" target="_blank">alan.mcconchie@gmail.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Should we use the single tag boundary=aboriginal_lands for these areas? Or should we deprecate that tag (in other words, reject the proposal) and instead use boundary=protected_area + protect_class=24?<br></blockquote><div><br></div><div>My gut feeling is that protect_class is an abomination.</div><div><br></div><div>Numbers are fine, where numbers are appropriate.  Like the address of a house, or the service</div><div>number for a bus, or the elevation of a peak.  Protect_class is a horrible, ugly mess.  You cannot</div><div>easily figure out which value to use (first check with the WDPA, then try to figure out from a gigantic</div><div>look-up table which value to use).  To make it easy for mappers, instead of just having a list of</div><div>possible values like "national_park," "historical_reserve" or whatever, editors will need a look-up</div><div> table (not difficult to code, but unnecessary) from natural concepts like "nature reserve" to 57</div><div>(or whatever the number is).  All data consumers like apps will need a lookup table to translate from</div><div> number to concept so users can make sense of it (or put up with the information that "You are now</div><div> entering a 37").  People using the query tool with the standard carto will either have to then go through</div><div> the wiki to do a lookup or such a lookup will have to be built into the code that handles queries.</div><div><br></div><div>Gut feeling, late at night: anything has to be better than protect_class.  I must be missing something</div><div>since it presumably went through the approval process and passed, and people actually use it, but</div><div>right now it looks like Satan conceived it to torment mappers before they die.<br></div><div><br></div><div>-- <br></div><div>Paul</div><div><br></div></div></div>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Dave Swarthout<br>Homer, Alaska<br>Chiang Mai, Thailand<br>Travel Blog at <a href="http://dswarthout.blogspot.com" target="_blank">http://dswarthout.blogspot.com</a></div></div>