Sehr gut ausgedrückt!
War hier eigentlich nicht nötig, weil iD in diesem Fall vielleicht schlauer ist, als man glauben sollte … wenn ich den im Beispiel angesprochenen Node lösche, ist sowohl das Ortsschild als auch der Verbindungspunkt der beiden Straßensegmente weg. Wenn ich dagegen die Funktion “Entnimm diesen Punkt von seinen Linien/Flächen” (aus dem PopUpMenue) verwende, wird lediglich der Schildnode gelöst und der Straßennode bleibt erhalten (möglicherweise wird der Node mit dieser Funktion automatisch verdoppelt?). Ist also lediglich ein Arbeitsschritt … die Frage ist, ob es beim Hochladen dann eventuell doch noch Wahalla gibt, das wollte ich im vorliegenden Fall nicht einfach ohne Rückmeldung machen.
Tatsächlich gibt es eine ähnliches Ergebnis, wenn ich in iD die Funktion “Trenne diese Fläche von anderen Objekten” nutze, um z.B. bei Bearbeitung von Landuse-Areas miteinander “verklebte” Flächen voneinander zu lösen. iD verdoppelt dann bei allen aufeinanderliegenden ways die nodes, so dass man die herausgetrennte Area beliebig verarbeiten kann.
Das hat allerdings den Nachteil, dass bei den ways, die man bei der Bearbeitung nicht manuell anfasst, die nodes nach dem Hochladen weiterhin unverbunden aufeinander liegen bleiben und zu Fehlermeldungen z.B. in Osmose führen. Man muss dann jeden einzelnen betroffenen node manuell wieder mit seinem Duplikat verbinden, da eine Funktion dafür in iD nicht zur Verfügung steht.
Na. wenn Du nur den Knoten ausgewählt hast, sollte es keine Probleme von übereinanderliegenden Knoten geben, aber getestet habe ich nicht, ob eventuell die beiden Linien dann jeweils einen eigenen Knoten haben und somit nicht mehr verbunden sind.
Ich war jetzt aber auch kurz am Überlegen und denke, ich hatte das Ortsschild aus den Linien gelöst (JOSM utilsplugin2 “Atl+Umschalt+J”) um es an die neue Stelle zu setzten.
“Historie des Ortsschildes beibehalten” ist natürlich in diesem Fall kein “von hinten durch die Brust ins Auge”. Danke für den Hinweis.
stimmt halt nur, wenn die einfache Software dann die richtigen Sachen automatisch macht oder gar nicht erst ermöglicht, dass man Dinge damit verändert auf die sie nicht adäquat vorbereitet ist (z.B. einen way nicht splitten lässt, wenn der in einer route-Relation ist und die dabei kaputt gehen würde). Wenn es dagegen einfach aussieht, aber man durch die vermeintlich einfachen Edits irgendwas kaputt macht, vielleicht sogar ohne gewarnt zu werden oder es überhaupt bemerken zu können, dann ist es ein Problem.
Wenn ein Editor nur POI Punkte (nodes) bearbeiten kann, dann ist das zwar einfach aber es reicht halt nicht, weil viele Features auf ways und relationen getaggt sind, und dadurch zu erwarten ist dass viele Doppelungen erstellt werden
Vielen Dank an die Helfer, ihr habt mir sehr geholfen. Ich hab jetzt noch 1 Ortsausgangsschild angebracht. Den Rest werde ich mir merken bis zum nächsten Mal. 
Youah, keine Frage … im Einzelfall kann auch eine einfache Software Mist sein, das ändert aber nichts an der grundsätzlichen Richtigkeit meiner messerschaften Analyse … 
… wobei ich iD so schlecht gar nicht finde für die einfachen Aufgaben wie Häusle malen, POI erfassen, hier und da mal einen Weg einzeichnen und Tags ergänzen. Und vieles lässt auch iD nicht zu (z.B. einen way zu splitten, wenn der in einer route-Relation ist).
Wie bitte?
Hallo
doch das geht.
ich habe eine Busrelation aufgetrennt um eine Abbiegespur anzulegen, hat ID alles schön gemacht auch die Relation wurde als durchgängig angezeigt.
Allerdings machte mich ein anderer Mapper darauf aufmerksam dass die Reihenfolge der Relationsteile nicht mehr stimmt.
Ich wollt nochmal irgendwann testen ob das Problem bei ID lag oder vor dem Bildschirm gesessen hat.
Gruß
Danfost
Na surprise … wenn man versucht, einen zu einer Relation gehörenden Weg an einem Node mit der Funktion “Trenne die Objekte an diesem Punkt” aufzutrennen, wird das mit dem Hinweis “Dies kann nicht getrennt werden, weil es Mitglieder einer Relation verbindet” von iD verhindert.
Benutzt man an derselben Stelle stattdessen die Funktion “Teile diese Linie an diesem Punkt in 2 Linien” (z.B. um unterschiedliche Tags zu setzen) lassen sich die beiden entstandenen Segment am betroffenen Punkt ebenfalls nicht voneinander trennen. Versucht man, eins der entstandenen Segmente zu löschen, unterbindet iD dies mit der Fehlermeldung: “Dieses Objekt kann nicht gelöscht werden, weil es Mitglied einer Relation ist.”
Vielleicht kann man das irgendwie austricksen, aber mit den angebotenen Tools geht das so einfach nicht.
Hallo,
hab hier
https://www.openstreetmap.org/note/new#map=19/48.29498/10.97126&layers=N
einen Punkt gesetzt und die Relation in zwei Teile getrennt. Weiter geht es dann nicht, da hast du recht, man kann nur den Punkt löschen und das Teilstück somit entfernen.
Vielleicht spielt auch die Art der Relation bei der Bearbeitung eine Rolle?
Gruß
Danfost
Möglich ist es … vielleicht auch ein bugfix in einem neueren Release von iD? Dein Change war vor 4 Monaten - Anfang Dezember ist mir aufgefallen, dass sich in iD einige Details geändert haben. Bin aber selber auch nicht der große iD-Experte, ich probiere nur auf dem Spielfeld gerne mal alle Optionen durch, um festzustellen, was geht und was nicht. Dabei bin ich dann auch auf die zuvor beschriebenen Sperrfunktionen gestoßen.
Nachtrag: Habe das gerade noch mal probiert und ja, man kann die Sperrfunktion eliminieren, wenn man den Weg an einem Punkt trennt und dann den Punkt selber löscht. Dann verschwindet nicht nur der Punkt, sondern mit ihm auch ein Stück des Weges, ganz ohne Hinweis auf die Relation … super Sache, wenn man mal so richtig aufräumen will … nee, kann ja eigentlich nicht wahr sein! 
OK, danke, habe mich zwischenzeitlich in die umfangreiche Debatte (speziell zu topic 72172) eingelesen. Es geht also gar nicht darum, einen Weg an einem Node zu teilen und dann physisch zu trennen, sondern nur um die Teilung als solche, um z.B. die neu entstandenen Segmente mit unterschiedlichen Tags zu versehen. Ist der Weg Teil einer Relation, wird bereits bei Durchführung dieser harmlosen Aktion von iD u.U. die Relation durchgemischt, wenn ich es richtig verstanden habe, und muss mühselig wieder repariert werden.
Sorry, ich war da auf dem falschen Dampfer bisher … das liegt wohl daran, dass es in OSM Problemzonen gibt, die in einer kommerziellen DB-Programmmierung undenkbar wären. Ist nicht das erste Mal, dass ich angesichts der existierenden Probleme und angesichts des Umstandes, dass man als Einsteiger praktisch unvorbereitet (Doku mit riesigen Lücken) auf die Datenbank losgelassen wird - ja, geradezu angesport wird, nach wenigen Übungsklicks einfach loszulegen - einfach sprachlos bin.
Hallo
und das Problem sieht man in ID nicht da es (meines Wissens) keine Anzeige für die Reihung der Relationsteile gibt. die Relation wird in ID auch nach “Durchmischung” als Duchgängig angezeigt.
Gruß
Danfost
Wenn das tatsächlich genau so passiert (was ich nicht weiß, weil ich es in iD m.W. nicht überprüfen kann), dann ist der Hammer, dass das nicht etwa dann passiert, wenn man anfängt, bewusst an den Relationen herumzupielen, sondern bei einer völlig harmlosen, alltäglichen kleinen Änderung wie z.B. Ergänzen einer Geschwindigkeitsbeschränkung oder Erfassen einer Parkbucht. Wie sagte der Edeka-Gentleman so schön: Supergeil !!
Vielleicht sollte man die Finger doch besser von OSM lassen und sich stattdessen den schönen Künsten widmen …
Trotzdem an dieser Stelle allen Beitragenden ein gutes neues (Mapping)Jahr und ein Dankeschön an alle Altmapper, die sich immer wieder die Zeit nehmen, die unbedarften Neulinge einzuweisen und all das regelmäßig zu reparieren, was andere zuvor zerdeppert haben.
Euch allen ebenfalls ein gute neues (Mapping)Jahr, bleibt’s 'xsund.
Dem ist tatsächlich (gefühlt) so, ohne dass wir Beweise vorgelegt haben, vorlegen konnten. Zumeist äußert sich das in einer falschen Reihenfolge in der Relation für genau die beiden beteiligten Ways (bei split-of way).
Da ich viel mit Qualitätssicherung bei Busrelationen mache PTNA fällt mir das immer mal wieder auf und einzelne Versuche die Ursache zu ermitteln landen meist bei: split-of-way in iD.
In JOSM bekommt man solche Problem auch hin, aber da ist das meist “pebkac” (der/die MapperIn), d.h. hätte sich durch MapperIn vermeiden lassen.
Hallo,
kurz ein OT zum Thema.
Könnt mir jemand zwei Abbiegespuren eintragen. Ich kanns nicht aus oben genannten Gründen 
https://www.openstreetmap.org/note/new#map=17/48.27557/10.99265&layers=N
Danke und Gruß
Danfost
Mach ich mal kurz.
Dankeschön 
Ich zweifle nicht daran … das kann objektiv betrachtet natürlich 2 Gründe haben - entweder der Editor ist den Daten nicht gewachsen oder die Relationen passen nicht in die Struktur der Datenbank. Was ich überhaupt nicht nachvollziehen kann, ist der Umstand, dass dies wohl schon lange bekannt ist und trotzdem noch keine erfolgreiche Abstimmung diesbezüglich stattgefunden hat.
Ich will das hier nicht weiter vertiefen, aber mir ist schon bei den ersten Berührungspunkten mit ÖPV in OSM aufgefallen, dass dieser Spezialbereich sehr komplex und unübersichtlich ist und eigentlich deutlich über die reine Erfassung von Geodaten nach dem Grundsatz “1 reelles Objekt = 1 Datenobjekt in OSM” hinausgeht. In den Routenrelationen werden keine reellen Objekte mehr dargestellt, sondern aus den Objekten zusammengesetzte und mit zusätzlichen Informationen (Reihenfolge) versehene abstrakte Strukturen. Gehört das noch in eine Geodatebank oder eher schon in den Bereich “Ausertung der Geodaten”? Ist aber, wie gesagt, nur so ein Gedanke und nicht dazu vorgesehen, in diesem Topic weiter vertieft zu werden.