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 pla16...@gmail.com <mailto:pla16...@gmail.com>:
> On Sun, Nov 25, 2018 at 12:40 AM Alan McConchie <> alan.mcconc...@gmail.com
> <mailto:alan.mcconc...@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.
>
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
