Geplant ist, dass die Neue Version mit diesem Feature im Laufe der nächsten Woche in die Beta kommt. Zurzeit läuft ein interner Alphatest durch besonders Projektinteressierte.
Da das Aufspalten von Wegen recht komplex ist, ist das Fehlerpotenzial groß. Die bereits geschriebenen automatischen Unit Tests können natürlich nur diejenigen Fälle abdecken, die ich selbst bedacht habe.
Daher poste ich das hier, um Feedback einzuholen über mögliche Spezialfälle die ich nicht bedacht habe
Andererseits mit der Bitte an euch, dass falls Euch durch StreetComplete fehlerhaft durchgeführte Aufspaltungen auffallen, dies hier in diesem Thread oder im Issue Tracker auf Github so fix wie möglich zu melden.
Nutzer spaltet einen Weg an einer Node (ok, das ist kein Spezialfall)
Nutzer spaltet einen Weg an einer Stelle zwischen zwei Nodes
Nutzer spaltet einen Weg an mehreren Stellen
Der Weg darf garnicht als Weg gespalten werden weil er als area=yes zu interpretieren ist
Weg ist geschlossen, also erste Node=letzte Node (Nutzer muss mindestens zwei Punkte zum Auftrennen wählen; Wählt er zwei Punkte, kommen am Ende auch nur 2 Wege raus, nicht drei, weil der erste und der letzte wieder miteinander verbunden werden)
Nutzer mit Wurstfingern trifft ungenau und möchte das Setzen seines letzten Spaltpunkt rückgängig machen
Nutzer mit Wurstfingern möchte den Weg an einer Node (z.B. Kreuzung) auftrennen => Größe des Fingers wird in Meter-auf-der-Karte umgerechnet und die Klickposition magnetet sich automatisch innerhalb dieser Distanz an Nodes ran. Kommen mehrere Nodes in Frage, wird der Nutzer darum gebeten, weiter heranzuzoomen
Weg schneidet sich selbst in einem oder mehreren Punkten (z.B. form eines “&”) und wird an einem dieser Schnittpunkte gespalten => D.h. de-facto wird der Weg durch Setzen nur eines Aufspaltpunktes an mehreren Nodes aufgespalten.
Weg schneidet sich selbst in einer Linie und wird dort gespalten. Gleiches wie oben
Weg ist Teil einer Relation
Weg ist Teil einer from-via-to-Relation (z.B. restriction-Relation)
Weg ist Teil mehrerer Relationen unterschiedlicher Art
Nutzer spaltet den Weg offline und lädt es später hoch. Automatische Konfliktauflösung wenn sich der Weg in der Zwischenzeit editiert wurde. Aufspaltung soll nicht mehr durchgeführt werden wenn…
der Weg an einem Ende verkürzt oder verlängert wurde
die Nodes an denen aufgespalten werden soll, verschoben oder gelöscht wurden
zusätzliche Nodes in der unmittelbaren Nähe der Spaltposition hinzugefügt wurden
Unzweifelhaft hat diese Funktion das Potenzial komplexere Strukturen wie Relationen zu zerstören, im Gegensatz zu der bisher vorhandenen Ergänzung vorhandener Infrastruktur mit (m.E. mehr oder minder sinnvollen) Tags und Notes.
Von daher würde ich vorschlagen die betroffenen Änderungssätze (zumindest in der Anfangs/Beta Phase) mit einem verpflichtenden “Review Requested” zu versehen.
Weg ist kompletter Kreisverkehr:
Routen dürfen komplette Kreisverkehre als Repräsentant der benutzten Strecke enthalten. Nach dem Aufteilen gilt diese Ausnahme nicht mehr. Daher müssen dann alle unbenutzten Teile aus allen Routen raus. Das kann zu weiteren Aufteilungen führen.
Weg gehört zu einer PTv2-Route (Diese Eigenschaft ist nicht immer erkennbar):
Die beiden Teile müssen in der richtigen Reihenfolge an dieselbe Stelle wie vorher. (Wenn es keine angrenzenden Nachbarwege gibt oder der Weg in sich geschlossen ist, dann ist die Nutzungsrichtung vorher unbestimmt und danach zufällig. Evtl. Hinweis an User?)
@bus-mt: Nur der Weg der ausgewählt ist, wird aufgetrennt. Also, alles klar.
@Weide: Das sind gute Punkte. Da ist noch Klärungsbedarf:
Wieso nur PTv2? Die aufgespaltenen Wege müssen doch bei jeder (normalen) Relation je nach Ausrichtung der RelationMembers relativ zum Weg richtig herum einsortiert werden? Wie auch immer, das ist, soweit wir uns hier nicht gerade missverstehen, bedacht. Mindestens JOSM und Vespucci machen das auch so (der Teil ist von JOSM abgeguckt). Die Role wird vom original-Way kopiert.
… innerhalb einer Route-Relation. Das war mir neu, und ist in der Tat nicht bedacht. Das wird aber auch in keinem anderen Editor, selbst JOSM nicht, behandelt. Ob es in irgendeiner Software die diese Routen auswertet, bedacht ist, weiß ich nicht, aber es macht das Parsen aufjedenfall wesentlich komplexer.
Der Abschnitt in der Wiki der erwähnt dass man Kreisverkehre auch als kompletten Weg in der Route eintragen kann weil es keinen Konsens darüber gäbe dass diese Praxis falsch ist, wurde 2014 hinzugefügt, leider ohne Referenz woher diese Aussage kommt. Der Abschnitt selber erwähnt ironischerweise den Grund, warum diese Praxis als falsch eingestuft werden sollte, da der echte Verlauf der Route nur fuzzy und mindestens unter Zuhilfename von Metadaten (Ort des Kreisverkehrs → Links oder Rechtsverkehr?) daraus bestimmt werden kann.
Oder, falsch ist vielleicht ein zu hartes Wort. Es ist dann halt ungenau, so wie viele andere Dinge in OpenStreetMap (zeitweise) auch nur ungenau erfasst sind - Route-Member sind nicht sortiert, Addressen nur als Ranges eingetragen, Grenzen nur so ungefähr, Straßenoberflächen nur manchmal erfasst und so weiter und so fort. Sollte ein Software die die Daten verarbeitet diese Daten nun ganz genau haben wollen, hat sie dann eben Pech gehabt, oder sie versucht, die Fakten in solchen Fällen eben anhand Dritt- und Metadaten und anderen Annahmen herzuleiten.
Da unklar ist, woher die Definition “dass es so auch ok ist” kommt und letztlich jede Tagging-Guideline auch von Software Support abhängig ist (siehe zum Beispiel Relation:street, unterstützt auch niemand), würde ich es jetzt erstmal genauso halten wie die anderen OSM-Editoren und den Spezialfall nicht unterstützen, d.h. im schlimmsten Fall ist dann am Ende ein Weg zu viel in der Relation, der Bus dreht also im Kreisverkehr eine Ehrenrunde.
Wenn dieser Spezialfall unterstützt werden soll, sollte man das zusammen mit den Autoren aller Editoren absprechen, damit alle den gleichen Algorithmus verwenden. Aber vorher sollte darüber von denjenigen die diese Alternative vorantreiben wollen, eine Diskussion auf der Tagging-Mailingliste angeregt werden.
Das ist an sich eine gute Idee. Auch insofern gut, weil so nur diejenigen von den tonnenweisen StreetComplete-Änderungssätzen überprüft werden, die tatsächlich eine Aufspaltung enthalten. Bisher ist die App nicht in der Lage, die Tags an einem offenen Changeset zu ändern, aber das sollte machbar sein.
Ich sehe da jedoch einige Probleme:
Das “Review Requested”-Flag wird dann automatisch gesetzt, das könnte zu (unangenehmen, je nach Temperament) Missverständnissen zwischen Reviewern und Nutzern der App führen, da sich beide nicht darüber bewusst sind
Den Reviewern nicht klar ist, was hier reviewt werden muss. Den Reviewern möglicherweise auch nicht klar ist, dass StreetComplete jetzt solche Sachen kann. Nicht jeder der Reviews macht, liest hier mit. review_requested=split_ways gibt es ja nicht, es soll laut Wiki immer yes gesetzt werden.
Damit mache ich die Leute die netterweise regelmäßig Review - eigentlich für Neu-User - machen, implizit zu Betatestern. Das wird einigen sicher übel aufstoßen und das könnte ich auch nachvollziehen. Ich kann mir durchaus vorstellen, dass das Feature oft genutzt wird.
Kannst Du sagen, welche Software dieses Flag am Changeset-Kommentar auswertet? Ich kann dann mal schauen, ob es Möglichkeiten gibt, den Reviewern in der Software mitzuteilen, worum es in dem Review geht (und dass das Flag automatisch gesetzt wurde) und dass es entsprechende Filtermöglichkeiten gibt, für Leute die sich auf das Review von Änderungen von Neu-Nutzern beschränken wollen.
Betreffend Softwaresupport für Kreisverkehre als geschlossener Weg in Route-Relationen muss ich mich korrigieren: JOSM supported es zumindest teilweise, zwar nicht das Aufspalten, aber im Relation-Editor wird es als richtig bzw. verbunden angezeigt. Hmm.
Wollte nur mal fragen, ob du bei diesen Relationen auch an diejenigen gedacht hast, die einen (oder mehrere) Way(s) als “via” enthalten. Wird nämlich ein Way, der die Rolle “via” in der Relation hat, aufgeteilt, so müssen die beiden “neuen” Ways beide als “via” in die Relation. Dürfte aber klar sein.
@Lukas458: Guter Punkt! Also, das Aufspalten des via-Ways wird wie jede andere Aufspaltung behandelt, d.h. der originale Weg wird durch die zwei (oder mehr) neuen Wege ersetzt, inklusive Rolle und in der richtigen Reihenfolge. Macht JOSM auch so.
Den Punkt, dass ein via (daher) aus mehreren Ways bestehen kann, habe ich nicht bedacht. Wobei, diesen Algorithmus habe ich mir von JOSM abgeschaut.
Ich habe es gerade getestet: Tatsächlich macht JOSM die restriction-Relation kaputt, wenn man den to-Weg aufspaltet und der via aus mehreren Wegen besteht. Das gleiche beim Aufspalten von from. Wow, einen Bug in JOSM gefunden, das passiert nicht alle Tage!
Ich habe mal in Pseudo-Code-Englisch niedergeschrieben, wie ein Algorithmus aussehen müsste, der eine Route mit einem aufgespaltenen Kreisverkehr korrekt updatet. Sounds about right?:
if the way is closed, it has the tag junction=roundabout and it is a member of a route relation, then:
1. before the way is split up:
for each route relation the way is a member of:
find the nodes that connect the neighbouring ways to this way, if any
add these nodes to the nodes at which the way is split up
2. when the relations of the way are updated with the splits:
for each route relation the way is a member of:
find the nodes that connect the neighbouring ways to this way, if any
find the splits that connect to these nodes, if any
if splits are found that connect to both neighbouring ways:
select a sublist of splits spanning between the previously found splits
order this sublist according to its neighbours in the relation
replace the way with the sublist of splits
otherwise:
update this relation normally (=replace way with all splits)
* connect means usually first or last node of way 1 equals first or last node of way 2.
However, if the way is a closed roundabout, it may be any node.
Aber ich bin mir noch immer nicht sicher, ob das wirklich unterstützt werden sollte. Unterstützt ja auch sonst kein Editor.
Nach meiner (lokalen) Beobachtung sind SC User meist Neuuser und von daher auch ohne “Review requested” auf meinem lokalen Radar, um ein paar Grußworte loszuwerden und die ersten Changes zu unterstützen. Ich vermute, das andere Mapper die in “ihrem” lokalen Radius ein wenig Qualitätssicherung betreiben das ähnlich machen?
Für Mapper ist die Reihenfolge in allen Arten von großen Relationen wichtig, denn man will den Kram ja irgendwie übersichtlich haben. Daher kann man das auch in Editoren über einen Kamm scheren. Für die Bedeutung der Daten ist das aber anders:
Wenn man in einer PTv1-Route oder z.B. einem Multipolygon zwei Wege vertauscht, dann ist das immer noch OK … nur vielleicht weniger übersichtlich. Die Nutzungsrichtung ergibt sich in PTv1 aus der Rolle: “forward”, “backward” oder “” (d.h. “forward+backward”).
In PTv2-Routen bewirkt aber jede Vertauschung zweier Elemente, dass man eine andere Route hat. Wenn man also wie z.B. der JOSM bei nicht geladenen Relationen die beiden Wegteile in zufälliger Reihenfolge einfügt, dann ist das in praktisch allen anderen Relationen nur etwas weniger übersichtlich – aber in PTv2-Routen ist dann ein Fehler drin der vorher nicht da war. Wir haben tatsächlich den sonderbaren Effekt, dass die meisten Richtungsfehler in PTv2-Routen ausgerechnet mit dem Relationsspezialist JOSM eingebaut werden während der PTv2-ignorante iD diese Fehler nicht macht.
Das ist keine Ehrenrunde. Es ist eine Runde von exakt 360°, die an dem alten Startnode des Kreisverkehrs beginnt und endet. Man hat also – außer und exotischen Fällen – hinterher garantiert zwei unstrittige Fehler in der Route.
Würde ich nicht machen. Gerade bei unvollständigen Routen oder Haltestellen im Kreisverkehr (gefunden in Frankreich, z.Tl. mit mehr als 360° im Kreisverkehr) wird das richtig gemein und ist später nicht pflegeleicht. Dazu kommt, dass Routen oft nicht fehlerfrei sind und man nicht aus kleinen Fehlern einen Berg unsinniger Daten machen will. Man könnte aber den User warnen und bei “Weiter” Relationen nachladen und den Kreisverkehr schonmal splitten. Meist kann der Mapper dann ohne große Probleme weitermachen.
Das mit “it has the tag junction=roundabout” stimmt nur für Kreisverkehre (sofern sie korrekt gemapped sind).
Wendeschleifen an Endhaltestellen von Bussen, haben das in der Regel nicht.
Ein häufiger Fehler ist, dass diese Wendeschleife an der (End-/Anfangs-)Haltestelle eben noch nicht aufgepaltet worden ist.
PTv2 sagt, dass der erste/letzte Node im ersten/letzten Way (gem. Fahrtrichtung, nicht gem. Richtung des ersten/letzten Ways) die Anfangs-/End-Haltestelle sein soll.
D.h. geschlossene Ways sind nicht immer Kreisverkehre und haben daher nicht immer “junction=roundabout”.
Ist ja interessant! Bei mir gibt er aber zumindest dann eine Warnung aus, dass man die eingefügten Relationsmitglieder überprüfen sollte. (Gut, ist am Ende auch nur ein Hinweis, mehr nicht). Manchmal klappt es bei mir auch - eine Relation mit mehreren via-Ways, to wird aufgespalten - nur das eine richtige “to” wird oder bleibt eingefügt.
Beim “from” Aufspalten klappt es allerdings auch bei mir nicht.
Allerdings sollten in sich geschlossene Wege, die keine Kreisverkehre sind, in PTv2 dringend vermieden werden, denn in dem Fall kann die Richtungsermittlung nicht funktionieren.
Nun, das geht hier um StreetComplete, nicht um JOSM. Relationen werden selbstverständlich beim Splitten nachgeladen, das ist beim Splitten immer notwendig. Allerdings kann kann man nicht davon ausgehen, dass die Nutzer dieser App irgendwas von Relationen usw. wissen. Und irgendwie manuell die Relationen bearbeiten, können sie schon garnicht mit StreetComplete. So können sie mit irgendwelchen Warnungen selbstverständlich auch nichts anfangen.
Wenn ein automatischer Algorithmus nicht in Frage kommt, weil zu komplex bzw. zu fuzzy, dann gibt es eben nur diese zwei Möglichkeiten:
nichts ändern, StreetComplete erzeugt im Zweifelsfall fehlerhafte Route-Relationen beim Aufspalten von geschlossenen Kreisverkehren
StreetComplete bietet Nutzern für geschlossene Kreisverkehre garnicht an, den Weg aufzuspalten. Das gilt dann aber für alle Kreisverkehre, nicht nur für solche, die Teil einer Route-Relation sind, denn die App fragt erst unmittelbar beim Upload an der API ab, ob der aufzuspaltende Weg Teil einer Relation ist
Bei JOSM ist das Problem… dass zum richtigen aufteilen eines Weges müssen die anschliessenden Wege am beginn und ende des Weges geladen sein, was nicht immer der Fall ist (Manchmal fehlen sogar die Relationen). Daher sollte man bevor man einen Weg aufteilt den Kartenausschnitt im JOSM am Anfang und Ende des Weges herunterladen, damit ein richtes einordnen überhaupt möglich wird. Sonst sind die chance 50 zu 50 Wenn diese Wege da sind kann man diese zwei neuen Wegteile zu den davor- bzw. danachliegenden RelationsMembers prüfen.
(Lösen könnte man das nur das man automatisch bevor JOSM ein Weg aufteilt diese Wege/Relationen an den Endnodes nachläd und dann die Teilung dürchführt. “Sicheres Teilen” )
Wenn diese Wege da sind kann man diese zwei neuen Wegteile zu den davor- bzw. danachliegenden RelationsMembers prüfen.