Protect_class und der Versuch der schrittweisen Abschaffung…

Guten Abend,

Mit sehr großer Sorge beobachte ich diverse Proposals, die es anscheinend zum Ziel haben, protect_class=* abzuschaffen und häppchenweise durch halbgare Proposals zu ersetzen, deren Ergebnis für mich nur Chaos und Unordnung in einem bisher strukturierten Tagging produzieren.
Los ging es mit https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:boundary%3Daboriginal_lands im Proposal selbst wird geschrieben, daß es synonym zu protect_class=24 ist.
So, und anstelle an den Definitionen zu arbeiten wurde einfach eine neue Grenze kreiert und dann gleich rasenmäherartig erst mal alles umgetaggt. Ich vermute, beim /bei den Ersteller/n ist man sich der Tragweite des ausgeklügelten boundary=protected_area-Schemas nicht bewußt, sie versteht es nicht und kippt einfach was neues in die Welt. Sorry für meine harschen Worte…

Aufgefallen ist es mir, als die Grenze des sorbischen Siedlungsgebietes (https://www.openstreetmap.org/relation/6001479), ohne lokales Wissen zu boundary=aboriginal_lands umgetaggt wurde. Das würde hier aber nicht zutreffen…

Dank woodpeck wurde der Mechanische Edit revertet. https://www.openstreetmap.org/changeset/93602628
Es bedarf hier stets lokales Wissen und kann nicht in einem mechanischen Edit erledigt werden. Hätte ich damals Kenntnis von dem Proposal gehabt, hätte ich zu mindesten vehement interveniert.

Genauso ist es nun mit dem Proposal https://wiki.openstreetmap.org/wiki/Proposed_features/Special_economic_zone
Auch hier ist das Proposal in meinen Augen völlig unnötig, da das bereits mit etabliertem Tagging (lange dokumentiertes protect_class=23) vollständig abgedeckt werden kann. Ich habe das Proposal abgelehnt.

Die allergrößte Gefahr sehe ich im Proposal https://wiki.openstreetmap.org/wiki/Proposal:_Named_protection_class_for_protected_areas
Ein protection_class=habitat würde mindestens protect_class=4|7|14|97|98 ersetzen. Für mich ist das ganze Proposal nicht hinnehmbar und kann ohne weiteres mindestens für Europa nicht angewendet werden, ohne sich dann in der Folge erneut grundlegendes Tagging zu überlegen.
Das hätte zu Folge, daß das hier in Deutschland/Europa angewendete feingliedrige Schutzgebietstagging kaputtgemacht wird. In meinen Augen kann protection_class in Europa nicht angewendet werden. Die Unterscheidung von Schutzgebietsflächen würde mindestens auf die dritte, wenn nicht gar auf die vierte Auswerteebene verschoben. Ich kann aber die Folgen nicht abschätzen.

In dem Zusammenhang sehe ich auch die Auskommentierung/ Löschung diverser protect_class-Werte im Wiki (egal ob DE oder EN) äußerst kritisch(mindestens protect_class=11 und 13). Die Änderung im EN-Wiki stehen für mich im Zusammenhang mit diesem Versuch der schleichenden Abschaffung. Die Änderung muß im meinen Augen zwingend revertet werden.

Mit Hinblick auf Änderungen im EN-Wiki: da sind wir wieder bei blinden, nicht abgesprochenen Wiki-Edits, um eine Einzelmeinung durchzusetzen…

Sven

I apologize for the post in English, as I do not speak German and am reading this forum via translator.

I have asked multiple times, and have yet to get a clear answer, as to why you prefer a numbering system and a lookup table. protect_class= does not have a clear meaning and does not follow the standard OSM convention of using plain language for describing tags.

When proposed, these ideas are formally discussed on the tagging list and elsewhere. In the case of special_economic_zone, the RFC was posted twice to the tagging list, and was listed in the weeklyOSM while it was in RFC. If you wish to advocate for a numbering scheme, I welcome your participation in the tagging mailing.

There is a growing consensus that words are a better way to describe objects than numbers.

We wish very strongly to work with the international community on adopting and documenting the best ways to tag these areas, and I invite you to participate in a constructive way. This is not a one-person effort on my part, there are many of us involved in the work to create better tagging for protected areas. The named protection classes proposal is still in the draft phase. We would very much like to understand the types of tagging and classifications that German (and other international) mappers require so that we can propose tagging that is both plain language and meets the needs that you have for the complexity of your land categorization.

DE: Euer Proposal https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:boundary%3Daboriginal_lands ist das selbe wie protect_class=24! warum eine neue Grenze? Das ist Quatsch. Das Tagging mit protect_class=24 hätte nur entsprechend angepasst werden müssen.
Das selbe ist mit protect_class=23 vs boundary=special_economic_zone.

Ich glaube, ihr habt euch nicht die Definitionen der protect_class -Werte im Detail angeschaut. Ihr habt nicht beachtet, welche Möglichkeiten darüberhinaus bietet!

EN:Your proposal https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:boundary%3Daboriginal_lands is the same as protect_class=24! why a new border? This is nonsense. Tagging with protect_class=24 should only have been adjusted accordingly.
The same is with protect_class=23 vs boundary=special_economic_zone.

I don’t think you looked at the definitions of protect_class values in detail. You haven’t noticed what the possibilities are!

DE: Ich hab das schon in der Disskussion des Proposal geschrieben. Wenn man das Tagging von Nummern in Wörter ändern will, muß zwingend die bisherige Unterscheidung beibehalten werden. Dann fällt mir aber auch kein Grund ein, daß überhaupt ändern zu wollen. Für mich ist protect_class derzeit nicht ersetzbar. Nur Definitionen und Taggingbeispiele können und müssen verbessert werden. Diese Definitionen und Taggingbeispiele sind ohnehin von Land zu Land sehr verschieden und lassen sich schwer international vereinheitlichen. Das Protect_class-Schema hat es recht gut geschafft. Das kann man auch nicht an einzelnen protect_class-Werten erklären. Es geht um das Gesamtsystem.

EN: I have already written this in the discussion of the proposal. If you want to change the tagging of numbers to words, it is imperative to keep the previous distinction. But then I can’t think of any reason to want to change that at all. For me, protect_class is currently unreplaceable. Only definitions and tagging examples can and must be improved. This cannot be explained by individual protect_class values. These definitions and tagging examples are very different from country to country anyway and are difficult to unify internationally. The Protect_class scheme has done quite well. It is about the whole system.

Sven

@ZeLonewolf: I do understand your wish to get rid of numbers and replace that with self-explaining words.
This is similar to hw=track & tracktype=grade1 … grade5 which is also a numbering scheme (neglecting the non-distinguishing grade).
Why has that not been changed?
First - you would have to change a terrific amount of lines. That does not apply to protected areas.
But second - you would have to find key words that uniquely define what is meant with the grades. They are explained with several sentences and at least one image. Not perfectly but understandable all over the world.

You may introduce a word like aboriginal_lands for protect_class 24, but this is very misleading in many countries. Introducing more values for the same class makes things not easier.

Another bad example is road classification: There you have e.g. a hw=*trunk *which means totally different things in Germany and Nepal. The only thing that prevents a German from extremely bad experience is the knowledge that trunk has nothing to do with what he expects from that word and is only a local classification. A local_class=2 would do as well without the danger of misinterpretation. But don’t be afraid - I do not want to plead for the removal of the tag trunk.

Finally: Even if you find it better and get broad support to replace numbers with words, you should not automatically replace that wordwide. You definitely run into misinterpretations (as was to be proven).

Thank you for the English translations and for tolerating the language difference!

I had nothing to do with boundary=aboriginal_lands, as it was not my proposal. That tag was voted on and accepted by the community two years ago with a vote of 45-7. Most of the votes against the proposal did so either because they felt that that “aboriginal” wasn’t the correct word or because they felt it should be part of boundary=administrative instead. There is very little support for a protect_class numbering, particularly the values that do not render.

That is incorrect. I have studied this topic in great detail and sought input and consensus from various members of the community. I’ve been working over time to improve the documentation of boundary=protected_area and protect_class=* so that it reflects how tagging is actually being used. In order to propose a better scheme, it is important to have clear documentation. It has been several month of effort to slowly understand and clean up that documentation and draft and circulate proposals for improvement. Until you have gone through the proposal process, it is hard to appreciate how much work goes into a proposal.

I agree!

As the documentation of protect_class improves, we will understand better how these numbers are being applied, and I ask you for help in understanding exactly what those distinctions are. It seems that you have a need to make a distinction between:

  • Protected areas by inter-continental agreement (such as Ramsar, World Heritage Convention, World Network of Biosphere Reserves)
  • Protected areas by continental agreement (such as Natura 2000, Bird Protection Directive of the EU, and Flora Fauna Habitats Directive of the EU)
  • Protected areas by national, state, or local agreement

So first I ask…how do you tag these distinctions today? Do you put “Natura 2000” in protection_title= or related_law= or what?

Is it true that the distinctions between these categories (class 7,97,98) are just which agreement applies?

How do you tag something if it is covered by one of these agreements AND meets one of the IUCN definitions?

For example:

Obere Havelniederung (SiteCode: DE3145421) is a Birds Directive Sites (SPA).

It is covered by Natura2000: https://natura2000.eea.europa.eu/?query=Natura2000Sites_9883_1,SITECODE,DE3145421
It is also an IUCN Category V land: https://www.protectedplanet.net/323340

Under the current scheme, it is ambiguous; should it be protect_class=5 because it is IUCN category V? Or should it be protect_class=97 because it is a Natura2000 area? Most areas that are part of Natura2000 will also have an IUCN category. It is ambiguous, and this is just one example of where the protect_class scheme fails.

Perhaps tagging for this land might be:

boundary=protected_area
protection_title=Vogelschutzrichtlinie
name=Obere Havelniederung
iucn_level=V
related_law=Natura2000
leisure=nature_reserve

What other information is needed to describe that area?

Great example!

First off, the grades 1-5 represent a sequence where smaller numbers mean nicer roads, and bigger numbers mean rougher roads. The numbers here actually mean something, whereas protect_class values are merely lookups. protect_class=4 isn’t “more protected than 3 but less protected than 5” while tracktype=grade4 IS a nicer road than tracktype=grade5 but not as nice a tracktype=grade3.

Secondly, tracktype has achieved 7 million usages. If we were inventing the tagging for tracktype today, we would perhaps come up with words rather than numbers. However, 7 million usages means that the tagging is widely accepted by the community and should not be changed.

However, this is not the case with protect_class. There are 64,000 total usages, however, of that, 48,000 are the “rendering” values of protect_class, namely 1a, 1b, and 1-6. Of the remaining 15,000, half of those were from a single import in Poland that chose to apply the tag protect_class=19.

Now, let’s put aside the renderable values of protect_class (the 1a, 1b, and 1-6) which are in fairly wide usage. Perhaps that is too entrenched to change, perhaps not, but in any case the categorization is mostly fine because they link to IUCN categories AND they fit the actual definition of a protected area (https://en.wikipedia.org/wiki/Protected_area) - which economic zones and indigenous lands do not!

Let’s also put aside the Poland import.

What we are really talking about here is somewhere around 7,000 usages scattered across 13 values. By the numbers, when looking at each individual category, this is not a large number, and these values do not render anyways in any renderer that I’m aware of. So while I do support replacing protect_class numbers with names, I am focusing my efforts on those edge cases which are an especially poor fit within the current scheme.

What we want is a well-documented collection of tagging that is accepted by the community, used widely, and is clearly and specifically defined. That is what I am hoping to achieve through this effort.

I also hope to achieve rendering support for all of boundary=protected_area. Right now, 7, 97, 98, and 99 do not render because they’re poorly defined and not well-accepted. So by peeling off what doesn’t belong and clearly documenting what’s there now, we hope to make that entire key a rendering one without having to add other tagging such as leisure=nature_reserve or natural=wood or landuse=recreation_ground!

Yes, that is the goal of the named protection classes proposal (which is also, not my proposal), with input from the international community.

I also am not a fan of the fact that trunk/primary/secondary mean different things in different countries. Those values are more intended for renderers to show the most important versus less important roads in a graduated color scheme. In that sense, they ARE the same in different countries - it is tagging how important the road is when compared to other roads. Roads tagged highway=motorway are the most important roads in that country, regardless of what “most important” looks like!

Remember that there is other tagging that describes the number of lanes, speed limit, surface, etc., all of which would supply a German tourist in Nepal with the information they need when traveling on those roads - do not mix these up!

Yes, I acknowledge this.

First of all it is a “Landschaftsschutzgebiet”
https://bravors.brandenburg.de/de/verordnungen-212840
Tagging in Germany is:

boundary=protected_area
protect_class=5
protection_title=Landschaftsschutzgebiet

NOT
leisure=nature_reserve for this Area

Ich halte es für keine gute Lösung, in diesem Zusammenhang Zahlen durch Namen (named protection classes) zu ersetzen. Die abstrakten Zahlen zwingen einen, sich genauer damit zu beschäftigen, welchen tatsächlichen Schutzstatus ein Schutzgebiet tatsächlich hat. Bei den Bezeichnungen “Vogelschutzgebiet”, “Naturschutzgebiet”, “Naturpark”, “Nationalpark”, “FFH-Schutzgebiet” ist die Gefahr groß, dass einfach der Begriff gewählt wird, der einem richtig erscheint, ohne tatsächlich sich damit auseinanderzusetzen, ob er zutreffend ist. Ich bin mir sicher, dass sehr viele bei OSM aktive Leute z.B. nicht den Unterschied zwischen einem Naturschutzgebiet und einem FFH-Schutzgebiet kennen und dann fälschlich alles als Naturschutzgebiete in die OSM-Datenbank eintragen würden.
Daher: Die Zahlenbasiernden Protextion-Classes sind zwar abstrakt und sperrig, sie sorgen aber auch, dass nicht alle Arten von Schutzgebieten allgemein nur noch als Naturschutzgebiet eingetragen werden.
Das es teilweise Schutzgebiete gibt, die sowohl Naturschutzgebiet, FFH-Schutzgebiet und vielleicht auch noch Vogelschutzgebiet sind, lässt sich auch nicht durch namensbasierte Schutzklassen lösen.

I consider myself impartial in this dispute because I do not indulge in any protect_class tagging. Only a very basic remark: Well established and widely used tagging procedures cannot be changed in a project that involves hundreds of thousands mappers. Of course, you can change all existing protect_class numbers with a mechanical edit but there are thousands of mappers who still will use the established protect_class numbering scheme.

I understand your intention to make the protect_class scheme more understandable but you are more than ten years too late with your proposal. At a certain point in any crowd project it is impossible to change any well etablished procedure. Just look at landuse=farm. The differentiation in landuse=farmland and landuse=farmyard has still not reached all first generation mappers. They don’t look in any forums, mailing list or wikis.

so ist es, und das Ding
https://wiki.openstreetmap.org/wiki/Proposal:_Named_protection_class_for_protected_areas
ist meiner Meinung nach großer Mist.

Einige US-Amerikaner haben wohl festgestellt, dass die protect_class bei ihnen nicht immer stimmig ist und wollen deswegen das ganze weltweite Schema durch “was anderes” ersetzen, ich hatte mich schon auf der Disk-Seite (EN) kritisch geäußert, und hoffe inständig, dass diese krude Idee einschläft.

Dass es beim komplexen Thema Schutzgebiete des Natur- und Landschaftsschutzes Probleme gibt war mir vor Jahren auch schon in D aufgefallen, das lag und liegt aber weder am protected_area-Schema (das ist gut und mächtig) noch an den Mappern, sondern primär an der Dokumentation, die klar und bei diesem Thema auch immer zu einem hohen Grad landesspezifisch bzw. rechstraumspezifisch sein muss.
Für Deutschland sind wir innerhalb der DE-Wikiseiten da halbwegs gut aufgestellt, daher nutze ich diese Disk für eine

Werbeeinblendung
Bei Erfassen von Schutzgebieten des Natur- und Landschaftsschutzes in D immer an diese Dokumentation der 3 Tags zum Schema halten
https://wiki.openstreetmap.org/wiki/DE:Tag:boundary%3Dprotected_area
https://wiki.openstreetmap.org/wiki/DE:Key:protect_class
https://wiki.openstreetmap.org/wiki/DE:Key:protection_title
und wenn dort etwas fehlt oder unverständlich ist, hier im Forum kritisch nachfragen, (nur) dann kann verbessert werden (bin und bleibe am Thema in D dran) …

The answer here is very easy: The legal background of the Natura 2000 site and the landscape protection area are very different and so we need two separate relations for both sites. This is also needed for linking to Wikidata. If you had a look at the links you might also noticed that size and geometry of both sites are very different, this would be the main reason for not combining them in one relation.