wollte gerade eine Geschwindigkeitsänderung auf 30 km/h im Verlauf einer Straße eintragen, die ansonsten für 50 km/h zugelassen ist.
Habe dazu 2 Knoten am Beginn und am Ende der Geschwindigkeitsbegrenzung gesetzt, gesplittet, die Höchstgeschwindigkeit geändert und wollte dann hochladen.
Leider ist die Straße eine Hauptstraße und es befinden sich viele Buslinien auf ihr. Daher kam es beim Hochladen zu massig Konflikten. Inwiefern wirkt sich die Änderung, die ich gemacht habe auf die Relationen aus? Der Weg an sich wurde ja nicht geändert, es muss nur langsamer gefahren werden.
Was und wie muss ich die Relationen ändern, damit es beim Hochladen nicht mehr zu Konflikten kommt?
ich nehme mal an, Du nutzest Josm. Darauf beruht meine Vorgehensweise:
der Wegabschnitt, den Du splitten willst, sollte vorher komplett im Editor drin sein. Ansonsten einen kleinen Ausschnitt am Anfang und am Ende des Weges nachladen.
Dann einfach splitten und möglichst zügig wieder hochladen.
Wenn Du dafür nur ein paar Minuten brauchst, sollte es beim nächsten Mal keine Probleme geben.
Nicht nur das Anfang und der Ende des Weges, welcher gesplittet wird sollte da sein, sondern auch die anschließenden Wegstücke, damit JOSM weiß, in welcher Reihenfolge er den neuen Wegabschnitt in der Relation einfügen soll.
Wenn aus einem best. Weg ein Teilstück herausgeschnitten wird, dann hat es doch die Eigenschaften des Mutterobjekts, sollte also Bestandteil der Relation bleiben…oder?
Das hängt sehr vom verwendeten Editor ab.
Bei JOSM ist das der Fall, bei Potlatch weiß ich es nicht.
Übrigens will man nicht bei allen Relationstypen dieses Verhalten.
Wenn man bei Abbiege-Relationen einen from/to-Weg splittet, will man nur einen Weg behalten.
zunächst möchte ich mich für die schnelle Antworten bedanken. Leider funktioniert es nicht so wie oben erklärt.
Ich konnte die Punkte setzen und diese Änderungen hochladen.
Wenn ich einen Punkt splitte (markieren und dann p drücken) und dies hochzuladen probiere bekomme ich immer noch die Warnhinweise bezüglich der Relationen.
Ich benutze JOSM und habe den kompletten Abschnitt, auf dem die zu splittenden Punkte liegen runtergeladen. Vielleicht hat ja jemand von euch Lust, die Punkte zu splitten und den Bereich zwischen den Punkten auf 30 km/h zu setzen.
Wenn ich die Punkte markiere werden in JOSM ziemlich lange Zahlen angezeigt. Für die beiden Punkte von Interesse lauten diese 1816591522 und 1816622683. Ich nehme an, dass es sich dabei um eindeutige Identifier handelt, über die Ihr die Punkte finden könnt.
Ich wäre sehr dankbar, wenn derjenige, der sich dieser Sache annimmt hier kurz beschreiben könnte, was ich hätte machen sollen.
Die kannst Du ignorieren. Es handelt sich nicht, wie Du im ersten Posting schriebst, um Konflikte - die betroffenen Relationen wurden mindestens seit Juni nicht angefaßt -, sondern um antiquiert getaggte Buslinien. Darum brauchst Du Dich aber nicht zu kümmern.
Nein, eine weitere Relation wäre völlig überflüssig. Vor dem Aufspalten bestand der Straßenabschnitt aus einem Weg, der Teil mehrerer Relationen (im wesentlichen Buslinien) war. Beim Aufspalten hat JOSM den einen Weg in drei Wege aufgeteilt und alle drei zu Elementen der betroffenen Relationen gemacht, d.h. in diesen steht nun jeweils nicht mehr ein Weg, sondern drei, welche aber zusammen dieselbe Strecke darstellen. So soll es sein, mehr ist nicht zu tun.
Es ist ja schön und gut, wenn in JOSM das richtig gemacht wird, aber leider ist Potlatch immer noch der meist verwendete Editor. Und bei P1/2 schätze ich, dass die das nicht berücksichtigen. (Merkaartor kenne ich nicht)
Will sagen, solange nicht mindestens die drei großen Editoren JOSM, Potlatch und Merkaartor das richtig machen, solange wird es immer wieder Probleme mit kaputten Relationen geben.
Nur nach Anzahl der Benutzer - nach Änderungssätzen und erst recht nach bearbeiteten Objekten liegt JOSM klar vorn. Ob Potlatch Abbiegebeschränkungen beim Auftrennen von Wegen gesondert behandelt, weiß ich auch nicht. Ansonsten werden mittlerweile (immerhin - lange konnte Potlatch nicht einmal das!) beide Wege in die Relation eingefügt. Hatten wir ja neulich erst: http://forum.openstreetmap.org/viewtopic.php?pid=249166
Die Verhältnisse zwischen Potlatch/JOSM/Merkaartor sind mir bewusst (siehe Editor-Statistik, leider alt).
Es bleibt aber Fakt, dass viele Potlatch-User unwissendlich potentiell Relationen zerstören oder die vorgesehene Ordnung nicht einhalten. Die Größenordnung des Problems ist schlicht nicht zu ignorieren.
PS: Man kann immer noch mit P1 Editieren. Dessen Relationen-Handling kann man getrost vergessen.
JOSM hat eine breiterte Enwicklernbasis als die anderen (je eine Hauptperson).
JOSM kann mit Plugins der persönlichen Arbeitsweise angepasst werden.
JOSM adressiert viele kompliziertere Fälle, die in den anderen Editoren nicht behandelt werden.
Vor allem wenn es um Relationen geht, ist der Relationen-Editor von JOSM eine echte Hilfe, da man damit jede Relation bearbeiten kann und durch Vizualisierung so gut es geht unterstützt wird.
Unbestritten. Ehrlich gesagt ärgere ich mich aber mehr über vermeintlich erfahrene JOSM-Benutzer, die klare Warnungen des Validators ignorieren und ungehemmt Murks hochladen, als über unerfahrene Potlatch-Nutzer, die es einfach nicht besser wissen (können) und von ihrem Editor auch keinerlei Hilfestellung zur Vermeidung von Fehlern erhalten. Zugegebenermaßen vermische ich gerade “Problem Editor” und “Problem Nutzer”.
Benutzt doch fast kein Mensch mehr, wollte ich da einwenden. Dann habe ich lieber noch einmal nachgesehen und die Änderungssätze für 2012 weiter aufgedröselt:
Uralt-Versionen wird es bei allen Offline-Editoren geben.
Das ist aber ein anderes Thema und wird bei Usern, die regelmäßigen etwas beitragen, hoffentlich selten sein.
Falls das nicht zu aufwändig ist, würde mich die Verteilung der Versionen bei JOSM auch interessieren. Kannst das ja zur besseren Lesbarkeit in Hunderter Blöcken zusammenfassen.
Hab’s mit P2 ausprobiert. Ergebnis: Nein, leider nicht. Wenn man einen Weg teilt, hat man plötzlich 4 Objekte in der Abbiege-Relation. Bei P1 wird das dann ja nicht anders sein.