Boundary=protected_area als tags an ways einer relation

Communities Deutschland (Germany)
1

Hallo zusammen!

Ich habe an vielen Naturschutzgebiet-Relationen in Brandenburg bemerkt, dass die ways in der relation oftmals boudary=protected_area haben.

Laut OSM-Wiki ist dies nicht gewollt. DE:Tag:boundary=protected_area
“Bei einer Relation type=boundary sind alle Daten des Schutzgebietes der Relation zugeordnet. Die einzelnen Ways (geschlossene wie offene) sollen, sofern sie keine Tags aus anderen Relationen besitzen, nur erläuternde note=* oder description=* -Tags erhalten …”

Viele dieser relationen haben keine konsistente Verwendung des tags boudary=protected_area. Manchmal ist der auf keinem der ways drauf, manchmal auf ein paar, manchmal auf allen. Auf manchen ways ist noch zusätzlich ein protect_class=irgendwas gesetzt.

Nun wurde ich darauf hingewiesen, dass ich das nicht so einfach entfernen soll. Begründung: 1. vielleicht hat der Renderer damit Probleme und 2. es wäre einfacher zu bearbeiten.

Aus meiner Sicht spricht gegen Punkt 1 die generelle Regel, dass nicht für den Renderer zu taggen ist. Gegen Punkt 2 spricht, dass es eigentlich umständlicher zu bearbeiten ist, wenn nicht nur die Relation die Eigenschaft eines Gebiets hat, sondern die Wege auch noch.

Wie seht ihr das, darf ich die boudary=protected_area tags von ways einer boudary=protected_area relation entfernen oder muss ich dafür nachfragen?

Achja, das habe ich alles von Hand gemacht, jede Relation und jeden Way einzeln angeschaut und dann die ways bereinigt.

Ein Beispiel: Relation: ‪Melzower Forst‬ (‪2758162‬) | OpenStreetMap
4 ways:

  • Die ways 1316021318 und 205401636 hatten die tags (hab ich bereits entfernt): boundary=protected_area und protect_class=98. Sie gehören zu 3 Relationen 2758162, 18052633 und 215277 Diese haben protection_class=98, =5 und =4 Warum hat der way dann protection_class=98, den niedrigsten Wert?
  • Der way 205401634 hat die tags: boundary=protected_area und protect_class=4. Er gehört nur zur Relation 2758162, da stimmt die protection_class des ways mit der relation überein. Aber: Die tags boundary=protected_area und protect_class=4 gehören laut Wiki nicht auf den way.
  • Der way 785898722 gehört zu den 3 Relationen 2758162, 18052633 und 215277, genau wie die ersten beiden ways, hat aber keinerlei tags (wie es sein sollte).

Noch ein Beispiel: Relation: ‪Naturpark Hoher Fläming‬ (‪1149729‬) | OpenStreetMap
43 ways
Keiner der ways hat die tags boundary=protected_area und protect_class=irgendwas. Anscheinend ist das aber bei diesem Naturpark ok.

Edit: Link korrigiert

2

@MadestCat Du kannst ruhig dazu schreiben, daß du das rasenmäherartig bereits machst und du für mich damit gegen Automated Edits code of conduct - OpenStreetMap Wiki verstoßen hast…

Weiterer Fehler: du setzt die Rechtsform eines Schutzgebietes mit in den Namen:

Die Rechtsform eines Schutzgebietes ist in der Regel nicht Namensbestandteil:

z.B. Schlaubetal: Bekanntmachung des Ministeriums für Umwelt, Naturschutz und Raumordnung über die Erklärung zum Naturpark „Schlaubetal“

Das Setzen der Rechtsform in den name-Tag ist für mich Mappen für den Renderer!

Sven

3

Sehe ich nicht so, da er einen offensichtlichen Fehler behoben und sich jeden Way einzeln angeschaut hat.

4

Immer wenn es darum geht, wenn jemand ungefragt und unangekündigt rasenmäherartig in Größenordnungen Dinge ändert, wurde zunächst dieser Verstoß festgestellt.
Ich hätte kein Problem damit, wenn das VORHER diskutiert worden wäre!

Den weiteren Fehler habe bereit auch genannt, soviel zum “vorher angeschaut”… :frowning:

knatschige Grüße…

5

Ich denke ich habe deutlich gemacht, dass ich gerade nicht per Rasenmäher drüber gegangen bin. Alle Änderungen wurden per iD durchgeführt, von Hand.

Ja, ich habe manchmal den Namen des NSG in den Titel übernommen, hauptsächlich dann, wenn es mehre Gebiete mit gleichem Namen aber unterschiedlicher Funktion gibt. Vielleicht habe ich es da übertrieben (aktuell sind das rund 50 Relationen, die ich wieder zurück benennen müsste, aber das kann ich gerne machen).

Wobei auch das nicht komplett konsistent ist. Es gibt in Deutschland 92 Relationen mit dem Namensteil “Naturschutzgebiet”, wobei wie bereits erwähnt 52 davon auf Brandenburg entfallen (mein Fehler).

Erstaunlicherweise haben im Gegensatz dazu die Nationalparks den Namenszusatz “Nationalpark” immer im Namen drin. Wenn jetzt der Renderer den protection_title immer mit anzeigt (von mir aus gerne), dann steht bei Naturschutzgebieten “Naturschutzgebiet irgendwas” und bei Nationalparken “Nationalpark Nationalpark irgendwas”. Also auf eines sollte man sich einigen … aber wir kommen vom Thema ab, das ist eine separate Diskussion wert, falls die nicht schon statt gefunden hat.

Hier geht es mir um die Entfernung von boundary=protected_area und protect_class=* von ways einer relation die bereits boundary=protected_area und protect_class=* hat.

(sowie um die falsche Eintragung von “Naturschutzgebiet” in den Namen)

6

Inhaltlich kann ich glaub wenig beitragen, abgesehen davon, dass ich plausibel finde, was du schreibst. Aber: Du hast an mehreren Stellen boudary statt boundary geschrieben, unter anderem auch im Titel. Ist wahrscheinlich nicht wild, weil du es ja entfernen willst und nicht hinzufügen, aber da solltest du auf alle Fälle aufpassen, dass das nicht falsch in den Daten ankommt.

7

Trotzdem: Vorher auf das Problem hinweisen! Nicht erst dann, wenn das Kind in den Brunnen gefallen ist!

Hier für Brandenburg: in den offiziellen Daten (die nutzbar sind, meine Meinung ist noch immer so; vgl. [Nutzbar] Geodaten des LfU und Landesbetrieb Forst Brandenburg - #10 by streckenkundler)

steht bei keinem NSG, LSG die Rechtsform im Namen, auch bei FFH-Gebieten nicht. Bei Naturparken, Biosphärenreservaten und unserem Nationalpark steht das zwar drin, aber bereits überwiegend mit dem Namen in Anführungszeichen. …und wie ich oben anhand des Schlaubetals gezeigt habe, sollte auch hier in den offiziellen Daten nur der Name, ohne Rechtsform stehen. Ich meine, daß hatten wir vor Jahren schon mal durchgeknautscht… ich Winke mal zu @Jo_Cassel Da findet sich einiges in den Analen des Forums, z.B.:

…und das boundary=protected_area an Ways von Relationsmitgliedern kann sukkzessive entfernt werden, wenn man ob ergänzender Daten oder Lagekorrekturen das Gebiet mal anfässt…

Edit: ich hab dem Beitragstitel mal ein kleines n spendiert.

8

Komplett einverstanden, dass “name” ohne “Naturschutzgebiet” getagged wird. Kein Problem, ich ändere das entsprechend bei meinen Edits … vorsichtig, selbstverständlich und nicht automatisiert.

Selbstverständlich habe ich mir auch die Relationen jedes mal angeschaut und geprüft, ob dort noch alles Sinn macht (zB ob type=boundary und boundary=protected_area jedes Mal gesetzt ist und ob protect_class zum protection_title passt) und zum Beispiel Wikidata Einträge hinzugefügt.

boundary/boudary ist nur hier ein Schreibfehler, tut mir Leid.

Edit: Ganz vergessen, wollte noch vorher was zum vorher Fragen schreiben:
Woher soll ich wissen, dass ich Fehler in Daten nicht einfach so entfernen darf, wenn die Relationen korrekt sind und danach alles in Ordnung ist? Ich habe ja nicht wirklich Daten entfernt oder etwas geändert (ok, außer die Namen, ich hab’s verstanden). Gibt es dafür eine grundsätzliche Regelung?

9

Ich bearbeite viele NSGs, LSGs und andere Schutzgebiete in RLP/NRW und verzichte stets darauf, den Wegen einer Relation boundary-tags zu geben. Ich sehe dies aber auch nicht als Fehler an. In jedem Fall würde ich mir nicht die Arbeit machen, dies großflächig zu bereinigen. Auch bei boundary=administrative ist die Vergabe des admin_levels lediglich optional, wird aber doch zumindest in Deutschland in Regel gemappt.

Ein weiterer, sehr häufiger “Fehler”, der sicherlich hunderte Schutzgebiete betrifft, ist die Verwendung von type=multipolygon anstatt type=boundary. Auch das korrigiere ich, wenn ich darauf stoße, suche aber nicht gezielt danach.

Definitiv würde ich stets auf das Kürzel NSG verzichten, auch wenn es Namensbestandteil ist. Dies ist klar im Wiki dokumentiert. NSG wird als short_protection_title erfasst und wer mag, kann den vollen Titel unter official_name setzen.

10

Was ich z.B. nicht einschätzen kann… ein Liniensegment ist z.B. Teil eines Schutzgebietes einerseits und andererseits auch Teil einer Admin-Grenze, dieses Liniensegment selbst ist aber Tag-los… gibt es da dann Probleme? Ich weiß es nicht, ich bin Mapper in meiner Freizeit, kein Rendering-Entwickler! Bei Admin-Grenzen gibt es ja auch Bestrebungen, die Tags von den Linien zu nehmen… So richtig glücklich bin ich damit nicht…

Bei meinem Bearbeitungen hier in Brandenburg habe ich diese kleinwenige Redundanz bei meinen Grenzbearbeitungen sehr zu schätzen gewusst. Bei einer Ersterfassung eines Schutzgebietes brauche ich eh boundary=protected_area (oder vergleichbar) am Way, da ich nur so entsprechend datengefiltert, die Grenzen erfassen kann, ohne versehentlich diese mit anderen Objekten zu verkleben, wo sie nicht verklebt gehört… aber auch hier…es kommt auf die Situation der Grenzbeschreibung drauf an, es gibt Ausnahmen…

Was ich z.B. beim Standard-Rendering von Carto beobachtet habe, ist, daß leisure=nature_reserve (nach Wiki anzuwenden für NSG’s) zu mindestens hier obsolet zu sein scheint. Hier verzichte ich zunehmend darauf, egal ob geschlossener Way oder Relation. Rendering klappt trotzdem.

Sven

11

Definitiv würde ich stets auf das Kürzel NSG verzichten, auch wenn es Namensbestandteil ist. Dies ist klar im Wiki dokumentiert. NSG wird als short_protection_title erfasst und wer mag, kann den vollen Titel unter official_name setzen.

ich finde schon dass man den vollen Titel irgendwo taggen sollte, “name” muss es nicht unbedingt sein, aber einfach nur rauslöschen hielte ich auch nicht für perfekt, einen dieser beiden tags sollte man dann mindestens nutzen um die Informationen zu verschieben.

12

Die primäre Frage: Was ist der volle Titel???

Ein weiteres Problem ist, beim Thema Schutzgebiete müsste man alle offiziellen Quellen begutachten. Ich dampfe das nun mal bewusst auf die NSG’s ein…, Finde die Original-Quellen zu NSG’s die z.B. in den 1960er Jahren in der DDR ausgewiesen wurden oder in den 1930er Jahren… Ich stecke in dem Thema berufsbedingt recht leidlich drin…

Wenn ich hier in Brandenburg schaue… eines der ältesten bestehenden NSG’s dürfte der Groß-Machnower Weinberg sein: Ausweisung als NSG: (laut hiesigem LfU) 13.06.1936 durch “Amtsblatt der Preußischen Regierung in Potsdam Nr. 27 vom 13.06.1936” In OSM: Way: ‪Groß-Machnower Weinberg‬ (‪37384936‬) | OpenStreetMap

Ich weiß nicht was zum kompletten Titel dieses Gebietes in diesem Amtsblatt steht… Was ich vorfinde sind die heutig zu sehenden Angaben…

An der Stelle sage ich es mal wieder mal… OSM ist eine Datenbank! Meine ersten Schritte, als ich vor über 30 Jahren mit Datenbanken angefangen habe (damals das seelige FoxPro) war: Normalisierung (!!) der Daten! (*) Stichwort relationale Datenbanken, nicht anderes ist OSM heute noch immer. Also Daten so aufbereiten, daß sie strukturiert abegefragt werden können. Diese Thematik hier gehört für mich dazu…

Sven

(*) meine Lehr-Literatur: https://www.hugendubel.de/de/buch_kartoniert/alfred_moos_gerhard_daues-sql_datenbanken-17699364-produkt-details.html …in meinem Regal noch immer einen Ehrenplatz habend…

13

Kurz zum Namen

Der Begriff “Naturschutzgebiet” wird mittels “protection_title=Naturschutzgebiet” getagged, also eigentlich gar kein Problem für den Renderer aus dieser Information und dem “name=Döberitzer Heide” auf der Karte ein “Naturschutzgebiet Döberitzer Heide” anzuzeigen. Daher bin ich voll bei Streckenkundler, das eben nicht in den Namen zu packen.

Zu dem ursprünglichen Problem mit den Grenzen

@streckenkundler Bei deinem vorletzten Beitrag überlegst du schon wieder, wie du besser für den Renderer taggen könntest, obwohl du später schreibst, dass Datenbanken sauber sein müssen und konsistent. Genau dieses Problem wird zu den Grenzen in der Wiki angesprochen: “Avoid using the tag on closed ways, or repeating it on boundary relation members, as this can lead to ambiguities and cause unexpected behavior in data consumers.”

Ich verstehe, dass boundary=protected_area während des Erstellens der Naturschutzgebiete hilfreich ist. Aber wenn sie einmal erstellt sind, sollte die ways bereinigen, zum besseren der Datenbank.

Die Zahlen die ich jetzt nenne sind geschätzt …
Von allen Relationen mit type=boundary (was ich auch jedes mal geprüft habe), sind die ways der relation bei etwa

  • 10% komplett richtig, haben überhaupt keine tags, hatten sie auch nie, genau wie es sein soll,
  • 10% komplett mit boundary=protected_area und protect_class getagged. Dies betrifft wirklich wenige Gebiete, da diese zum einen groß genug sein müssen, um eine Relation zu sein und gleichzeitig komplett ohne Kontakt zu anderen Relationen.
  • den restlichen 80% eine Mischung aus ways mit oder ohne boundary=protected_area und wenn dieser tag drauf ist, dann mit oder ohne protect_class mit verschiedensten Werten.

Noch was zum Rendern: Das einzige Problem was ich sehe sind Naturschutzgebiet- Relationen, die Administrative Grenzen enthalten. Bei denen sind die Grenzen eine Mischung aus grünen und blauen Linien.
Wenn wir dagegen die Grenzen per boundary=protected_area auf Grün zwingen, werden halt die Administrativen Relationen mit einer Mischund aus blau und grün dargestellt.
Am besten wäre hier eine Schraffierung der Grenze, also grün/blau schraffiert, wenn die Grenze gleichzeitig zu einer Administrativen und einer Naturschutz-Relation gehört.

@limes11
Ich habe mir halt den Aufwand gemacht, hab anscheinend nichts besseres zu tun :sweat_smile: Ich habe das bemerkt, es hat mich dann gestört, wobei ich vorher nicht bemerkt habe, wie viele Änderungen das sind und dass das so weite Kreise zieht.

Abschließend

Wenn jetzt nicht doch noch ein gutes Argument kommt, die Fehler in den ways der Relation zu lassen, würde ich die letzten 11(!) ways auch noch anpassen.

14

Nun, Schutzgebietsgrenzen allgemein sind eben manchmal so definiert… Da hat man dann zwei Möglichkeiten:

  1. verkleben der Grenzsegmente
  2. direkte Nutzung der Geometrie

Ich hatte schon beide Varianten im Einsatz… Ich habe für mich erkannt, daß Variante 2 letztendlich wartungsärmer ist, vor allem wenn am Pflege von Grenzen macht und diese per Geometrie ersetzen austauscht. Bei Veklebungen müsste man alle Verklebungen wieder nachpflegen → noch größerer und unnötiger Aufwand.

Grundsätzliches noch zu Grenzen… Hier hat sich mir auch gezeigt, ggf. in älteren Karten nachzusehen…
Was übrigens auch zu beachten ist: (zu mindestens hier für Brandenburg weiß ich es) Die hier verwendbaren Grenzen haben lediglich eine Genauigkeit für die DTK 1:10.000 und sind nicht rechtsverbindlich. Rechtsverbindliche Grenzen gibt es nur im Schutzgebietskataster. Folge: Da uns diese Genauigkeit aber egal ist ergibt sich defakto eine Art “OSM-Variante” der Grenze des Schutzgebietes…Meine Erfahrungen bei meinen Grenzerfassungen hier in Brandenburg sind: Jede Grenze hat so seine Eigenheiten, die einem manchmal erst auf dem zweiten Blick erscheinen…

Frage: wie lange war der vorherige Zustand? Es war ewig lange so und es hat keinen gestört, es waren keine Probleme bekannt… Ich sehe es nicht ein, daß jetzt plötzlich alles über den Zaun gebrochen werden muß!

Ich fasse hier eh irgendwann mal wieder die Schutzgebiete (1) an und auch die Admin-Grenzen (2)… da gibt es noch jede Menge Arbeit… Da kann man das dann ggf. mitmachen, wenn man was anfasst…

  • (1) noch fehlende Grenzen, bzw. weitere Lagekorrekturen
  • (2) vor allem Lagekorrekturen

Das sollten aber nur äußerst versierte Mapper und ausschließlich mit JOSM machen…

Siehst du, darum erst fragen, disskutieren…

15

Ein paar Anmerkungen:
Die OSM_Daten werden natürlich durch ein Datenbankmanagementsystem (DBMS) verwaltet, das Datenmodell wurde und wird aber weitgehend unkontrolliert durch die freiwilligen Mitarbeiter erweitert. Das ist die unvermeidliche Folge des kollaborativen Ansatzes von OSM. Von einer normalisierten relationalen Datenbank im engeren Sinn d.h. ohne Redundanzen kann da keine Rede sein.
Redundanzen haben natürlich den Nachteil, dass man bei Änderungen immer alle Vorkommen im Auge behalten muss, sie erleichtern aber in bestimmten Szenarien die Auswertung erheblich.

Bei den Umrisslinien von Schutzgebietsgrenzen sollte man zunächst anstreben, geschlossenene Polygone zu erhalten. Dann hat man die ganzen Probleme ob mit Tags am way und in der Relation nicht, da es nur den way gibt.
Wenn Multipolygone vom type=boundary nicht zu vermeiden sind, gehören gemeinsame Tags (idR alle) in die Relation. Für redundante Tags an den ways sehe ich keinen zwingenden Grund - Nicht-Verkleben beim Neueintragen z.B. erreiche ich in JOSM durch Strg-Click, da brauche ich keine Filterung per Tag.

Bei den admin-Grenzen ist die Lage eine ganz andere. Da liegen (bis auf die Seegrenzen) immer mindestens zwei bis zu im Extrem einem Dutzend Grenzen übereinander und die Grenzsegmente sind Mitglied in entsprechend vielen Relationen. Da hat es sich als praktikabel erwiesen, das boundary=administrative und den höchstwertigen admin_level redundant an die Grenzsegmente zu hängen. Zumindest ist das internationale und im Wiki dokumentierte Praxis.

Wenn abschnittsweise Schutzgebiets- und admin-Grenzen zusammenfallen, würde ich trotzdem zwei Linienzüge übereinander legen. Das geht ja mit “Folgen”-Werkzeug im Editor sehr schnell.
Von Wiederverwenden von Grenzabschnitten auch anderer Flächen (natural, landuse usw.) halte ich generell nichts, da das Relationen erzwingt und spätere Änderungen zum Graus werden.

1 Like
16

für Brandenburg dürften alle relevanten Dinge bereinigt sein: NSG, LSG, Naturparke, BR
Schorfheide-Chorin… eine handvoll ausgewiesener Totalreservate… Den Rest bitte ich hiermit andere darum…

…was leisure=nature_reserve anbelagt…

…so habe ich bei meinen jüngeren NSG-Erfassungen der letzten Jahre das nie mehr erfasst…

Da leisure=nature_reserve ja ausschließlich auf Naturschutzgebiete abzielen soll… mit protect_class=4 hat man zum einen die selbe Aussage und zum anderen passt das besser in die allgemeine Erfassung von Schutzgebietsgrenzen.

Ich bin sogar soweit zu sagen, als daß auch leisure=nature_reserve mittlerweile nur noch mappen für den Renderer ist (das mag früher anders gewesen sein). Das boundary=* mit protect_class=* ist für mich universeller Einsetzbar und logischer…

Wie erreicht man, daß leisure=nature_reserve als deprecated anerkannt wird?

streckenkundler

17

Zu dem Thema gibt es einen Hintergrund-Info Fußnote in der Wiki:

Das boundary=protected_area-Schema wurde eingeführt, als leisure=nature_reserve bereits existierte. Das protected_area-Schema wird erst seit 2019 von der Standardkarte unterstützt. Es ist nicht zu erwarten, dass leisure=nature_reserve völlig verschwindet. Dieser Sonderfall sollte bei Auswertungen berücksichtigt werden.

Ich denke das geht über die Wiki, also die Dikussionsseiten von

Da wird dann abgestimmt, soweit ich das verstanden habe.