StreetComplete nutzt übrigens den gleichen Algorithmus wie JOSM. Wenn JOSM beim Aufspalten eine kaputte (Route-)relation hinterlässt, dann SC wohl auch.
Der Code ist hier, wer das gerne mal durchlesen möchte was berücksichtigt wird:
1 Like
aber Radrouten, diese ganzen Fahrradknotenpunktrouten… die führen äußerst gerne darüber, oder beginnen/enden da…
In der Regel repariere ich solche Dinger, indem ich alles Segmente wieder zusammenführe und bei allen(!) beteiligten Relationen die entsprechenden Teile regelkonform manuell wieder zusammenbaue, incl. Rollen…
Nochmal: bei Standardkreisverkehren ist ein Aufsplitten völlig unnötig. Es verkompliziert nur die Daten.
Sven
1 Like
Mir ist das nicht egal, besonders bei scheinbar unlogischen Fahrtrouten. Beispielsweise biegen manche Busse statt rechts, links ab, obwohl die Bushaltestelle schon 50 m rechts zu sehen ist und PKW auch rechts abbiegen. Das liegt dann oft daran, dass die Busse auf Grund des Winkels dort nicht abbiegen dürfen (nicht ausgeschildert, aber so von der Stadt angeordnet, Sondergenehmigung) und so fahren sie einen größeren Umweg (Schleife). Auch bei landschaftlich oder touristisch interessanten Gebieten finde ich es wichtig zu wissen, wo der Bus genau fährt.
Das funktioniert in vielen Fällen nicht.
Ist es nicht so, dass Thunderforest Transport diese Routenrelationen für die Darstellung der Buslinien braucht? 
Kann nur zustimmen. Das der
- Straßenverlauf nur Optional sein sollte.
- eventuell weiter Rollen
- Überlegungen zu Automatische Routing… z.B: mit Via-Punkte wenn das Routing das nicht ganz richtig macht.
Außerdem sollte man zu jeder Route auch die Möglichkeit haben dafür ein GPX… kml … garmin… download Möglichkeit haben. Damit das nicht nur gut zum Rendern ist… weil das ist dass was man mit Ptv2 Routen gut kann… sie wie Ptv1 zu rendern.
Gruß Miche
Yes, SC seems to keep all the ways in the relation correctly:
- before StreetComplete: overpass turbo
- after StreetComplete: overpass turbo
One can visually check that they are technically the same and contain exact the same route.
If one click on Export / JOSM for each of them, it can be seen that in second overpass the relation on that roundabout is comprised of two ways (while in the first overpass it is only one way).
However, wiki seems to indicate that only two usages are to be used in such cases of roundabouts in relations.
Either:
- The whole roundabout is included in the route relation.
while this is technically wrong (as bus would not in reality make one and a half circle to pass that roundabout as the visualization shows), it seems to be allowed and used by some mappers (likely because it is simpler to do). It may also be the case that data consumers have a special kludge to handle that situation (e.g. treat that whole roundabout way as an one simple node?),
or
- The roundabout is split and the part used by the bus route is included in the route relation.
this is the only technically correct way to indicate exactly which part of the route the bus will actually take (and should IMHO always be used when adding roundabouts to the relations).
If the latter (technically fully correct) way of adding a roundabout to the route is used, after splitting the roundabout will always remain correct as it was. (that is fundamental definition of relations, that it does not matter of how many small parts it is comprised if they make the exact same geometry in the exact same order).
However if former (technically incorrect / oversimplified) way of adding a roundabout to the route is used, any splitting of the roundabout will expose that underlying wrongness even more (as less data consumers are likely to have kludge for that situation too). Note that anything that splits the roundabout in this case will always “break” the relations, as the tools can’t know that the original mapper “lied” when they created the relation. This is AFAICT what seems to have happened in this changeset.
TL;DR - it would IMHO be best, when adding roundabouts to the relations, to always split the roundabouts and add only correct (actually used) part of them in the relation. Adding whole roundabound in relation (even when only part of roundabout is used by that route) is asking for trouble.
1 Like
@westnordost While not a solution, perhaps a StreetComplete-specific workaround might be possible to avoiding SC triggering this issue in the future - i.e. maybe splitting way functionality could be disabled on ways tagged with junction=roundabout?
Then little less data would be collected by the StreetComplete (e.g. roundabouts that only have partial sidewalks would not get sidewalk information), but it would avoid those kind of breakages. I don’t know how easy/possible it is from its software architecture point of view, though.
1 Like
Wenn “$Transportmap” den Linienverlauf “zeichnen” soll, so muss er meiner Meinung nach auch in den Daten enthalten sein. @miche101 hat mal einen Ansatz ausprobiert, wo nur die Haltestelle und einige “Stützpunkte” (normale Nodes als “via” in der Route) gemapped wurden. Der Ansatz ist realisierbar, wird aber nicht funktionieren
- “$Transportmap” muss für jeden Tile in jeder Zoomstufe ermitteln können, welche Routen hier zu “zeichnen” sind.
Darunter können Flixbusrouten sein, die die A 99 im Osten Münchens nutzen
N409 von Hamburg nach Bologna - hält nicht in München.
N538 von Prag nach Florenz - hält nicht in München.
Wie soll so ein armer “$Transportmap”-Renderer beim neu rendern (Scheune ist verändert worden) entscheiden, ob hier und welche Routen hier auf der Autobahn angezeigt werden sollen, ohne alle Routen auf dem Kontinent / der Landmasse zu berechnen?
Wie soll so ein armer “$Transportmap”-Renderer merken, dass die Tiles hier neu gerendert werden müssen, wenn die Busse nicht mehr über die A 99 sondern weiter westlich, mit Umweg, über die A 7 bei Ulm fahren. Die Tiles bei Ulm müssten dann ebenfalls neu gerendert werden.
Busrouten mittels Haltestellen und “Stützpunkte” zu definieren ist machbar, aber das Rendern - gerade das Updaten - von Tiles bekommt man nicht mehr in den Griff - ohne riesigen Aufwand.
Fazit: Ohne Routenrelationen die die Ways enthalten geht sowas nicht (mit vertretbarem Aufwand).
Also: $Editor muss beim split-ofway / split-of-roundabout die korrekte Reihenfolge der Elemente in allen Routenrelationen beibehalten/herstellen können. Das ist eine lokal begrenzte Aufgabe, die nur die direkt angrenzenden Ways mit berücksichtigen muss. Theorie: ich haben keinen fertige Lösung parat.
Beobachtung: Wenn ich mir die Analysen von PTNA für die mittlerweile 252 ‘network’ anschaue, treffe ich immer wieder auf Dinge wie hier, wo die beiden Ways nur vertauscht werden müssen. Eine genauere Analyse zeigte dann zumeist, dass ein split-of-way gemacht wurde (hier u.U. nicht der Fall).
“Die $Editoren beherrschen den split-of-way, split-of-roundabout” kann ich nicht unterschreiben.
Yes, good idea, but that’s already the case. Or to be more specific, for any closed way.
@westnordost das sollte so sein, aber offensichtlich ist dies eben nicht der Fall. Sonst wäre dies gar nicht passiert!
https://pewu.github.io/osm-history/#/way/28446137
Der Kreisverkehr war zwar schon einmal gesplittet, aber seit Version 10 (seit 2016) ein geschlossener way mit junction=roundabout. Bis vor 2 Wochen, als ich dies am 29.10.23 durch Version 19 beim Bearbeiten mit SC aufgesplittet und damit die Relation geschrottet habe. Also schau bitte noch mal in Deinen Code, wo der Fehler liegt und wie bei diesem Spezialfall eines Kreisverkehres mit geschlossenenm way und darüber verlaufenden Relationen, wie er sehr gut und zutreffend von @Matija_Nalis beschrieben wurde, ein Splitten wirksam verhindert werden kann.
Ich nehme ganz stark an, dass bisher kein Editor/Algorithmus in einem solchen Fall vollautomatisch die Routen fehlerfrei neu sortieren und richtig zusammenfügen kann. Das würde nämlich erfordern, dass der Editior vollautomatisch weitere Aufsplittungen vornehmen muss, und das unter Umständen obendrein für verschiedene Routenrelationen und -richtungen.
Trotz
wird der entscheidende Unterschied sein: bei der Bearbeitung mit JOSM sitzt ein Mensch vor dem Bildschirm und wird ziemlich sicher eine Fehlermeldung über eine defekte Relation angezeigt bekommen und diese vor dem Hochladen beheben.
1 Like
Ich fragte Dich zu Deiner Meinung zur Verhinderung des Aufsplittens, wenn Relationen über geschlossene Kreisverkehre laufen, nicht zu Busrelationen im Allgemeinen.
@all: wenn Ihr Busrelationen mit oder ohne ways im Allgmeinen diskutieren wollt, macht bitte einen neuen Topic auf, das ist in diesem Thema offtopic und lenkt vom eigentlichen Problem ab. Danke
Oh, du hast recht. Ic habe diesen Code-Abschnitt falsch gelesen:
Ein Element gilt als aufspaltbar, wenn es ein Weg ist und er entweder nicht geschlossen ist oder nicht als Fläche interpretiert werden soll (z.B. building=yes)
@mnalis Kannst du vielleicht ein Ticket dafür aufmachen? Du hast die Problematik weiter oben ja schon beschrieben, den Text kannst du fast 1:1 übernehmen. Ich hätte gerne ein Ticket dafür, weil ich mich dunkel erinnere, dass dieser Fall schonmal im Issue Tracker diskutiert wurde. Bevor man die Implementation also wie vorgeschlagen ändert, würde ich gern nachvollziehen, warum es damals so implementiert wurde wie es implementiert wurde.
Danke für das nochmalige Nachlesen.
I’ve now opened a ticket at: Disallow splitting a way in case of junction=roundabout · Issue #5372 · streetcomplete/StreetComplete · GitHub
Natürlich gibt es dabei auch Probleme… aber die gibt es bei Ptv2 auch… wenn nicht mehr…
Wobei ich sagen muss Ptv2 hinlässt mehr schaden… die Zerstückelung von Wegen sehe ich als größte Plage… die nachhaltig und für lange Zeit für verschiedenste Probleme sorgen wird.
Die Wartung/Nachhalten, Reparatur usw. aller Routen sind jetzt schon ein massives Problem… Viele kaputte Relationen, überholte Relationen… Wanderrouten die über Straßen führen obwohl daneben schon Gehwege gezeichnet sind. usw.
Die versprochenen Vorteile von Ptv2 sind meiner Ansicht nie eingetreten …
Für mich ist Ptv2 gescheitert… zumindest bei Bus-Routen weil es nicht genug Mapper gibt die es bräuchte um da was brauchbares und aktuelles dabei rauskäme.
Der Arbeitsaufwand müsste sich erheblich minimieren… um aktueller und brauchbarer zu werden. Da wäre Auto Routing schon ein großer Schritt in die Richtung.
Gruß Miche
2 Likes
Also sollte es dahingehend ein Proposal geben (=Straßen-Wege nicht mehr Teil von Route-Relationen), hast du meine Stimme.
Allerdings denke ich, dass dieses Proposal höchstens so weit gehen könnte, dieses als ausdrücklich optional zu betiteln. Auch zweifle ich zurzeit, ob ein solches Proposal eine eindeutige Mehrheit erreichen könnte, solange nicht gleichzeitig eine einfache und klare Lösung aufgezeigt wird, wie Datennutzer die Route stattdessen einfach visualisieren können sollen.
… Und ich denke, das ist nicht möglich. Zumindest solange nicht, wie es nicht so eine Art OvertureMaps für OpenStreetMap gibt, also ein allgemein von Datennutzern gemeinsam genutzter Preprocessing-Step, der (Mapper-freundliche) Datenstrukturen in datennutzerfreundliche umwandelt. In dem Fall also, die Routen der Busse per Router-Applikation (und möglicher Stützpunkte) automatisch hinzuzufügen.
Kurz: scheint in weiter ferne zu liegen.
Ein anderer Ansatz das Problem der ständig auseinanderbrechenden Route-Relationen in den Griff zu bekommen der mir bei @flohoff 's lightning talk zu Routing-QA gestern auf der State of the Map Europe gekommen ist und mir erreichbarer scheint:
Populäre Editor-Software (JOSM, iD) könnte bei Download der Daten je Route-Relation jeweils checken, ob diese valide ist. Vor Upload wird dann für jede Route-Relation die bei Download valide war, gecheckt, ob sie jetzt noch immer valide ist. Wenn sie jetzt nicht mehr valide ist, wird das als Fehler (statt als Warning) im Validation-Step vor dem Upload gewertet.
(JOSM überprüft schon bei Upload ob Route relations valide sind - zumindest für den Teil der Route Relation in der bounding box der heruntergeladenen Daten - , oder? Ich bin mir gerade nicht sicher, wie weit dieser Check geht.)
Das weiß ich auch nicht, in wie fern JOSM nur teilweise geladenen Relationen auf Validität prüft - beim Hochladen.
Daher habe ich es mit zu Gewohnheit gemacht, alle Relationen komplett zu laden, bevor ich den Validator manuell anwerfe. Dieses Verfahren ist aber so für die Allgemeinheit nicht zumutbar.
Ich glaube auch nicht dran das ein Proposal Erfolg hätte. Glaub da muss erst alles kaputt gehen bevor man da gewillt ist daran was zu ändern.
Dazu müsste ich selbst mal anfangen die Sache sein zu lassen 
. Glaub dieses Jahr Fahrplanwechsel mach ich nicht mehr mit… ca. 500 Relationen kann sich gerne wer anders anschauen.
Gruß Miche
So eine Funktion sehe ich eher als Teil eines Editors. Es gibt schon eine Routing-Erweiterung für JOSM, die eigentlich genau das kann, aber leider bisher ohne Unterstützung für Relationen:
JOSM/Plugins/Routing - OpenStreetMap Wiki
1 Like
Ab dem nächsten Release wird StreetComplete bei Kreisverkehren die nur aus einem geschlossenen Weg bestehen die Option fehlen, den Weg aufzuspalten. Nutzer müssen in dem Fall eine Notiz hinterlassen.
Es stellt sich raus, dass das von Anfang an auch so geplant und implementiert wurde, dieser Check ist aber bei einem späteren Refactor verlorengegangen. Siehe Wege trennen mit StreetComplete - #23 by westnordost
4 Likes