ok, das lief wirklich nicht optimal.
Der Revert ist abgeschlossen. Hier gibt es für die Interessierten nochmal die Import Guidelines zum Nachlesen: https://wiki.openstreetmap.org/wiki/Import/Guidelines
Wieweit die NSG-Grenzen für Brandenburg den urheberrechtlichen Anforderungen entsprechen, kann ich nicht beurteilen. Aber die aktuell in OSM enthaltenen entstammen m.E. aus einem Import bzw. sind von mehr oder weniger amtlichen Quellen übernommen wurden. Da die Umweltverwaltung BBs die Daten zwar unentgeltlich abgibt, aber schon immer auf eine Nennung der Quelle bei Weiterverwendung besteht, vermisse ich diese im Datenbestand! Oder finde ich nur nicht die richtige Stelle.
Die “Mutter” der Datenquelle liegt aktuell hier: http://www.mlul.brandenburg.de/cms/detail.php/bb1.c.280662.de Die Daten sind unter der Datenlizenz Deutschland – Namensnennung – Version 2.0 freigegeben.
Falls Interesse besteht, die Informationen nach OSM zu übernehmen, bin ich gern bereit in einer entsprechenden Community mitzuwirken, insbesondere da mir die auf der Site genannten Kontaktpersonen aus meiner früheren Tätigkeit bekannt sind.
Gruß Gert
Danke für den Revert!
moin,
mag jemand mal über dies ( http://www.openstreetmap.org/relation/5684638 ) und die anderen NSG schauen, ob die Quelle usw. verwendbar ist? Import?
Moin,
die Lizenz der Quellen scheint Datenlizenz Deutschland – Namensnennung – Version 2.0 zu sein (Shape Download Seite). Ich habe auf die schnelle nicht gefunden ob die kompatibel ist. Siehe auch mein Kommentar in http://www.openstreetmap.org/changeset/35548040
Ich habe gerade das hier gefunden im Forum, scheint also nicht kompatibel zu sein.
Wohingegen hier im Wiki die Lizenz als OK angesehen wird.
Da mir derzeit keine Anwendung bekannt ist, die boundary=protected_area rendert, habe ich mir heute selbst eine overpassTurbo - Abfrage bebaut.
http://overpass-turbo.eu/s/dEv
Die Abfrage baut bewusst ausschließlich auf boundary=protected_area und boundary=national_park auf und berücksichtigt nur die Grenze Brandenburgs (bzw. angeschnittene Grenzen).
braune Linie: Biosphärenreservate (protect_class=98)
dunkelgrüne Linie: Naturparke (protect_class=5)
rote Linie: Nationalpark (protect_class=2)
grüne Linie:NSG (protect_class=4)
hellrote, transparente Fläche: Totalreservate (protect_class=1a)
hat vielleicht noch ein paar Ecken und Kanten aber eventuell hilft es ja jemanden…
Sven
(Natur-)Schutzgebiete scheinen ja etwas unpopulär in OSM zu sein… Schade… Nun, sei es so… Mit stoischer Gelassenheit beschäftige ich mich weiter mit diesem, für mich interessanten Thema und deren möglichst OGC-konfomen Umsetzung (bzw. deren weitestgehenden Annäherung).
Ein Naturschutzgebiet besteht ja nicht immer aus einer Außengrenze… wie z.B. das Dürrenhofer Moor
Einige NSG’s haben auch definierte Totalreservate( im folgenden “TR” genannt; =Naturentwicklungsgebiete ect.) wie z.B. Drehnaer Weinberg und Stiebsdorfer See.
Solange es ein einfaches NSG ist, mit einer einfachen Linie, ist alles prima…
Nur meine Probleme…, denn so einfach ist es oft nicht, unter anderem wenn das NSG ein Totalreservat hat:
-
NSG’s orientieren sich aber auch gerne in Teilen ihrer Grenze an Administrativen Grenzen: http://www.openstreetmap.org/relation/5874907
-
bei NSG’s mit TR wird das TR vollständig von der NSG-Grenze umschlossen: z.B. http://www.openstreetmap.org/relation/4763396
-
bei NSG’s mit TR {vgl. zweiter Link} grenzt dieses TR manchmal in Teilen an die Außengrenze
a) http://www.openstreetmap.org/relation/5874542 und
b) http://www.openstreetmap.org/relation/5874094
- es gibt ein Mix aus 2. und 3.
Bei meinem Problem 1 plädiere ich für die Verwendung von Segmenten der Admin-Grenzen: solange man mit JOSM arbeitet und sich Grenzbearbeitung zutraut (!)
Bei meinem Problem 2 wird es schon schwieriger: die TR-Fläche ist lediglich eine Teilmenge des gesamten NSG. Datentechnisch wäre eine MP-Relation falsch, die innere TR-Fäche ist nicht von der äußeren Umgrenzung ausgeschnitten.
Bei meinem Problem 3 wird es noch komplizierter. Dadurch, daß die äußere Umgrenzung an mehreren Punkten gleich der innere Fläche ist, widerspricht es logischerweise der Definition des (Multi-)Polygons.
Wie kann man nun das alle einigermaßen sauber abbilden?
A: Admin-Grenzen direkt nutzen?
B: Admingrenzen indirekt durch “verkleben der Stützpunkte” nutzen?
C: site-Relationen anstatt Relationen mit type=boundary|multipolygon nutzen? Ziel wäre die Teilflächen des TR und dernucht TR-Flächen ansprechen zu können (u.a. wegen ref, ggf. Webseite, Wikilinks, ect.) Die unter 3. genannten Links zeigen einmal die type=site-Variante(a) und einmal die type=boundary-Variante(b); letztere verursachen logischerweise MP-Fehler beim OSMI.
Im Moment tendiere ich dazu, admin-Grenzen direkt zu nutzen und site-Relationen, beim Vorhandensein der o.g. Situationen 2-4 zu verwenden…
… oder hat einer eine andere Idee???
fragt Sven, der befürchtet, an den Grenzen der bei OSM verwendeten Taggingmöglichkeiten (und der mangelnden OGC- Konformität von OSM) angelangt zu sein.
PS: eigentlich wollte ich doch nur NSG’s nach dem boundary=protected_area - Schema eintragen… und nun das… Hmpf… 
PPS: bei den von mir jüngst neu eingetragenen Gebieten habe ich grundsätzlich auf leisure=nature_reserve verzichtet, da dieses aus meiner Sicht für die o.g. Aufgabe inkompaktibel ist.
Alleine in NRW gibt es 3181 NSGs. Die von Hand zu erfassen ist nahezu unmöglich. Ursprünglich ging es in diesem Thread ja um die lizenzkonforme Übernahme der eigentlich frei verfügbaren Daten. Da habe ich die Hoffnung noch nicht aufgegeben. Von daher würde ich die jetzige Erfassung so einfach wie möglich gestalten, um bei einer Datenübernahme flexibel zu sein und wenig Arbeit zu verlieren.
Gruß Klaus
Hallo Klaus,
letztendlich ist das ja das Ziel… auch einen gangbaren Weg zu finden, nicht nur die NSG-Außengrenze zu erfassen, sondern auch Totalreservate innerhalb des Gebietes (u.a. wegen Betretungsverbote ect…)
Für Brandenburg bin ich mal durchgegangen und hab alle Hebiete, die als NSG zu identifizieren sind mit den boundary=protected_area - Tags ergänzt. Das Tag leisure=nature_reserve habe ich gelassen.
Bei der Suche nach solchen Schutzgebieten bin ist auch auf einige gestoßen, die keine NSG’s sind, es waren Findlinge dabei, geschützte Bäume, ect. Nicht alles hab ich bisher gelöst. Auch einige landuse=conservation habe ich gefunden, die muß ich mir noch genauer anschauen, in den überwiegenden Fällen sind es mit an Sicherheit grenzender Wahrscheinlichkeit keine NSG’s
Ergo… ich putze auch erst mal das Vorhandene, um nur noch die echten Schutzgebiete zu haben.
Sven
Mit undokumentierten Datenkonstukten wie site-Relationen oder subarea-Flächen erreicht man nur,
dass die NSG nicht korrekt ausgewertet werden können.
Alle NSG haben eine Außengrenze, die man als Fläche oder MP nach den üblichen Regeln erfassen kann.
Falls ein NSG ein TR hat, kann man diese innere Fläche als ein weiteres OSM-Objekt anlegen (z.B. als
boundary=protected_area ohne Namen). Die Zuordnung ergibt sich hinreichend aus der Lage im NSG.
Das Problem mit den undokumentierten Datenstrukturen ist mir bewußt und es gefällt mit absolut nicht… Im Moment experimentiere ich ja auch etwas mit den Gebieten in meiner näheren Umgebung…
Ich hatte auch schon dran gedacht, nur die Außengrenzen als einfachen geschossenen Ring, wenn nötig als MP zu erfassen und die inner liegenden TR-Flächen als simple Flächen ohne Zugehörigkeit zu einer Relation zu erstellen. Letztendlich würde auf eine ähnliche Erfassungsweise wie bei den Admingrenzen hinauslaufen… Das ist mir dann auch in den Sinn gekommen, nachdem ich den Beitrag geschrieben und eingestellt hatte.
Das Erfassen eines NSG’s mit inneren oder an die Umgrenzung grenzenden TR-Flächen ist im Wiki bisher nicht gut (gegentlich gar nicht) dargelegt.
Sven
Hier hake ich noch mal nach…
Dann muß es auch Regeln geben, in welcher Reihenfolge und in welchen Abhängigkeiten etwaige Protect_class-Werte auszuwerten(*) sind…
Bei den Admingrenzen ist es vergleichsweise recht einfach, es ist es hierachisch gegliedert: von AL2 bis AL10/11 ect…
Bei protect_class ist es nicht zwangsläufig so… Ein Gebiet kann deckungsgleich Protect_class 4 und protect_class 5 sein und kann auch ein Protect_class 1 enthalten… Es besteht aber nur eine (rechtliche) Abhängigkeit zwischen Protect_class 4 und Protect_class 1 (z.B. NSG und ein TR des NSG). Auch das protect_class Protect_class=2 und Protect_class=4 können deckungsgleich sein, ein protect_class=1 gilt aber nur im Zusammenhang mit protect_class=4. Auch bei den anderen könnte es schwierig werden…
Mir geht es nicht darum, das boundary=protected_area - Schema zu kritisieren… Nein… Das ist gut… sondern um die Darstellung der rechtlichen und damit objektmäßigen Abhängigkeiten einiger Protect_class- Werte aufzuzeigen.
(*) Hier sehe ich derzeit keine Regeln im Wiki
Sven
PS: Ach ja, meine Aussagen gelten (zur Zeit) nur im Zusammenhang mit der brandenburgischen Naturschutzgesetzgebung.
Moin,
wenn es um rechtliche Aspekte geht, kommt man nicht umhin, dafür spezielle Relationen (Beziehungen, Abhängigkeiten) zu definieren.
Ein TR hat nunmal die Rolle “TR” und nicht “inner” und auch nicht “outer”.
Aber da muss sich halt jemand mit beschäftigen, der sich damit auskennt …
(allgemeingültig oder länderspezifisch oder …)
Gruß
Georg
Ich hab ja stoische Gelassenheit… 
Ok… ist eine gute Idee… Ich denke, daß ließe sich aber über das Tagging hinbekommen… Das NSG hat ja eine Nummer… Und alle Teilflächen, egal ob Zone 1, 2 oder 3 beziehungsweise Totalreservat|Naturentwickungsgebiet und allgemeine Schutzgebietsfläche belämen eben jene eindeutige ref. Ich hab im Moment nur noch keine freie Quelle…
Von daher habe ich meine testesweite angelegte Relation type=site und die dieversen Relationen mit role=subarea wieder aufgelöst… Es gibt nun eine Linie/eine Relation der umgrenzenden Linie als protect_class=4: http://www.openstreetmap.org/relation/5874542 und falls vorhanden, eine Umgrenzung des TR http://www.openstreetmap.org/relation/5927458 unter Ausnutzung gemeinsamer Grenzlinien, bzw. sofern festgelegt, auch Teilabschnitte administrativer Grenzen.
Ich habe ja die Hoffung, in nicht all zu langer Zeit offizielle Daten nutzen zu dürfen… dann wäre mein ref-Problem gelöst…
Im Zusammenhang dessen wünsche ich mir sehnlichst ein Rendering von boundary=protected_area anstelle von leisure=nature_reserve… es sollten auch nicht alle protect_class-Werte sein… Auch bei Josm könnte man da etwas arbeiten…
Sven
Wie genau sollte dann die Logik zur Darstellung von “boundary=protected_area” aussehen? Ich bearbeite nämlich das Thema derzeit für die Freizeitkarte-Android. Bislang wird dort “leisure=nature_reserve” gerendert, was ich (genau wie du) auch nicht so glücklich finde.
Gruß Klaus
Das nicht alle protect_class- Werte gerendert werden (können) ist zunächst einmal klar…
Ein Anfang wäre es sicher, protect_class=4 wie leisure=nature_reserve zu rendern, sowie protect_class=1, 1a oder 1b als Liniensignatur als dünne rote Linienschraffur mit 45° Linienwinkel zu rendern… Die Unterscheidung von 1a und 1b ist mit aber nicht 100% klar… “meine” Totalreservate" in Brandenburg habe ich mit 1a getaggt, da ich das als passend ansehe.
Von einem Tagging anderer protect_class - Werte würde ich zunächst absehen… Eventuell sollte man die Möglichkeit vorsehen, protect_class=2 wie boundary=national_park zu rendern.
Bei den Protect_class - Werten 5 und 98 (=LSG;Naturpark bzw Biosphärenreservat) hab ich keine echte Idee… Wunsch besteht… aber… Datenlage scheint schlecht zu sein…
Viele Grüße,
Sven
Ja, grundsätzlich stimme ich dir zu …
mit einem zurückhaltenden Overlay sollte man darstellen:
leisure=nature_reserve
boundary=protected_area && protect_class=4
und mit einem signifikanten Overlay Flächen mit Betretungsverbot:
boundary=protected_area && protect_class=1
boundary=protected_area && protect_class=1a
boundary=protected_area && protect_class=1b
Ob es die Klasse “protect_class=1b”, Zugang nur für indigene Völker, in Deutschland/Europa gibt, darf bezweifelt werden.
Im Moment berücksichtige ich in der Freizeitkarte-Android aber nur “leisure=nature_reserver” und zwar als “zurückhaltendes Overlay”:
Für Gebiete mit Betretungsverbot bietet sich in der Tat ein Schraffur oder ähnliches an. Ich werde da mal testweise was einbauen, z.B. für die “Döberitzer Heide” im Westen Berlins, und mich dann wieder melden.
Gruß Klaus
Sehr Schön…
Bezogen auf Mitteleuropa gibt es protect_class=1b nur einmal in Norditalien: http://overpass-turbo.eu/s/e5E
Bei mir im Großraum Spreewald habe ich auch einige protect_class=1a
Vielleicht animiert es ja die Renderer, auch die Hauptkarte mal umzustellen.
Sven
Die Naturschutzgebiete mit striktem Betretungsverbot habe ich mal wie “militärisches Sperrgebiet” dargestellt. Das verstehen die Kartennutzer dann auch …
Hier ein Beispiel aus dem Umland von Lübben (Brandenburg). Ein Klick aufs Bild vergrößert …
Gruß Klaus
PS: Die “Döberitzer Heide” im Westen Berlins wird leider nicht ausgewiesen. Das könnte am Tagging (MP) liegen. Vielleicht hat jemand Lust sich das mal genauer anzusehen.