[Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

Mateusz Konieczny matkoniecz at tutanota.com
Sun Nov 25 11:04:17 UTC 2018

I would not care too much about support in data consumers, checking what magic number meansduring development is not too problematic.
But it is horrible, horrible for mappers that edit tags directly. Maybe this can be hidden in iD,but magic number are obnoxious for all other mappers.

25. Nov 2018 02:22 by pla16021 at gmail.com <mailto:pla16021 at gmail.com>:

> On Sun, Nov 25, 2018 at 12:40 AM Alan McConchie <> alan.mcconchie at gmail.com <mailto: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20181125/16fdc9c9/attachment-0002.html>

More information about the Tagging mailing list