Hi Martin,
That was an interesting analysis. I enjoyed reading it, and found I pretty much
agree with your points. A few embedded comments below:
On 29. Nov 2018, at 10:40, Martin Koppenhoefer wrote:
........By the time, I thought it would be a good scheme because it
distinguished the hierarchy (level: national, regional etc.) and the protection
scope (natural, cultural, etc.), and had also a structured tag (pr.title) for
the actual class name —- and numeric values were still quite common in tagging
anyway (sac scale, tracktype, admin_level), although those numbers are actually
easier to understand because they express a hierarchy, unlike the protect
classes which are just codes.
>> +1, and I still think so, on the whole. If you look at the ICUN website
>> (referenced from the boundary=protected_area wiki page), there is an intent
>> to define a sort of a hierarchy of protection levels from wilderness down to
>> resource extraction (for p_classes 1 through 6). I agree it's rather
>> obscure, and doesn't come through at all clearly on the wiki page. Also the
>> wiki look-up tables (at least for the US) need work.
........ Compared to the 2 tags that already were established in 2009,
leisure=nature_reserve and boundary=national_park, it seemed more versatile and
universally applicable.
>> +1 This is the main reason for my interest in boundary=protected_area. We
>> need something. There's a lot of blatant misuse of those two old tags -
>> people use them just to get boundaries to render.
........I still believe it is desirable to have a scheme which offers ways to
precisely define the kind of protected area, just that numbered classes for the
scope were a bad idea. Especially because it is the essence of the thing to
know what is protected, not just a detail. A good scheme should allow for both:
adding rough information and refine it with details. At least for a basic
representation you should not have to resort to lookup tables or presets.
>> +1 (mostly). The boundary=protected_area scheme allows rough/detail tagging
>> to some degree, I think. I presume you can specify b=p_area without adding
>> p_class if you wish (though IMHO p_title ought to always be specified). I'm
>> not wild about numbers for p_class, but I don't know how else to succinctly
>> specify purpose and level-of-protection, which I do think is desirable and
>> is not always obvious from the title. Plus any change at this stage would be
>> difficult? (see numbers below)
.......I am also not sure any more whether we should put all kinds of protected
areas in the same bucket, maybe there could already be a first class
distinction between natural protection, resource protection and social
protection. e.g. “water_protection_area” rather than a handful of protected
tags with obscure protection classes.
>> +1 Problem is, there are already around 8000 uses in the "resource area",
>> and over 4000 in "social" (from counting the corresponding p_classes in
>> TagInfo), so introducing new top-level tags is going to affect a lot of
>> existing data. The boundary=aboriginal_lands proposal only replaces
>> p_class=24 (about 600 uses), but I bet we will now have two ways of mapping
>> the same thing for a long time.
..... On the other hand, I would not create first level classes to distinguish
between a national park and a regional park.
>> +1
>> My overall take: this is a well established tag set, with around 70k uses of
>> boundary=p_area, and around 50k uses of p_class and of p_title, so a lot of
>> people are actually finding it usable, and its going to be difficult to
>> change it substantially. IMO, I think we should focus on more user-friendly
>> documentation and possibly editor assistance.
One idea: split the p_class wiki documentation off from boundary=p_area into a
wiki page of its own. Even consider having separate p_class wiki pages for each
country, with smaller, better explained look-up tables.
Another idea: The presets in JOSM et al could have the mapper fill in the
p_title (or select it from a list) and do a software look up of the title in a
country specific table and display a suggested p_class. If the editor doesn't
find the title in its table the mapper would have to research the correct
p_class and enter it manually, but this might be quite unusual. However it
sounds like a lot of work for the JOSM and other editor teams.
But in any case, I'm optimistic....once we have rendering of the
boundary=protected_area set I think we'll find we're in pretty good shape.
[BTW, a bit off the topic, but we have a local website called calands.org which
shows all the protected areas in California (if you look, click on the "Explore
CPAD Map" button on the opening map). It illustrates a couple of points:
1) We're up to our ears in protected areas around here, and there are
probably (at a guess) over 50 different titles. Not sure if this is the same
in other states/countries. But hence my interest in mapping them.
2) The CPAD map groups these area titles by "Owner level" (ie, City,
County, Federal, Non Profit, Private, Special District, State). This is another
way of aggregating the huge collection of disparate titles. It has a different
purpose from IUCN or p_class codes, but it might make a useful additional
sub-tag for boundary=p_area.]
Cheers
- doug
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
