Import von Schutzgebiets Shapes

Dann ist es wahrscheinlich ein Problem des Koordinatensystems (wird ja von Streckenkundler untersucht).
Übrigens: Oft steht im Original-Shapefile (ESRI?) Informationen zum Koordinatensystem.

Dann lohnt sich mMn ein Nachbohren bei Gemeinde oder LRA.

Och, der Offset ist nicht der Rede wert… Ich hatte die Befürchtung, daß es was mit Gauss-Krüger-Daten zu tun hat(*), darum meine Nachfrage…

(*) dann wäre es was um 50-100m oder so, je nach Region mehr oder weniger…

Offset an der Staatsgrenze ist gleichmäßig in x-Richtung ca. 0,4m und y-Richtung ca. 0,8m. Das ist für mich absolut vernachlässigbar…

Aber…

LSG “Rotwand”: Ich würde die in OSM vorhandene Staatsgrenze als Südgrenze des LSG verwenden, den Rest aus dem Shape… Ansonsten… Uhi… Schwierig… zwischen Schliersee und Bayrischzell würde ich die Shape-Grenze als solche in Erwägung ziehen, da fehlt mir aber das Wissen der Erfassung der Gegend… Entlang z.B. von Wegen und auch der St 2075 entlang würde ich die Grenze dann diese Straßen und Wegen ausschließend, die Grenze daran anpassen…

LSG “Sutten und Umgebung”: hat gemeinsame Grenze von Rottach-Egern und Schliersee… die in OSM vorhandene Grenze sieht aus der Ferne des Spreewaldes genauer aus… Kann ich durchaus auch glauben, ein Vergleich zu einer Katasterkarte wäre hier sicher hilfreich, fehlt mir aber…

Nachtrag…

Schutzgebietsgrenzen (auch wenn diese durch administrative Grenzen definiert sind) werden meiner Erfahrung nach nicht so regelmäßig nachgepflegt, wie es mit den Administrativen Grenzen selbst geschieht…

Seitens des Schutzgebietskatasters ist es stets nötig, Schutzgebietsgrenzen nachzupflegen… Eine unendliche Aufgabe… Gerne wurden/werden in den Originalunterlagen der Unterschutzstellung die Grenzen ganz oder Teilweise nach Flurstücksgrenzen definiert. Eben solche Flurstücksgrenzen sind mitunter einer ständigen Veränderung (Lageverbesserung, Teilung, Verschmelzung, BOV) unterworfen, was die Laufendhaltung teilweise extrem erschwert…

Somit koppeln sich vermeindlich Schutzgebietsgrenzen mal von adminstrativen Grenzen oder anderen landschaftlichen Gegebenheiten ab…

…so ich muß ins Bette…

Grüße,

Sven

+1, würde ich auch so machen, wenn die Straße die Grenze ist (bzw. parallel dazu) dann macht das am meisten Sinn, wenn man der (vermuteten) Lagegenauigkeit des offiziellen Shapes den Vorzug gibt, die Grenze dann aber nicht zum Rest der Karte passt, ist niemandem geholfen.

Danke mal allerseits bis hierhin…

Das läuft, deshalb hab ich noch nichts importiert.

So die, Antwort vom LRA ist inzwischen da: “Die Gemeindegrenze verläuft an den Flurstücksgrenzen. In solchen Portalen wird sie oftmals nur vereinfacht dargestellt. Dass die LSG-Shapes exakt der Gemeindegrenze entsprechen, kann ich Ihnen nicht versprechen, aber auf jeden Fall genauer als die vereinfachten geraden Linien”.

Und nun? Einen Straßenverlauf nach Bild oder Track-Aufzeichnung anzupassen ist ein Ding, eine Grenze zu verschieben (und wenn’s nur ein paar Meter sind) was anderes. Sprich, ich tu mich immer noch schwer zu entscheiden, wer jetzt Recht hat (Anfrage an einen der ursprünglichen Mapper der Grenze läuft auch noch). Ich glaube aber auch nicht, daß ich in endlicher Zeit eine wirklich belastbare Aussage von offizieller Stelle bekomme. Bin von Natur aus eigentlich ein Pragmatiker, aber hier komm ich in’s grübeln…

Und dann noch eine andere Frage: Teile der neuen Linie werden dann ja quasi sowohl boundary=administrative als auch boundary=protected_area (mit protected_area in der neuen Relation für die Shape). Die jeweiligen “Doppel-Ways” muss ich aber entweder/oder taggen, oder gar nicht, weil eh die Relation maßgeblich ist?

Das Taggen der Linien ist im Prinzip redundant, wird bei “normalen” MPs auch beanstandet, ist bei admin-Relationen aber Standard: boundary=administrative & admin_level=*, wobei der höchstrangige (niedrigster AL) genommen wird. Gibt es analog auch bei reinen PLZ-Grenzen, die nicht mit admin-Grenzen zusammenfallen.

Folgender ChangeSet - ich betrachte jetzt mal die Gemeinde-Grenzverläufe aus offizieller, “maschinenlesbarer” Quelle als valider. Bitte mal kommentieren, ich hab noch 10 andere LSG Shapes hier liegen…

Wobei mir bei der nächsten Shape schon wieder meine Zweifel kommen :confused: Hier macht die vorhandene Grenze in OSM (orange Linie) auf Basis des Bayern 80cm Bildes wesentlich mehr Sinn als die rote Shape Line (bei N47.7366, E11.8336)

Also best-guess Einzelfall-Entscheidung.

Die Frage hatte sich mir auch schon gestellt, das Ergebnis bzgl. Schutzgebiete ist festgehalten unter
https://wiki.openstreetmap.org/wiki/DE:Tag:boundary%3Dprotected_area#Relation_type.3Dboundary
“Hinweis: 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 […]”

Schau dir den Bereich mal im Bayernatlas an:
https://geoportal.bayern.de/bayernatlas/?lang=de&topic=ba&bgLayer=tk&catalogNodes=11,122&E=712245.44&N=5290742.17&zoom=13
Hintergrund Webkarte ist noch eine vereinfachte Linie (lila), Hintergrund Topographische Karte siehst du die Flurstücksgrenzen. Anhand der Flurstücksgrenzen siehst du auch, dass die vorhandene Grenze in OSM (orange Linie) weniger Sinn macht.

die rote Linie sieht für mich stimmiger aus, auf jeden Fall deutlich detaillierter. Könnte natürlich trotzdem verschoben oder sonstwie falsch sein. Die orangene Linie ist im Vergleich dazu wischiwaschi, abgerundete grobe Linien. Aber je nach Maßstab könnte man natürlich auch sagen erstaunlich genau und völlig ausreichend für fast alle unsere Anwendungen :wink:

Bei den admin- und PLZ-Relationen sind die tags an den ways drin, weil es (angeblich) Anwendungen gibt, die darauf angewiesen sind.
Wenn davon bei den Schutzgebieten nichts bekannt ist (die sind ja idR simple geschlossene ways), würde ich ebenfalls dafür plädieren, auf ein boundary=protected_area auf den ways einer solchen Relation zu verzichten.