[Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

Paul Allen pla16021 at gmail.com
Sun Nov 25 01:22:06 UTC 2018

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20181125/03be4d4a/attachment.html>

More information about the Tagging mailing list