[Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

[Dave Swarthout]

@Paul,

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.

On Sun, Nov 25, 2018 at 8:23 AM Paul Allen <pla16021 at gmail.com> wrote:

> On Sun, Nov 25, 2018 at 12:40 AM Alan McConchie <alan.mcconchie at gmail.com>
> wrote:
>
>>
>> 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?
>>
>
> My gut feeling is that protect_class is an abomination.
>
> Numbers are fine, where numbers are appropriate.  Like the address of a
> house, or the service
> number for a bus, or the elevation of a peak.  Protect_class is a
> horrible, ugly mess.  You cannot
> easily figure out which value to use (first check with the WDPA, then try
> to figure out from a gigantic
> look-up table which value to use).  To make it easy for mappers, instead
> of just having a list of
> possible values like "national_park," "historical_reserve" or whatever,
> editors will need a look-up
> table (not difficult to code, but unnecessary) from natural concepts like
> "nature reserve" to 57
> (or whatever the number is).  All data consumers like apps will need a
> lookup table to translate from
> number to concept so users can make sense of it (or put up with the
> information that "You are now
> entering a 37").  People using the query tool with the standard carto will
> either have to then go through
> the wiki to do a lookup or such a lookup will have to be built into the
> code that handles queries.
>
> Gut feeling, late at night: anything has to be better than protect_class.
> I must be missing something
> since it presumably went through the approval process and passed, and
> people actually use it, but
> right now it looks like Satan conceived it to torment mappers before they
> die.
>
> --
> Paul
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20181125/3c031286/attachment.html>