Hallo zusammen,
Remscheid hat in OSM keine Stadtteile - das möchte ich ändern.
Da ich bei solch Umfassenden Änderungen bei Weitem nicht erfahren genug bin baue ich auf Unterstützung bei meinem Vorhaben:
Und zwar sind in der Stadt Remscheid (Kreisfreie Stadt, admin_level=6) aktuell nur die (politischen) Bezirke (z.B. Remscheid Süd, admin_level=9) und die in ALKIS verfügbaren - aber IRL relativ nutzlosen “Gemarkungen” (z.B. Remscheid Fünfzehnhöfe, admin_level=11) als vollständige Gebietsbegrenzungen gemappt. (Die Bezeichnung nutzt kein Mensch)
Es existieren keine Relationen mit admin_level 7 und 8 (mMn richtig, da kreisfreie Stadt), aber auch keine des Level 10.
Es gibt noch vereinzelte Markierungen von Ortschaften und Stadtteilen (im weitesten Sinne), die aber kein System haben (z.B. Nutzung des Tags place=hamlet als Stadtteilbezeichnung)
Da mich das bei der Orientierung mit OSM immer wieder stört, dass ich bei einer Adresse keinen halbwegs brauchbaren Stadtteil habe, würde ich gerne die von der Stadt Remscheid zur Verfügung gestellten “Stadtteile” als admin_level=10 importieren/einpflegen.
Wir kann ich hier weiter vorgehen, um die Stadtteile als sinnvolle Unterteilung in OSM einzufügen?
Die gewünschten Daten sind im Geoportal der Stadt Remscheid unter Lizenz Zero verfügbar:
(Infrastruktur → Stadtgebietsgliederung → Stadtteile)
“Der Inhalt der Internetseiten der Stadt Remscheid ist urheberrechtlich geschützt. Die Vervielfältigung von Informationen oder Daten hieraus, insbesondere die Verwendung von Texten, Textteilen oder Bildmaterial, bedarf der vorherigen Zustimmung der Stadt Remscheid.”
Hallo,
ich habe es mir mal angeschaut.
So ganz trivial ist der Import nicht.
Der Teufel steckt -wie so oft- im Detail:
a) in den “Außengrenzen” (admin_level=6) gibt es kleinere Unschärfen (meist kleiner 5m) zu den vorhandenen Grenzen - Dort würde ich die bestehenden Grenzen als Basis sehen.
b) die vorhandenen 4 Stadtbezirke (admin_level=9) sind innerhalb von Remscheid teiweise “freihändig” eingetragen und in weiten Bereichen mit postal_code-Grenzen identisch.
→ Hier würde ich mit einem Import starten wollen.
c) die (neuen) 50 Stadtteilgrenzen (admin_level=10) wären erst nach den Stadtbezirken dran
d) vorhandene Daten: Neben den bereits erwähnten place=hamlet gibt es u.a. auch place=locality und unterschiedliche Schreibweisen z.B. Hasten ./. Hasten Mitte (im Shapefile)
Wie soll damit verfahren werden?
Der reine Grenzimport würde die vorhanden Nodes ja nicht verändern. Die Namen würden dann (teilweise) nicht zusammen passen.
Was wird aus dem vorhanden place=hamlet ?
Dabei taucht die nächste Frage auf: Soll in jeden Stadtteil ein place-Node als admin_centre in der jeweiligen Relation? → Bei den 4 Stadtbezirken gibt es solche Nodes bisher nicht.
Aus technischer Sicht käme -für mich- ein Import per JOSM in Frage.
Die Shapefile kann man damit problemlos öffnen.
Danach könnte man die Stadtbezirke und -teile Schritt für Schritt übernehmen und an die vorhandenen Grenzen anpassen.
Das ist aber nix, was man “einfach mal so” nebenbei macht.
Siehe Pkt. b) Neben der Anpassung der vorhandenen Grenzen müssen die PLZ-Grenzen geprüft werden und können entweder mit ‘verschoben’ werden oder müssen separat angelegt/aufgesplittet werden.
Kleines Detail: In der Nähe der Hausnummer Gerstau 27 ist eine “Nadel” im Grenzverlauf. Das sieht für mich wie ein Datenfehler aus. So etwas würde ich beim Import ignorieren wollen.
ich stimme dir voll und ganz zu, übers Knie gebrochen wird da gar nix
Dass die Aktion mit einer eventuellen Neufassung von Grenzen und Bearbeitung von Bestandsdaten einhergeht habe ich schon erwartet.
Finde den aktuellen Zustand einfach zu chaotisch.
Wenn ich dich richtig verstehe würdest du mit einem Import der Stadbezirke (4x) starten und die daraus resultierenden Grenzen (viellieicht zusammengeführt mit den brauchbaren Außengrenzen) als Basis für die Unterteilung in Stadtteile nehmen?
Nachfolgend dann Anpassung der PLZ an die Gebiete und eventuell weitere Zusammenführungen von Grenzen.
Wie mit den vorhandenen Bezeichnungen umzugehen ist bin ich mir noch nicht ganz schlüssig.
Im Prinzip bringen die Stadtteile teilweise gängige Bezeichnungen mit (z.B. Lennep Altstadt, Hasenberg, Honsberg uvm.) aber auch eher unübliche ( z.B. Scheid und Kratzberg). Hier sehe ich allerdings die Vorteile überwiegen, in die Stadtteile place-Nodes einzufügen.
Edit: nachdem ich mir andere Städte angesehen habe ist dort sehr verbreitet zwar das admin_level=10 eingepflegt zu haben, allerdings die Bezeichnung nicht als admin_centre, sondern frei als Knoten place=suburb geografisch sinnvoll zu platzieren. Das würde ich dann hier auch so handhaben.
Für die gängigsten Unterteilungen, die keine Stadttteile sind müsste dann zusätzlich eine place=neighbourhood rein. (z.B. Gerstau, Rath). Die Ortschaften müssen natürlich weiterhin mit den entsprechenden place tags versehen sein.
(nebenfrage: macht es hier sinn, die Punkte in Flächen umzuwandeln, damit die Gebäude als zugehörig identifiziert werden können?)
Mein Vorschlag mit den 4 Stadtbezirken zu beginnen hat mehrere Gründe:
Es sind nur ‘4’
… und gleichzeitig sind diese ja später auch die (Teil-)Grenzen von vielen Stadtteilen.
z.B. hat der Stadtbezirk Alt-Remscheid den identischen Grenzverlauf mit:
Innerhalb von Remscheid (von Süd Richung Nord)
Westhausen
Ehringhausen
Reinshagen
Kremenholl
Honsberg
Blumental
Bliedinghausen
Zentralpunkt
Neuenkamp
Stachelhausen
Altstadt
Fichtenhöhe
Haddenbach
Goldenberg
Lüttringhausen West
Kratzberg
Von diesen Stadtteilen wären dann schon Teilabschnitte der Grenzen vorhanden.
In OSM werden üblicherweise diese Grenzsegmente mehrfach genutzt und nicht übereinander gelegt.
D.h. die Shapefiles können nicht ‘einfach so’ importiert werden. Weil dann die Grenzen übereinander liegen würden. Das geht halt nur in Teilstücken die dann jeweils in den entsprechenden Relation eingetragen werden. Bei den ‘Außengrenzen’ sind ja jetzt schon diverse Grenzrelationen beteiligt.
Was mir noch etwas Kopfschmerzen macht sind Differenzen zwischen den Shapefiles der Stadt und den Grenzverläufen in ALKIS. Beispiele finden sich im Bereich Stöcker Bach und der Grenze “Gemarkung Remscheid” (admin_level=11). Die Abweichung liegen im Bereich bis ca. 10 Meter. Das sollte zumindest im Wald nicht kritisch sein.
Anderes Beispiel wo der Morsbach in die Wupper mündet: Dort sind die Abweichungen etwas größer. (bis ca. 30 Meter) Könnte aber daran liegen, dass die Grenzen einfach an den Bach gepinnt wurden.
Beim Prüfen der Daten fiel mir das hier auf:
Dort wurde um eine Firma herum die Stadtgrenze von Wuppertal und Remscheid ziemlich freihändig geändert:
In Pink habe ich den Grenzverlauf lt. ALKIS mal grob markiert:
Der Ersteller des Grenzverlaufes wurde nach der Quelle angefragt:
Ob die Postadresse der Firma zu Wuppertal oder Remscheid gehört, sollte mMn auf die administrativen Grenzen keinen Einfluss haben.
Wobei ich das manchmal auch nicht checke… Wenn Flügel 1 von den Grenzen her in Remscheid liegt, warum gibt man dann als Firma nicht einfach Flügel 1, Remscheid an, sondern Wuppertal?
Das würde ja mit einer Anpassung der Stadtgrenzen auch bereinigt.
Zeigt aber wieder, dass die Administrativen Grenzen nicht mit den PLZ übereinstimmen müssen.
Die postalische Zugehörigkeit von Flügel ist historisch bedingt.
Laut Ratsinfo aus Januar ist das Verfahren immer noch im Gange.
Da dies mehrere Administrative Grenzen verschieben wird, wäre das dann doppelte Arbeit.
Vielleicht beschäftige ich mich dahin mit dem Prozess der Zusammenführung und bearbeite schonmal Lüttringhausen
Ich habe zwischenzeitlich den Grenzverlauf östlich der A1 zwischen Lennep und Frielinghausen etwas bearbeitet. Dort liefen mehrere administrative Grenzen (fast) parallel. Diese habe ich zusammengefasst auf den Verlauf lt. ALKIS:
Kannst dich ja gern wieder melden, wenn es weiter geht.
In QGIS gab es zumindest früher mal ein Skript, das diese Zerlegung automatisch gemacht hat.
Das Zusammenfieseln der Stücke in neue Relationen, Anschließen an und Weiterverwenden von bestehenden Abschnitten bleibt dann aber weiterhin Handarbeit.
Bei der Beurteilung, welche Grenze genauer ist, nehme ich eher die mit mehr nodes pro Abschnitt.
Wenn eine an vorhandenen Bach, Waldrand o.ä. geklebt wurde, ist sie natürlich nicht genauer als diese Linie, die ja meist aus einem mehr oder weniger genauen Luftbild abgemalt wurde.
Abgesehen davon ist das Kleben von Grenzen an physische Objekt bis auf wenige Ausnahmen sowieso keine gute Idee, siehe auch die Diskussionen zu den Naturschutzgebieten.
Unabhängig vom konkreten Fall:
Wenn zu einem Ortsteil/Stadtteil/-bezirk sowohl eine Grenzrelation als auch ein place-Node existiert bzw. neu angelegt wird, dann sollten diese beiden Objekte unbedingt miteinander verbunden werden.
In D dürfte bei admin_level > 8 dabei aber role:label idR. die bessere Wahl sein.
