+1
Super Zusammenfassung!
Und Kudos an Ian für’s nachfragen und besser-machen-wollen!
Ich verwende in solchen Fällen die bereits vorhandenen Linien weiter und füge sie mit ergänzenden Linien zu den von mir neu erstellten Flächen zusammen. Ich fange mit einer Teilfläche an und verbinde die restliche Relation im Trennungsbereich mit einer neuen “outer”-Linie, so dass die restliche Relation weiterhin funktioniert. Dann kommt das Teilstück drann. Das Ganze ist durchaus nicht banal zu bewältigen, man braucht dafür schon ein wenig Routine, Konzentration und möglichst auch am Stück Zeit.
Ich kenne bislang keine Lösung, um diese Nodes wieder per Klick zu verbinden. Es gibt zwar inzwischen im iD-Editor Fehlermeldungen, wenn sich zwei Punkte sehr nahe liegen, aber meines Wissens nur, wenn z.B. der End-Node einer highway-Linie nahe an einer anderen higway-Linie liegt und nicht mir ihr verbunden ist oder wenn zwei Nodes eines Objekts sehr nahe beieinander liegen. Ich habe aber noch nicht beobachtet, dass es eine Fehlermeldung gibt, wenn Nodes einer landuse-Fläche sehr nach von Nodes einer anderen landuse-Fläche liegen. Müsste man mal ausprobieren.
Ich füge bislang in solchen Fällen tatsächlich die voneinander gelösten Nodes wieder manuell zusammen (einen davon anfassen und etwas hin und her bewegen, bis er sich mit dem anderen verbindet, oder ich löse halt vorab nur die Nodes einzeln voneinander, die ich trennen will.
Der iD-Editor wird aber in der Hinsicht immer weiter entwickelt und nicht immer bekomme ich mit, dass es inzwischen andere Möglichkeiten als die gibt, als ich es gewohnt bin. Und manchmal sind neue Funktionen, die Fehler vermeiden sollen, für mich als langjähriger iD-Editor-Nutzer auch hinderlich. Im Moment gibt es teilweise falsche Fehlermeldungen, wenn ich z.B. einen Pfad erstelle, der dann in eine Treppe übergeht, zeigt mit der iD oft Fehlermeldung an, dass es ein routingfähiges Objekt gebe, dass nicht mit dem Rest verbunden sei und ich stelle meist fest, dass alles korrekt verbunden ist und kann dann nicht mehr machen, als die Fehlermeldung zu ignorieren. Ich habe aber Hoffnung, dass mit dem nächsten Release das wieder besser wird.
Ich will jetzt hier kein iD-Bashing betreiben, aber in JOSM geht das mit dem contour-merge-plugin mit zwei bis drei Mausklicks.
Es gibt halt immer spezielle Aufgaben, bei denen einer der Editoren weniger komfortabel ist.
Die Häuser auf der linken Seite einer “kleinen” (lanes=2) Bundesstraße bilden städtebaulich oft ein Ensemble mit denen auf der rechten Seite. Das residential-Poly am Bürgersteig enden zu lassen nur weil da eine (Haupt-)straße ist, ist fernab jeder Realität. (Berlin als schlechtes Beispiel, wo jeder Häuserblock allein für sich steht) Man ist gut beraten, Residentials in Richtung solcher Ensembles zu gliedern. Soziologische Einflüsse können eine Rolle spielen (Reichenviertel), aber die Begriffe sollten in der Bevölkerung geläufig sein.
Ist Dein Vorschlag ernst gemeint? Armenviertel abteilen, oder doch nur Reichenviertel?
Und stigmatisierenden Begriff ran schreiben, richtig verstanden?
Ich schriebe jetzt lieber nicht, wie der hier in der Bevölkerung geläufige Begriff des Armenviertels lautet.
(Da ich selbst eine teilweise jüdische Familienabstammung habe, stimmt es mich traurig).
Ich trenne übrigens, wie von Galbinus beschrieben, an Hauptdurchgangstraßen.
Wartbarkeit der Relationen und Multipolygonvermeidung sind die Kriterien.
+1
Auch und vor allem wenn man viel im kleinstädtischen Bereich oder ländlich/dörflichen Bereichen mappt, kommt man sonst sehr schnell zu Angrenzungsproblemen bei siedlungscharakterisierenden landuse-Werten… Dann lieber an wie beschrieben trennen.
Sven
Ich verstehe, was Du meinst und stimme Dir in sofern zu, dass gewachsene Wohnviertel in jedem Ort eine gewisse Bedeutung haben, auch wenn das von Dir gewählte Beispiel sehr unglücklich gewählt ist, wie man am nachfolgenden Kommentar erkennen kann. Es stimmt aber schon dahin gehend, dass es zumindest im Volksmund in nahezu jedem Ort einen “Millionenhügel” oder auch mehrere gibt, auch wenn der korrekterweise auf keiner Karte auftaucht.
M.E. hat das aber mit dem landuse nichts zu tun, der ist völlig unabhängig von der Art der Wohnbebauung. Residential ist residential, egal ob es ein Hochhausviertel oder eine Villengegend ist.
Danke Dir und auch dieterdreist für Eure Hinweise. Und das funktioniert dann auch mit iD, wenn ich Dich richtig verstehe. Habe mich da bisher nicht rangetraut, weil es immer wieder heißt, bei der Benutzung von iD sollte man die Finger von Relationen lassen …
Ja, die Meldungen zu den nicht verbundenen highways kenne ich auch und nein, bei landuse-Flächen gibt es die definitiv nicht. Deswegen bin ich ja damit reingerasselt und habe gefühlt 100 Osmose-Fehler produziert, auf die mich skyper dann hingewiesen hat … zum Glück …!!.. sonst hätte ich vermutlich fröhlich weiter gemacht … 
Ja, genau so habe ich es dann auch gemacht, wobei das manuelle Verbinden genau so zeitaufwändig ist wie das einzelne Trennen. Aber ok, et iss wie et iss.
Gut zu wissen … JOSM steht ja ohnehin auf meiner todo Liste, aber bisher bin ich mit iD eigentlich sehr gut klar gekommen. Aber dass JOSM vom Umfang her mehr Möglichkeiten bietet als iD ist hier ja schon öfters thematisiert worden.
+1!
Hallo
wenn ich das richtig verstanden habe:
wenn ich in ID zwei oder mehr Knoten verbinden will fange ich diese mit dem Lasso ein und verbinde sie durch drücken der c-Taste
Gruß
Danfost
Ich beschwere mich ja gar nicht, das manches mit dem iD-Editor vielleicht weniger komfortabel geht als mit JOSM. Jeder arbeitet halt damit, was er gewohnt ist. Ich habe mal einen Umstieg auf JOSM versucht, bin mit dem Editor aber nicht warm geworden. Und der iD-Editor hat halt auch seine Vorzüge. Fehler produzieren kann man mit jedem Editor.
Oh ja, stimmt 100%ig, und das liegt meistens nicht am Editor … 
(wie ich aus eigener Erfahrung bestätigen kann).
landuse geht um die Nutzung des Bodens, städtebauliche Figuren muss man anders erfassen, da gibt es aber kaum Bestrebungen bisher. Straßen sind keine Wohnnutzung, die haben ihren eigenen landuse, von daher wird man mittelfristig alle landuses dort geteilt haben.
So ist es.
+1
Sven
Übgrigens gibt es keine Probleme mit dem iD-Editor bei der Erstellung oder Bearbeitung von Multipoligonrelationen. Die immer wieder vorgebrachten Probleme betreffen meines Wissens ausschließlich Routenrelationen, weil der iD bei Veränderungen der Relation offensichtlich die Reihenfolge der Relationsmitglieder zerschießt. Wenn dann z.B. eine Wanderroutenrelation als GPX-Datei aus der OSM-Datenbank exportiert, springt die GPX-Linie dann quer von einem Abschnitt zum anderen.
Das sieht dann so aus:
… müsste aber ungefähr so aussehen:
Leider kenne ich bislang kein komfortabel zu bedienende Tool, um eine durcheinander geratene Routenrelation sauber zu sortieren und mir ist unverständlich, wieso die Macher des iD-Editors das Problem nicht in den Griff bekommen.
Tool das eine heruntergeladene GPX Spur sortiert kenn ich auch keins, aber eins, das Routen in den OSM Daten erstaunlich gut reparieren kann, das kenn ich. Spoiler, der Name ist im Thread bereits gefallen 
im Relationeneditor von Josm gibt es einen Sortieren-Knopf.
Das hatte ich mal versucht, ist aber schon länger her, kam aber irgendwie nicht so gut klar damit. Vielleicht sollte ich da mal einen zweiten Anlauf machen. JOSM wurde ja auch weiterentwickelt.