Irgendwann vor langer Zeit hatte ich es einmal angekündigt. Wenn es Wirrwarr bei den Grenzlinien gibt werde ich das hier melden. Also ich hatte mir ein Tool programmiert, dass bei einem Klick in die Map die Grenzlinien einer gewissen Stufe (habs vergessen wie es exakt hieß) zusammensetzt und als Polygon anzeigt. Das funktionierte bisher ganz gut (außer bei mit Exklaven und Inseln und derlei). Bei Dabendorf gibt es Probleme. Da wurden die Grenzlinien falsch verknüpft. Siehe Screenshot im Anhang. Wieso geht kein Anhang?
Das muß an deinen Daten oder so liegen. Bei Dabendorf (al=9) waren lediglich die Elemente nicht sortiert. mit CS https://www.openstreetmap.org/changeset/87470053bereinigt.
Sven
Da ist aber immer noch etwas faul:
AL 9 Zossen https://www.openstreetmap.org/relation/176412 umfasst auch das Gebiet von
AL 9 Dabendorf https://www.openstreetmap.org/relation/11004330#map=14/52.2477/13.4351
Dabendorf kann keinen AL 9 mehr (und auch keinen AL 10) haben, da es laut Hauptsatzung der Stadt Zossen von 2009 nur noch “Gemeindeteil Dabendorf im Ortsteil Zossen” ist.
Im offiziellen adressverzeichnis gibt es auch keine Adressen mit Ortsteil dabendorf. Allerdings gibt es Adressen mit dem Ortsteil lindenbrück, dafür gibt’s aber noch keine admin boundary.
Kenne mich mit AL nicht so gut aus, aber Lindenbrück ist ebenfalls ein Teil von Zossen.
…wenn ich mir das anschaue, würde ich es folgendermaßen aufbauen…
Zossen: al=8 (ist klar)
Ortsteile: Glienick, Hrostfelde, Schünow, Kallinchen, Nächst Neuendorf, Nunsdorf, Schöneiche, Wünsdorf, Lindenbrück und Zossen jeweils als al=9, da eigene Ortsbeiräte (Ja, Zossen nochmal als Ortsteil, siehe Hauptsatzung §5, eigene Ortsbeiräte)
die in §4 Abs. 2 benannten Siedlungsflecken als al=10…: Also Dabendorf als al=10 unterhalb von Zossen (al=9) u.s.w.
Dann passt meiner Meinung nach die Hierarchie…
Sven
Die Grenzlinien-Verbindungen passen immer noch nicht. Also mein Tool funktioniert so ähnlich wie das Feature “?” in openstreetmap.org. Mit einem Klick in die Map weren die einzelnen Linien vom Umschließenden Objekt auf Ebene n von der OSM API ausgeliefert. Diese setzt mein Script zu einem Polygon zusammen. Bei openstreetmap.org funktioniert das mit dem Feature “?” irgendwie anders als bei mir. Was also Fakt ist: Wenn ich in meinem Tool in die Area Stadtgebiet Zossen klicke, dann wird mir die Stadtteilgrenze (mit allen innenliegenden Ortsteilen) als Linien von OSM API geliefert. Wenn ich in die Area Dabendorf klicke, dann werden die Linien der Stadtteilgrenze Dabendorf und zudem weitere der Stadtteilgrenze Zossen geliefert. Diese baut mein Tool zu einem Polygon zusammen und es kommt dabei das heraus was oben im Screenshot zu sehen ist. Also muss es irgendwo in OSM einen Fehler geben, der die API dazu veranlasst mehr Linien als notwendig zu senden.
Die Stadtteilgrenze Zossen hat Dabendorf inklusive.
Die Stadtteilgrenze Dabendorf umschließt in openstreetmap.org nur Dabendorf und in meinem Tool gibt es obigen Fehler.
Es liegt damit ein “admin_level 9” innerhalb eines “admin_level 9” und das funktioniert nicht und ist nicht korrekt.
in openstreetmap.org:
Dabendorf:
Relation: Dabendorf (11004330)
Elemente im Grenzrelation AL=9 Dabendorf sortiert; dort is_in entfernt.
Bearbeitet vor 21 Tagen von streckenkundler
Version #3 · Änderungssatz #87470053
Tags
admin_level 9
boundary administrative
name Dabendorf
type boundary
Mitglieder
Weg 337451081 als outer
Weg Dabendorf/Zossen (792612596) als outer
Weg Neukölln-Mittenwalder Eisenbahn (113831543) als outer
Weg Neukölln-Mittenwalder Eisenbahn (263209911) als outer
Weg Dabendorf/Zossen (792612594) als outer
Weg Machnower Chaussee (49185909) als outer
Weg Machnower Chaussee (44838772) als outer
Weg Telzer Weg (242009843) als outer
Weg Telzer Weg (349995473) als outer
Weg 792612589 als outer
Weg Grenze Mittenwalde/Zossen (792612590) als outer
Weg Grenze Rangsdorf/Zossen (86383924) als outer
Weg 264644569 als outer
Knoten Dabendorf (475274393) als label
Zossen:
Relation: Zossen (176412)
Adm. Grenze Dabendorf
Bearbeitet vor 3 Monaten von Megachip
Version #16 · Änderungssatz #83659385
Tags
admin_level 9
boundary administrative
name Zossen
name:prefix Ortsteil
type boundary
Mitglieder
Weg 257674160 als outer
Weg 261418791 als outer
Weg 51653342 als outer
Weg 37870283 als outer
Weg 257639539 als outer
Weg Grenze Mittenwalde/Zossen (92738032) als outer
Weg Grenze Mittenwalde/Zossen (792612590) als outer
Weg Grenze Rangsdorf/Zossen (86383924) als outer
Weg 264644569 als outer
Weg 337451081 als outer
Weg 792612597 als outer
Weg 337457922 als outer
Hat denn inzwischen jemand die von Sven (streckenkundler) vorgeschlagenen Korrekturen o.Ä. umgesetzt? (Wenn niemand etwas geändert hat, kann sich auch nichts geändert haben. ;))
Hach… ich habs mir fast gedacht…
Ich setze mich mal ran…
Sven
So… al=9: Wünsdorf verkleinert, al=9: Lindenbrück ergänzt, al=9: Dabendorf nach al=10 verschoben. Alle Grenzen waren vor dem Hochladen per Definition und JOSM-Validator geschlossen. Ach: admin_centre ergänzt…
Es sollte theoretisch nun passen… Mal sehen, ob https://osm-boundaries.com/ auch der Meinung ist.
CS: https://www.openstreetmap.org/changeset/88473930
Sven
Vielen lieben Dank fürs Aufräumen! 
Gestern Abend, im Bette ist mir wahrscheinlich der wahre Grund eingefallen, warum die Auswertung Wirres gezeigt haben könnte… es lag bestimmt doch an der Auswertung… Die Grenze von Dabendorf (ehemals al=9, nun al=10) war in Teilen durch eine highway-, bzw. railway-Linie definiert… Ich hab das eben bereinigt und die Grenzen separiert… Bahnlinien und Straßenachsen sind meiner Erfahrung nach niemals administrative Grenzen. Bahn und Straße sind bei Grenzen im Detail immer einschließend oder ausschließend, niemals teilend (im Gegensatz zu Gewässerachsen).
@lorissa… bitte mal nachprüfen… Auch prüfen, ob an anderen Stellen sowas Teil als Grenzen sein können.
Allgemein würde es mich mal interessieren, wieweit solche Linienverwendung speziell bei Grenzen noch verbreitet ist…
Sven
Kommt leider immer wieder vor. Selbst bei Gewässern sollte man das nur machen, wenn das offiziell so geregelt ist.
Ist halt zugegeben bequem, so einer Linie mit “F” zu folgen, mal abgesehen vom versehentlich Fang auf einen Grenznode bei einem Klick in der Nähe.
Na, wenn es “nur” eine mit “F” erstellte Linie gewesen wäre, wäres es zu verschmerzen gewesen, denn mit der Filter-Funktion JOSM hätte man nun die “verklebte” Linie sauber separieren und bearbeiten können…
Hier war allerdings eine Linie mit hw=primary bzw. railway=disused selbst als Teil der Grenze verwendet worden… das dürfte der Grund gewesen sein…
Sven
@streckenkundler, sieht gut aus! Danke!
Ob als Grenzlinie eine Straßenlinie oder sonstwas verwendet wird, interessiert mein Toll nicht. Ansonsten weiß ich zuwenig von der Materie, wie das bei Doppelbelegung (Grenze und Straße) in den Tiles dargestellt wird. Müsste ja nur eines von beiden möglich sein, also würde dann eines fehlen.
Sowas wie mein Tool ist meines Wissens nach einmalig. Ich verwende es auch nur lokal und habe es nicht online gestellt, aus verschiedenen Gründen:
1.) Jeder Klick in die Karte ist eine Datenbankabfrage. Manchmal verklicke ich mich selbst, das geht schnell so ein Klick. .oO(Doppelklick einbauen könnte ich mal antesten).
2.) Das Zusammensetzen der einzelnen Linien zu einem Polygon ist sehr aufwendig. Mein Computer benötigt da manchmal schon einige Zeit. Wobei sich die Zeit summiert aus DB-Anfrage-Antwort-Zeit und Zusammensetzen-Zeit. Die Linien werden von OSM nicht sortiert ausgeliefert.
Also ich schätze, mein Tool ist einmalig. Ich benötige es für einen schnellen Blick, um zu sehen was alles in einer Gemarkung liegt. Dabei ist es manchmal schon wichtig auf welcher Straßenseite / Flussseite die Grenze verläuft, aber nicht immer, also eigentlich nur in urbaner Gegend, in Wald und Wiese ist es relativ egal.