Das Schild ist nicht Teil der Relationen, sondern der Node des Schildes verbindet zwei Straßensegmente, die Teile der Relationen sind.
Wenn hier der Node gelöscht wird … s.o.
Wenn hier die beiden Straßensegmente vereint werden und dann ‘maxspeed’ angepasst wird, ändert es auch die Relationen - denn ein Straßensegment verschwindet ja.
Die Frage ist (nach Augenschein), ob sich an den ‘maxspeed’ = ‘50’ was ändert?
Ich kann mir irgendwie nicht vorstellen, dass bei dem nun nicht mehr innerorts-Stück Tempo 100 gilt, wenn dort so viele Einmündungen ins Gewerbegebiet sind.
Ist da nun 70, …? Ab wo, bis wo?
iD, ich weiß, ist nicht das gelde vom Ei, aber für mich hat es bisher gereicht.
Was ist damit gemeint?
Ja, ab dem neuen Ortsausgangsschild ist auf 70 km/h Richtung Deining begrenzt. Aber nicht komplett, sondern bis kurz hinter der nächsten Bushaltestelle/Abzweigung nach Aufhofen.
Deshalb die Frage/Bitte an die Wissenden hier. 
Bitte, sehr gerne. Die neuen Ortsschilder aus dem Gewerbegebiet raus auf den kleinen Zufahrtsstraßen kann ich ja dann evtl. setzen. Wird an der Stelle des Ortausgangsschildes die Straße auch wieder in 2 Teile getrennt oder kommt das einfach direkt auf die Straße? Evtl. kannst Du ja eins setzen, dann dem kann ich mich dann orientieren.
EDIT: Die 70 km/h Beschränkung geht mindestens bis auf Höhe dieses Node, ein klein wenig weiter sogar noch. https://www.openstreetmap.org/way/907082345
Vielen Dank für die Unterstützung.
Wenn du nur "traffic_sign’ = ‘city_linit’ und ‘name’ = ‘Egling’ von Node löscht, hat das auf die restliche Geometrie keinen Einfluss.
Ok, danke, mache ich dann.
Ja, habe ich an dem südlichsten Weg gemacht. Position geschätzt.
Fraglich, ob man für 20m oder weniger die ‘70’ noch mappen sollte. Aber da dort nun mal ein Ortseingangsschild steht, … ja.
Wenn ich das Schild mit iD wie beschrieben aus dem Weg löse, bleibt der Node, der die beiden Straßensegmente verbindet, erhalten. Lediglich der darauf liegende Node des Schildes wird gelöst und kann dann verschoben oder gelöscht werden. Die beiden Straßensegmente müssen dazu nicht verbunden werden.
Ob es dann beim Hochladen noch zu einem Fehler kommt, kann ich ad hoc nicht beurteilen, weil ich den Change nicht durchgeführt habe.
Es gibt gestandene Mapper, die arbeiten schon seit vielen Jahren mit iD und haben damit keine Probleme … ich will mir darüber selber jetzt mal kein Urteil erlauben, da ich mit JOSM noch nicht gearbeitet habe, aber den unterschiedlichen Kommentaren nach zu urteilen, ist das wohl eher so was wie eine Glaubensfrage …
Bei iD ist sehr viel dazugekommen seit das Projekt 2012 gestartet wurde, aber es kann immer noch viel weniger als Josm was auch an der offenen plugin Architektur liegt. Josm konnte 2012 im Grunde schon alles Wesentliche was er auch heute kann, nur dass es jetzt noch viel detaillierter in den Kleinigkeiten optimiert ist.
Grundsätzlich lädt iD jeweils die Daten für den aktuellen Bildschirm, bei josm steuert das der Benutzer.
Josm ist ein Desktop Programm, iD eine webapp im Browser.
Die Richtung geben bei iD die maintainer vor, dabei haben sie bisher in Streitfragen auch gern mal bold gegen den Wikikonsens entschieden, während Josm aus der Community kommt und darauf geachtet wird, auf die diversen Empfindlichkeiten einzugehen.
Das hat alles weniger mit Glauben zu tun, als mit handfesten Unterschieden.
Verstanden, Danke.
Dankeschön.
Danke nochmal, dann kümmere ich mich um den Rest.
Ich wies ja vorsichtshalber schon drauf hin, dass ich mir keine Expertise anmaße … aber grundsätzlich gilt eigentlich immer und überall: es gibt nicht das beste Tool, das beste Programm, das beste Gerät - der Nutzen lässt sich nur an den Erfordernissen messen. Für einfache Arbeiten ist ein einfaches Programm “besser” als die Supersoftware, in den sich der unbedarfte User mühsam einarbeiten muss um dann die meisten Funktionen doch nie zu nutzen - ganz allgemein gesprochen.
Wenn ich mich dann irgendwann erst mal in JOSM eingearbeitet habe, werde ich natürlich das Gegenteil behaupten … 
Ich habe anfangs auch mit einem webgestützten Editor gearbeitet, bin dann auf JOSM umgestiegen, weil der mehr Möglichkeiten bot.
iD war zu Beginn ziemlich fehlererzeugend, inzwischen kann man normale Sachen ganz gut damit erledigen, bei Relationen und aufwendigen Vorhaben würde ich es aber nicht verwenden.
Schon aus Gründen des Umlernens werde ich nicht auf iD umsteigen, dasselbe gilt natürlich umgekehrt auch für Nutzer von iD und weiteren Editoren.
Beim Umstieg ist man im neuen Editor im Vergleich viel langsamer und zwar um so mehr, je routinierter man im vorherigen Editor war.
So geht’s natürlich auch: Node verdoppeln, die Tags am neuen Node belassen, am alten Node löschen und dann den neuen Node löschen (von hinten durch die Brust ins Auge?).
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. 