On Sun, Nov 25, 2018 at 12:40 AM Alan McConchie <[email protected]> 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 [email protected] https://lists.openstreetmap.org/listinfo/tagging
