<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Martin,<br>
That was an interesting analysis. I enjoyed reading it, and found I pretty much agree with your points. A few embedded comments below:<br>
<br>
On 29. Nov 2018, at 10:40, Martin Koppenhoefer wrote:<br>
<blockquote>........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.<br>
>> +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.
<br>
<br>
........ 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.<br>
>> +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.<br>
<br>
........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.
<br>
>> +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)<br>
<br>
.......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. <br>
>> +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.<br>
<br>
..... On the other hand, I would not create first level classes to distinguish between a national park and a regional park.<br>
>> +1<br>
<br>
>> 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.
<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
[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:<br>
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.<br>
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.]<br>
<br>
Cheers<br>
- doug<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote>
</body>
</html>