Titeländerung von “iD: verschwundene Stützpunkte?” nach “iD und Umgang mit Schutzgebietsgrenzen”
Grund: durch die Beiträge von @limes11 scheint iD hier irgendwie seine Finger im Spiel zu haben.
Er hat die beiden Endpunkte des Wegs https://www.openstreetmap.org/way/309471261 miteinander verbunden. Dabei gingen keine Stützpunkte verloren. Die übrigen Stützpunkte der Relation sind in den Wegen, die er nicht angefasst hatte
Allerdings sollten die Wege in der Relation selbst keine boundary-tags haben. Die gehören nur auf die Relation selbst.
Solche Schutzgebiets-Relationen sollten mit iD nicht angefasst werden… oder wenn, dann nur, wenn man mit iD richtig fit ist und ganz genau weiß, was man tut…
Hier im Spreewald haben wir eine besondere Situation bei Schutzgebieten… Es gibt sich überlagernde NSG’s… und beim Inneren Unterspreewald kommt eine besondere Grenzsituation hinzu.
Wenn man sich das nun anschaut, sieht man, daß das NEG Wasserburger Spreewald durch das NSG Innerer Unterspreewald eingeschlossen ist. Der Grund liegt im Einigungsvertrag. Das BR Spreewald ist mit dem letzten Volkskammerbeschluß zum Biosphärenreservat geworden. Kraft Einigungsvertrag hat die damalige Verordnung Landesgesetzcharakter. Jegliche Veränderung ginge nur über ein Landesgesetz-Verfahren. Man hat hier aber Angst, daß dann das gesamte Konstrukt wie ein Kartenhaus zusammenfällt, daher fasst man das nicht an und stülpt ein neues NSG drüber…
Ergo… Bedienfehler…
Nun, bei Admin-Grenzen haben wir das auch, und wenn wir das nicht hätten, würde es noch undurchsichtiger… Wir hätten dann taglose Wege, deren Zweck nur in der Relation ersichtlich ist…
Sven
Nachtrag… Dann muß aber auch iD in der Fehlerprüfung einen Bug haben? Die Relation war vorher bereits sauber und mit den 4 Segmenten geschlossen, warum dann eine angebliche Fehlermeldung “found non-noded intersection between” (siehe CS-Kommentar) Was sagt diese Meldung bei iD aus? ich kenne iD nicht…
Du erhältst die Fehlermeldung, wenn du in ID editierst und den Weg anklickst:
Area should be a closed area based on the tag “boundary=protected_area”
Connect the ends
Remove the tag
Ignore this issue
Areas must have connected endpoints.
ID akzeptiert diese offenen Wege bei boundary=administrative. Bei protected_area ist das ‘area’ wohl zu viel des Guten. (Ich weiß nicht, ob es wirklich Konsens ist, die ways zu taggen. Bei Multipolygonen führt das oft zu defektem Rendering. Die Bedeutung des ways sieht man doch leicht an den Relationen.)
Meiner Ansicht nach muß da bei iD in Bezug auf boundary=protected_area nachgearbeitet werden. Die Alternative wären “gestapelte” boundary=protected_area-Ways: in Fall hier wären es 2.; im Extremfall könnten es auch mehr werden…und ab einem bestimmten Punkt (Stichwort 2000-Punkte-Grenze) müssen ways eh gesplittet. Ja und bei diesen ganzen Teilflächen kommt man um Relationen eh nicht drum herum…
Mit der BR-Spreewald-Grenze komme ich derzeit nicht an diese Stützpunkte-Grenze (1182 Stützpunkte), da diese Grenze aber teilweise durch Admin-Grenze definiert ist, könnte es sein, daß man diese Punkte-Grenze bei Detailierung und Lagekorrekturen der Admin-Grenze erreicht… Bei anderen boundary=protected_area-Grenzen nähert man sich dieser 2000-Punkte-Grenze (BR Schorfheide-Chorin).
Bei den boundary=protected_area-Grenzen hier im Spreewald bin ich vor Jahren übrigens bereits einen Schritt zurück gegangen… meine ursprüngliche Erfassung war, daß ich auch physisch Admin-Grenz-Segmente für das Schutzgebiet verwendet habe, dort, wo es entsprechend definiert ist…
Sven…
PS: ich überlege mit mal einen besseren Titel: z.B. iD und Umgang mit Schutzgebietsgrenzen…
Das sehe ich auch so. Ich ignoriere die aktuell aufploppenden Fehlermeldungen einfach. Aber so manchen iD-Benutzer wird es verleiten, die Fehlermeldung zum Anlass zu nehmen, um den Korrekturvorschlag des Editors anzunehmen.
