[Tagging] Feature Proposal - Voting - boundary=aboriginal_lands
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
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”
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>
>> 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
> Tagging mailing list
> Tagging at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging