[Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

Joseph Eisenberg joseph.eisenberg at gmail.com
Sun Nov 25 01:35:17 UTC 2018


Thank you for reviving this proposal. I believe it’s possible that both are
needed.

American Indian and Alaskan Native Nations in the USA have a good deal off
autonomy and administrative power and certainly should be considered a type
of administrative boundary, but outside of the usual numeric admin_levels
system. I believe this is true for Canada and Australia as well.

it is possible that the areas in Brazil or other countries lack as much
political/administrative function, and are more of a “protected area”
without self-governance.
On Sun, Nov 25, 2018 at 10: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20181125/aa9e6776/attachment.html>


More information about the Tagging mailing list