Naturpark Schwäbisch-Fränkischer Wald - Quellen für Grenzen

Hallo,

der Naturpark Schwäbisch-Fränkischer Wald ist in OSM nicht vorhanden, bzw finde ich ihn nicht.
Ich würde ihn gerne eintragen, mir fehlt aber da etwas der Ansatz. Hat jemand eine Idee?

Vielleicht hier nachfragen? https://www.naturpark-sfw.de/
Adresse ganz unten auf der Seite.

die aktuellste (aufgefundene) Fassung:
https://rp.baden-wuerttemberg.de/fileadmin/RP-Internet/Stuttgart/Abteilung_5/_DocumentLibraries/Documents/Naturpark_SFW/NP_SFW_AenderungsVO.pdf

Die Karten dazu unter
https://rp.baden-wuerttemberg.de/rps/abt5/seiten/naturparke-s
Da die Karten Bestandteil der Verordnung sind, dürfen sie mMn genutzt werden.

Danke, die von Mammi verlinkte Fassung hatte ich auch gefunden, aber die Karten von Seichter nicht. Vielen lieben Dank.

Wie würdet ihr das praktisch angehen? Das sind über 100km Grenze. Wenn ich bspw. vorhandene (Gemeinde)Grenzen mitbenutzen würde, könnte ich das nur stückchenweise hochladen, was dann aber die QA-Tools triggern würde, da das MP nicht korrekt wäre. Ich befürchte, dass das dann schnell wieder wegkorrigiert wird.
Erstelle ich es lokal, kann ich mit Replikationskonflikten rechnen, da das schon etwas dauern kann. Ich könnte die Grenzen mit neuen Ways erstellen, hochladen und dann Stück für Stück mit vorhanden Ways verschmelzen. Oder ich arbeite mich Stück für Stück durch und verbinde die beiden offenen Enden temporär nach jeder Etappe damit das MP gültig ist.

Virtuelle Objekte sollten nicht mit realen Objekten abgebildet werden. Somit halte ich es für sinnvoll, die komplette Grenze neu zu erfassen…

Da der Naturpark an vielen Stellen über die Gemeindegrenzen definiert ist, würde ich diese Grenzen mitverwenden.
Bei einer entsprechenden note an der Relation erwarte ich nicht, dass da jemand etwas reparieren will, auch wenn ein QA Tool
da anspringt.

Die admin-Grenzen sind genauso virtuell wie die des Naturparks. Da große Teile der Naturparkgrenzen über Kreis- und Gemeindegrenzen deklariert werden, würde ich diese mitverwenden, d.h. in die NP-Relation aufnehmen. Das hat dann zur Folge, dass in den Eigenschaften der Grenzsegmente eine weitere Relationsmitgliedschaft auftaucht. Das halte ich für gut vertretbar.

Ein Übereinanderlegen (“Verkleben”) von zwei Grenzen halte ich nicht für vorteilhaft, es erschwert nur unnötig die spätere Bearbeitung. Das Durchklicken von übereinander liegenden Linien ist zwar trivial, aber lästig.

Wenn man es nicht in einem Rutsch schafft, würde ich mich Stück für Stück annähern, auf jeden Fall mit description versehen und z.B. in CS hierher verlinken. Da sollte dann nicht soviel schief gehen. Zur Sicherheit könnte man bei der Relation auch noch lifecycle-Prefixes anwenden, daß die Relation während der Bearbeitung unter dem “Radar” der QS-Tools bleibt und erst bei Fertigstellung freischalten.

Als direkte Nutzung der Geometrie oder “verkleben” mit der Admingrenze? Ich selbst mir da in meinen vielen Jahren noch immer unschlüssig ob eines richtigen Weges. Zur Zeit halte ich ein “verkleben” für besser, ob es so ist? Gute Frage, nächste Frage? Solange, wie ich mich mit sowas beschäftige, schwang das “Meinungspendel” immer hin und her…

Sven

Hallo
und wenn du die Arbeit in einigen Wochen beendet hast, kannst du es schnell mit einem shape prüfen:
https://udo.lubw.baden-wuerttemberg.de/public/
Leider ist das wohl nicht lizenzkonform für eine Übernahme, eine Prüfung sollte aber möglich sein

die Naturparkgrenzen sind auch nicht virtueller als die Gemeindegrenzen, oder?

Das wäre wirklich sehr praktisch! :slight_smile:
Die PDF-Karten aus den ZIP-Dateien entpacken und dann die darin enthaltenen Naturparkgrenzen extrahieren und in Shapefiles umwandeln:

for f in *.pdf; do ogr2ogr -f "ESRI Shapefile" "${f%.pdf}.shp" "$f" "NP_Detail_1:5000__Grenze_Naturpark" -nlt LINESTRING; done

Dann die shp-Dateien mit JOSM öffnen, benötigt wird dazu das OpenData-Plugin.

Siehe auch:

ogrinfo Detail_NP_SFW_1.pdf

mit ogr2ogr könnte man die pdfs auch direkt in OpenStreetMap Dateien umwandeln ohne den Zwischenschritt über die shapes, oder?

Egal ob man die bestehenden Geometrien/Ways mitbenutzt oder neue Ways mit den bestehenden verklebt, ist der Vorteil aus einer direkten Umwandlung vermutlich nicht so groß. Man muss trotzdem die gesamten 100km händisch durchgehen. Ich werde vermutlich die Daten aus der Verordnung in einem extra Layer lassen und nur zur Orientierung nutzen, da die Naturparkgrenzen schon bestehenden OSM-Features folgen. Da ist es egal, ob das Shp oder Osm Files sind.

Danke whb, der Tipp vereinfacht die Sache enorm.

OSM-XML kann zumindest meine Version (GDAL 3.4.1, released 2021/12/27) nicht schreiben (-f “OSM” out.osm):

stimmt, das hatte ich falsch in Erinnerung, es gibt dafür ein python script das auf ogr basiert
https://wiki.openstreetmap.org/wiki/Ogr2osm
da kann man bei einer Datei es auch gleich in josm machen