While admin_level is numeric, they numbers are already widely known, so it would be fine to reuse the tag admin_level=4 to specify the administrative level of a certain protected area, I think, especially if the operator=* is not the same.
> 'strict_nature_reserve', 'wilderness_area', 'national_park' (already used), 'natural_monument', 'habitat', 'protected_landscape', 'sustainable_resource_use_area Great idea. I can actually remember those. Perhaps we can create specific wiki pages for each of the protect_class=1 to 6 and add those definitions, to help out taginfo and editors like iD and JOSM. I would also probably vote for a proposal that added new tags like *=wilderness_area, *=natural_monument, and deprecated protect_class. There will need to be synonyms for 11 to 19 as well, since these are used in some countries according to the table, as well as for at least a few of the Social/Cultural ones. Are you feeling up to writing a big proposal, Kevin? It may be a lot a work and probably requires consulting with other communities (like German at least), but I think you have the persistence to get it done. Joseph On 7/29/19, Paul Allen <[email protected]> wrote: > On Sun, 28 Jul 2019 at 15:36, Martin Koppenhoefer <[email protected]> > wrote: > > we do have an established numbered scheme for admin_levels, it could be >> reused to tag the administrative level that instituted the protected >> area, >> for a state park it would have the value 4, the key could remain >> “admin_level” also in the context of boundary=protected_area >> > > I'm not entirely happy with admin_level. It's numbers, so you have to read > the wiki to figure out > what admin_level=4 is. I view it as a historical accident that we should > avoid repeating, not a > template for good taq design. > > The kind of protection could be readable words, like nature, or birds, or >> culture, or water, air etc. >> > > A lot better than numbers. Still has problems, such as some objects will > need to have a list > of values because it serves multiple purposes, but better than > randomly-assigned numbers. > > -- > Paul > _______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
