Kreisverkehr als Multipolygon?

Ja, die Wege müssen alle durchgängig sein (d.h. Endnode des einen Ways == Endnode des nächsten Ways). Einzige Ausnahme dabei sind Flächen (lies: geschlossene Ways, egal ob Kreisverkehr, Wendefläche oder sonstwas), bei denen sinngemäss jeder Node als Endnode angesehen wird.

Ich meine eher das Gegenteil: Wenn es ein klassischer Kreisverkehr ist, soll man den auch als geschlossenen Ring anlegen, auch wenn der Durchmesser ungewöhnlich groß ist.

Ich hoffe, die lesen im Forum mit.

Gerade damit scheint es ja beim Garmin bei segmentierten roundabouts Probleme zu geben. Das hab ich mit mein PS gemeint, nicht einen Routenplaner.

In diesem speziellen Fall interpretiere ich die Richtungspfeile auf dem Luftbild so, dass im zweispurigen Bereich die Spuren nicht gewechselt werden dürfen. Wenn dem so ist würde ich die Spuren teilen, indem ich die nördliche Ausfahrt an die südliche Einfahrt anknüpfe. Die östliche Einfahrt würden diese Spur dann kreuzen und die Ausfaht von der äußeren Spur wegführen. Denn innern Ring bräuchte man dann nicht mehr teilen und könnte ihn als geschlossen Ring als Kreisverkehr taggen

Widerspruch. Die Motorway Zufahrten in UK haben oft einen großen Kreisel als Verteiler und der muß segmentiert werden weil mindestens zwei Brücken im Weg des Kreisels vorkommen. Trotz der Größe sind es definitiv Kreisverkehre.

Baßtölpel

Sehe ich auch so!

Das halte ich für falsch.
Wird sollten schon die Realität abbilden.
In die Route sollte nur der Teil des Kreisverkehrs aufgenommen werden, welcher auch tatsächlich durchfahren wird.
Das würde z.B. auch bedeuten, dass jemand, der nur Bus-Routen auf einer Karte darstellen möchte, vor der Darstellung auch noch die Routen analysieren muss.
Wenn eine Haltestelle so am Kreisverkehr liegt, dass dieser 1,5x durchfahren wird, dann ist das mit deinen “Verknüpfungspunkten” auch nicht mehr lösbar, dann müsste man zusätzlich noch die Lage der Haltestelle analysieren.

Ich halte diese im November 2012 vorgenommene Änderung für diskussionswürdig:

http://wiki.openstreetmap.org/w/index.php?title=DE%3ATag%3Ajunction%3Droundabout&diff=833659&oldid=832317
Das wurde jahrelang anders praktiziert und dann kommt jemand daher und ändert das ohne Diskussion?
Deshalb bin ich dafür, diesen Teil der Änderung im Wiki rückgängig zu machen, bis es dazu evtl. einen Konsens gibt.

Genau, es gibt verschiedene gute Gründe, einen Kreisverkehr zu segmentieren.
Wie z.B. Brücken, verschiedene Oberflächen, nicht baulich getrennte Radwege, welche nicht komplett um den Kreisverkehr herumführen oder eben Routen…
Deshalb halte ich diesen Satz im Wiki für nicht gerade optimal:

Besser wäre, wie auch im englischen Wiki, auch die Mehrzahl zu erwähnen, z.B. “Der/Die OSM-Weg/e”.

Da es vorkommen kann, dass eine Kreisverkehr segmentiert werden muss, sollte ein Navigationsprogramm auch immer eine Analyse des Kreisverkehrs vornehmen (den Kreisverkehr zusammen setzen und dann die Ausfahrten zu zählen ist auch nicht so schwer).

Gruß,
Mondschein

ich habe bisher auch immer den ganzen Kreisverkehr in Relationen aller Art aufgenommen. Zu- und Abfahrt vom Kreisverkehr sind durch die benachbarten Relationsmitglieder gegeben, Fahrtrichtung auch. Ich sehe in einer Route keinen Grund für eine Trennung.

Du schreibst, dass jemand der nur Busrouten darstellen möchte, nicht gezwungen werden sollte, die Wegführung am Kreisverkehr vorher zu analysieren. Vom Navi verlangst Du aber genau das?

Richtig.
Eine reine Darstellung sollte nicht auch noch Routen analysieren müssen, sondern nur die Wege entsprechend markieren.

Richtig.
Denn ein Navi muss das zwangsläufig können, da es immer notwendig sein wird, Kreisverkehre zu segmentieren (unabhängig von Routen, siehe oben).
Aber warum sollte man das einem Renderer jetzt auch noch schwer machen, wenn es sich denn vermeiden lässt?
Nur weil es das Navi schon schwer hat?
Das schafft nur zusätzliche Komplexität in der Auswertung, welche sich vermeiden lässt.

Kurz:
Nur durchfahrene Segmente des Kreisverkehrs in Routen aufzunehmen schafft weder beim Navi, noch beim Renderer mehr Komplexität.
Immer den gesamten Kreisverkehr in Routen aufzunehmen, beseitigt beim Navi keine Komplexität, fügt für den Renderer aber neue hinzu.

Gruß,
Mondschein

Hallo miteinander!

Ich möchte dieses Thema aus gegebenem Anlass wieder aufwärmen. Ich habe in Spanien mehrfach Kreisverkehre gesehen, die teilweise Radspuren hatten, teilweise nicht, dann wieder mit einer Hälfte als Brücke, usw. Dass es notwendig sein kann, einen Kreisverkehr aufzuteilen halte ich, auch aufgrund der vorherigen postings, für erwiesen und ich könnte noch weitere theoretische Beispiele bringen, warum dem so sein sollte.

Für mich stellt sich jetzt nur die Frage, ob es jetzt „weniger schlecht“ ist, die einzelnen Segmente als junction=roundabout zu taggen, oder eine Relation daraus zu machen. Persönlich fände ich eine Relation logischer, weil es mehrere Einzelsegmente zu einem großen ganzen verbindet. Gesehen habe ich das allerdings bisher nicht und ich müsste mal schauen, ob die Router damit auch klarkommen. Auf jeden Fall bin ich dafür, den Satz, der nur im Deutschen Wiki steht zu streichen, da es definitiv eine Notwendigkeit gibt, Kreisverkehre zu zerlegen, die Frage ist aus meiner Sicht nur, wie man es am besten löst. Ist vielleicht das Forum der falsche Ort, dies zu diskutieren oder warum war hier auf einmal Schluss?

  • Nadjita

Multipolygone sind für flächenhafte Gebilde da, nicht zum Zusammenfassen von Wegen. Eine MP-Relation aus den Kreisverkehr-Segmenten würde also die gesamte umschlossene Fläche (halbe Fahrbahn plus Mittelinsel) zum Kreisverkehr erklären. Das ist völliger Unsinn. Zum Zusammenfassen von Straßen werden in anderem Zusammenhang type=route-Relationen genutzt (was ich zum Zusammenfassen eines Kreisverkehrs jedoch keinesfalls empfehlen möchte). junction=roundabout an die Segmente und beim Zerlegen eventuelle Routenrelationen anpassen, fertig.
Gerade weil Multipolygone nichts mit eindimensionalen Wegen (unsere routingtaugliche Approximation für Straßen) zu tun haben, wird kein Router eine MP-Relation auswerten. Zurecht.