Baulich getrennte Straßen und 4-spurige Straßen innerhalb von Städten

Hi,

da gabs schonmal den divider-Tag:

http://wiki.openstreetmap.org/wiki/Proposed_features/Divider
http://wiki.openstreetmap.org/wiki/Proposed_features/Divided_road

ist inzwischen abgelehnt, was ja nix heissen muss. keine ahnung ob es einen verbesserten neuen Vorschlag gibt.

Gruß zorque

Das ist deine Meinung. Aber wenn man ein Tag durchgezogene_mittellinie=yes einfuehrt, dann werden bestimmt viele Leute daraus auch schliessen, dass da natuerlich das Linksabbiegen verboten ist (dazu muesste man ja die durchgezogenen Linie ueberfahren) und somit entsprechend Abbiegerelationen implizit mit definiert werden.

Diese Unklarheit wuerde man vermeiden, wenn man stattdessen ein wenden_verboten=yes Tag einfuehren wuerde. Das sagt ja nichts darueber aus, wieso das so ist, sondern beschreibt nur die Wirkung.

Gruss
Torsten

Genau, das ist meine Meinung. Wenn dafür aber ein Tag eingeführt werden sollte, ist es in meinen Augen sinnvoll wenden_verboten=yes zu nehmen. Oder aber KLAR zu definieren dass das Tag nichts impliziert. Ich halte nicht viel von Implizierungen. Man weiß nie, ob der Mapper dies als impliziert angenommen hat, oder ob es tatsächich nicht vorhanden ist.

Das Problem gibt es ja bereits bei highway=residetial. Wenn nun kein footway=* getaggt ist, besteht die Möglichkeit, dass auf beiden Seiten ein Fußweg ist oder aber das keiner vorhanden ist.

Ich finde den bisherigen Ansatz im Grunde genommen richtig. Meiner Meinung nach mappen wir in erster Linie nicht Straßen als Bauwerke, sondern ein abstraktes Wegenetz. In diesem Sinne sind zwei voneinander getrennte Richtungsfahrbahnen für mich tatsächlich zwei Wege. Zwei nebeneinander verlaufende Wege sollten bei dieser Betrachtung nur dann zu einem zusammengefaßt werden, wenn man tatsächlich jederzeit von einem auf den anderen wechseln kann. Eine ähnliche Diskussion gab und gibt es ja auch bei straßenbegleitenden Fahrradwegen, die ja auch genau dann separat gemappt werden sollten, wenn man nicht von der Straße auf den Radweg wechseln kann. Ich finde, daß beide Fragen miteinander verwandt sind und auch konsistent gelöst werden sollten. Insofern ist die Tendenz, zwei getrennte Richtungsfahrbahnen zu einem Weg zusammenzufassen das genaue Gegenteil der auch anzutreffenden Tendenz, direkt an der Straße liegende Radwege separat zu mappen. Beides halte ich nicht für sinnvoll.

Ich denke, daß ein wesentlicher Teil des Problems wie so oft von der Darstellung im Renderer herrührt. Der bekommt für eine vernünftige Darstellung einfach zu wenig Informationen, hier speziell die Information, daß beide Richtungsfahrbahnen zu einer Straße gehören. Die eigentlich richtige Lösung wäre, das historisch gewachsene Datenmodell einmal grundsätzlich in Richtung Objektorientierung zu überarbeiten. Unter anderem müßte dabei dann z.B. eine Straße als ein Objekt definiert werden, daß ein oder mehrere Elemente (=Wege) hat (z.B. lediglich eine Fahrbahn, oder 2 getrennte Fahrbahnen + 2 baulich getrennte Radwege, usw.), dazu dann noch diverse Attribute. Ich fürchte aber, das ist angesichts der komplizierten und zähen Entscheidungsprozesse kaum möglich. Als workaround bietet sich an, Straßen als Relationen zwischen einzelnen Wegen zu mappen, ähnlich wie Routen, aber acuh das scheint mir kurzfristig kaum durchsetzbar zu sein…

Grüße,
Philipp

Hi,

Zustimmung. Wenn das Tag einen Einfluss auf Kreuzungen und Einmündungen hätte, würde das dazu führen, dass 10 m vor und nach dem Kreuzungsknoten der way 2 x gesplittet wird, wenn man doch abbiegen darf. Und es ist m. E. nicht unüblich, dass an Kreuzungen/Einmündungen kurz eine gestrichelte Linie kommt - v. a. auf zweispurigen Straßen.

Implizierungen sind nichts Schlechtes. Sie müssen nur ordentlich definiert werden und dürfen sich mittelfristig nicht ändern. Wenn sie sich ändern, dann muss es eine festgelegte Routine geben, wie die Daten aktualisiert werden. Das könnte z. B. ein Bot machen, nachdem ein Proposal akzeptiert wurde. vehicle=* ist auch eine Implizierung, die wenigsten werden sich daran stören und es ist auch recht sauber im Wiki dokumentiert. Problematisch sind Tags, die nie klar definiert wurden, wie eben footway und cycleway, und wo sich auch niemand wagt, es mal festzulegen. Da kommt man dann an dem Punkt an, dass es weder falsch noch richtig, sondern einfach schwammig und Ansichtssache ist.

Gruß vom Plasmon, das keine Diskussion über foot- und cycleways an dieser Stelle wünscht :sunglasses:

Ach komm, so ne gaaaanz kleine Diskussion?

Dafür gibt es zz. schon folgenden Thread: http://forum.openstreetmap.org/viewtopic.php?id=5181. Abschaffung von Potlatch + cycleway + footway in einem :wink:

Ich hätt da ne andere Idee: Wir schaffen sowohl potlatch, jOSM als auch Merkaartor ab. Dann entfallen diese Diskussionen gleich mit :smiley:

Tun wir das? Wer hat das festgelegt?

OSM ist (leider) ein extrem offenes Projekt, wo jeder machen kann, was er will. Und die einen wollen vielleicht eine Strassenkarte zur Navigation haben, waehrend anderen vielleicht eine topographische Karte wichtiger ist. Und letztere sind an der Strasse halt eher als Bauwerk interessiert.

Ausserdem soll das OSM-Datenmodell ja weltweit einheitlich sein. Wenn man hier in den gut erfassten Staedten nun damit anfaengt, weisse Linien zu taggen, dann kann man da in anderen Teilen der Welt sicherlich nur verwundert den Kopf schuetteln.

Das OSM-Strassen-Daten-Modell muss also deutlich mehr Anforderungen erfuellen. Es muss

  • einfach und robust sein
  • verschiedenen Interessen gerecht werden
  • im Detailgrad skalierbar sein
    Und wenn es nach mir ginge, dann sollte es auch noch
  • eindeutig und
  • konsistent sein.

Wenn man irgendwelche Erweiterungen oder Aenderung plant, muss man neben obigen Anforderungen auch immer noch im Auge behalten, wie sich das mit dem bisher Ueblichen vertraegt. Denn per Beschluss aendern ja nicht alle Editoren und Mapper von einen Moment auf den anderen ihr Verhalten, sondern jede Entwicklung ist bei OSM ja ein schleichender Prozess.

Gruss
Torsten

Irgendwie begreife ich Euer Problem nicht. Klärt mich mal auf.

Wenn ich eine durchgezogene Linie bei OSM mappe, dann bedeutet sie genau dasselbe, wie in der Realität: Sie darf vom rollenden Verkehr nicht überwunden werden. Der Mapper malt genau da eine Linie in OSM, wo er sie auf der Straße vorfindet. Er hat keine Möglichkeit, da etwas hinein zu implizieren. Wo seht ihr denn diese Implikation, von der ihr sprecht?

Genz im Gegenteil zu eurer Aussage ist also die gemappte Mittellinie die beste 1:1 Abbildung, die man sich denken kann. Im Unterschied dazu sind gerade “Wenden verboten” und Abbiegerelationen, die das Linksabbiegen verbieten, Folgerungen also Implikationen aus der durchgezogenen Linie. Ganz abgesehen davon kann die durchgezogene Linie in OSM besser dargestellt und somit in hohen Auflösungen durchweg sichtbar bleiben. Sie lässt sich zudem besser unterbringen als ein Haufen Abbiegerelationen-Schilder. Im Falle von den Unmengen von Hauseinfahrten, die man hier fast flächendeckend findet, müsste ersatzweise an jeder eine Abbiegerelation postiert werden. Die Linie ist zudem suggestiver. Daher nimmt man in der Realität auch lieber als eine Anhäufung von “geradeaus und rechts” Schilder. Analog dazu wären die vielen Abbiegerelationen an den Hauseinfahrten ebenfalls weniger suggestiv und übersichtlich. Gerade an Hauptverkehrsstraßen wird die durchgehende Linie in der Realität dazu genutzt, um das Linksabbiegen in Haus- bzw Grundstückseinfahrten zu verhindern.

Last but not least “wirkt” die durchgezogene Linie in OSM auch dann, wenn die abbiegenden Straßen und Einfahrten noch gar nicht gemappt sind. Für jeden neu angefügten Linksabbieger wirkt sie sofort. Der eintragende User muss nichts von der durchgezogenen Linie wissen. Er braucht auch nicht zu wissen, dass er Abbiegerelationen einfügen muss. Er braucht auch nicht zu wissen, dass es sie gibt und wie man sie nutzt. Er braucht auch nicht zu wissen, dass er für das detaillierte Mapping des neuen Linksabbieger auf durchgezogene Linie prüfen muss. Die durchgezogene Linie - eingetragen von einem einzelnen Mapper - wirkt auch alle bisherigen und zukünftig eingetragenen linksabbiegenden Straße und Hauseinfahrten, genau wie in der Realität.

Die durchgezogene Linie in OSM ist also 1:1, übersichtlich, einfach im Renderer darstellbar und wirkt auf bisherige und zukünftige Linksabbieger Einträge. In der Gesamtwürdigung sehe ich nur positive Eigenschaften. Bitte klärt mich auf, was nun eigentlich dagegen spricht und wo ich gegebenenfalls Denkfehler mache.

Hallo
Gerade bei den Einmündungen liegt ja das Problem. Wenn eine durchgezogene Linie als vorhanden gemappt ist und jemand einfach nur eine neue Straße mit der bereits gemappten verbindet, darf man von einer Seite nicht hineinfahren. Dem ist aber in den meisten Fällen nicht so. Normalerweise wird die durchgezogene Linie dann aufgehoben, sodass man zwar von der einmündenden Straße in beide Richtungen weiter fahren kann, aber noch lange nicht wenden darf.

Wenn man das nun korrekt mappen würde, müsste man die Straße mit der durchgezogenen Linie kurz vor und nach jeder Einmündung auftrennen, um die durchgezogene Linie aufzuheben und ein Abbiegen zu ermöglichen. Dann würde aber der Router die Möglichkeit nutzen, und einem das Wenden vorschlagen. Dies ist aber nicht erlaubt.

Daher sollte man das nciht wenden dürfen mappen, was auch gleichzeitig die durchgezogene ist. Allerdings sollten Abbiegeverbote seperat eingetragen werden.

Wie ich schon schrieb: Die durchgezogene Linie kommt in OSM genau dahin, wo sie in der Realität ist.

Und wenn die durchgezogene Linie in der Realität unterbrochen ist, wird sie auch auf OSM unterbrochen. Dabei ist es vollkommen schnurz, warum sie unterbrochen ist.

Abbiege- und Wendeverbote sind Implikationen/Folgerungen, die sich aus der durchgezogenen Linie ergeben und sind daher in der Datenbank zu vermeiden. Warum also überlässt man deren Berechung - auch die des von Dir geschilderten Falles - nicht dem Routenplaner?

Um die Unterbrechung zu verdeutlichen, mappt man sie mit durchgezogene_mittellinie=no. Diese Unterbrechung lässt sich im Renderer genau so schön, wie die Mittellinie selbst darstellen, indem man sie im Kreuzungs- bzw Einmündungsbereich einfach weglässt, wenn der entsprechende Verbindungsknoten mit durchgezogene_mittellinie=no gekennzeichnet ist.

Ich verstehe immer also noch nicht, warum Du statt der durchgezogenen Linie deren Implikationen Abbiege- und Wendeverbot mappen willst.

Hi,

Vielleicht weil im Moment die meisten Straßen als einzelne Linie (way) gemappt werden!? Wenn eine Straße als Bauwerk, also Fläche gemappt wird, kann man den way für die weiße Mittellinie natürlich in die Mitte einzeichenen. Aber wie macht man das einer normalen Straße die nur aus einer Linie besteht?

Vielleicht meinst du aber auch, dass man der Straße als Tag “Markierung=durchgezogene_Mittellinie”, “Markierung=durchgezogene_Mitteldoppellinie” oder so ähnlich statt den daraus folgenden Ge- und Verboten (Abbiegen verboten, Wenden verboten, Überholen verboten usw.) geben sollte. Das wiederum finde ich richtig.

Fraglich ist nur, wie man das an Kreuzungen interpretiert. Solange Kreuzungen als abstrakte Knoten gemappt werden, ist es mies, den way 30 m, 10 m, 1 m oder 1 mm vor der Kreuzung aufzuteilen, nur um sowas darzustellen. An Grundstückszufahrten wird das noch verrückter. Ich denke, dass man mit den zz. üblichen Abbiegerelationen am besten kommt, das Tagging für Mittellinien also keinen Einfluss auf Kreuzungen und Einmündungen haben sollte. Weiterhin sehe ich im Moment keinen Bedarf für den Fall, eine an Grundstückszufahrten unterbrochene durcghgezogene Mittellinie zu mappen. Für das Routing wäre das höchstens relevant, falls die Grundstückszufahrten selbst gemappt werden.

Gruß, Plasmon

Ich hatte heute live folgendes Problem:
http://maps.cloudmade.com/?lat=49.4129&lng=11.176701&zoom=16&directions=49.41081962868372,11.18135690689087,49.412383238350245,11.173503398895264&travel=car&styleId=1
Die Regensburger Straße für jede Richtung zwei Fahrspuren dazwischen ist eine Abtrennung mit so einem Gummihubbel auf dem elastische Reflektoren sitzen. Also defintiv zwei Fahrspuren.
So wie der Router da lotst wollte das auch mein Garmin. :frowning:

Eigentlich wäre es doch hier am sinnvollsten zwei Fahrspuren anzulegen oder?
Lässt sich das auch mittels Relationen verhindern daß einen der Router quer über die Fahrbahn lotst anstatt die Abfahrt zu nehmen?

Da ich ehrlich gesagt eher der “Feldwegemapper” bin traue ich mir die Lösung dieses Fehlers nicht ganz zu.

Dies ist ein gutes Beispiel dafür, welcher Mist passiert, wenn man eine solche Straße mit nur einem Way implementiert. Zwar wurden schon ein paar Abbiegerelationen an dieser Stelle angelegt, aber immer noch nicht genug. Irgendein Nürnberger sollte das dringend mal vernünftig machen, zumal südöstlich der Kreuzung die Straße neben der Punktewolke liegt.

Karl

Irgendwie reden wir aneinander vorbei. Daher fasse ich das bisher oben Geschriebene noch einmal kurz zusammen und verdeutliche:

Das Mappen:
Wenn eine Straße in Teilen eine durchgezogene Mittelinie hat, so wird genau der davon betroffene Teil 1:1 in OSM mit durchgezogene_Mittelinie=yes (bzw englischen Äquivalent) gemappt. Kurze Unterbrechungen können zur Verdeutlichung mit durchgezogene_Mittelinie=no getaggt werden. Ist die Mittellinie an einer Abzweigung unterbrochen, so wird nicht “der way 30 m, 10 m, 1 m oder 1 mm vor der Kreuzung” mit durchgezogene_Mittelinie=no gemappt, sondern nur der Verbindungsknoten-Node (Punkt). Dadurch, dass nur der Node angegeben wird, weiß der Routenplaner oder eine sonstige Anwendung, dass sich die Unterbrechung genau auf die Abzweigung bezieht. Er kann hieraus die notwendigen Schlüsse, wie zum Beispiel das von Dir erwähnte Wendeverbot ziehen. Es ist dann nicht mehr möglich, den way “30m bis 1mm” neben der Einmündung zum Wenden zu nutzen. Das Taggen des Verbindungsnodes als Unterbrechung der durchgezogenen Mittellinie entspricht dabei genau dem Prinzip von OSM, eine Stra0e auf eine Linie zu reduzieren. Denn der Schnittpunkt zweier Linien (Straßen) ist hier ein Punkt und in diesem Falle genau der Verbindungspunkt.

Beispielsweise eine Unterbrechung/Barriere auf einer Straße wird bei OSM ebenfalls als Punkt gemappt, obwohl die gesamte Straßenbreite davon betroffen ist. Auch hier bleibt das von mir vorgeschlagene Verfahren analog.

Das Rendern:
Die Darstellung der durchgezogenen Mittellinie geschieht im Renderer einfach, platzsparend, übersichtlich und suggestiv, indem man sie in der Straßenmitte als Linie darstellt. Um nun die Unterbrechung an einer Einmündung ebenso suggestiv darzustellen, kann der Renderer im Überlappungsbereich der verknüpften Straßen die durchgezogene Linie löschen. Wie breit die Darstellung der Unterbrechung sein muss, weiß der Renderer selbst am besten. Denn er selbst bestimmt die dargestellte Straßenbreite. Wenn der Renderer rund um den mit durchgezogene_Mittelinie=no gekennzeichneten Node die Mittellinie im überlappenden Bereich der beteiligten Straßen löscht, ergibt das genau die richtige Breite.

Stimme zu! Dies ist ohnehin in der Realität eher seltener der Fall, da die durchgezogene Mittellinie häufig gerade dazu dienen soll, die Zufahrt zu Garagen und Grundstückszugängen auf der linken Seite zu verwehren. Heutzutage wird nur noch selten - insbesondere bei öffentlichem Interesse wie zum Beispiel bei Einkaufsmärkten oder Tankstellen - nach entsprechender Gefahrenabwägung eine Mittellinienunterbrechung genehmigt. So kann der OSM Routenplaner vermöge eingezeichneter Mittellinie die Schlussanfahrt zum Fahrtziel so gestalten, dass es von rechts angefahren werden kann. Die Linie “wirkt” also, auch wenn die Garage oder Grundstückszufahrt nicht gemappt wurde.

Die Abbiegerelationen + Oneways bei jener Auffahrt sollten meiner Einschätzung nach ausreichen, um eine korrekte Verkehrsführung zu ermöglichen. Nur wurden jene erst nach W&Gs Posting eingerichtet, also wird es bis zu einer Berücksichtigung beim Routing noch eine Weile dauern.

Ansonsten ja, eine ordentliche Aufspaltung der Straße in zwei Ways ergäbe dort zusätzlich deshalb Sinn, um den angedeuteten Radweg (Radwege?) (cycleway=opposite_track) eindeutig auf der korrekten Straßenseite (oder beiden?) verlaufen lassen. Denn ein Radfahrer soll die Fahrbahnen sicher nicht kreuzen.

Aber wie gesagt, liegt hier etwas weiter südostlich die momentane Straßenführung noch nicht einmal korrekt auf der Punktewolke. Vielleicht sollte man erst einmal allgemein die Straßenverläufe in OSM korrigieren, bevor man sich über weitere Details Gedanken macht. Grundsätzlich muss ich immer, wenn ich irgendwo bei OSM auf Bundestrassen treffe, deren Verlauf verbessern, Kurven ordentlich ausgestalten, etc., bevor ich Wege vernünftig daran anschließen kann. Wenn dies überall stimmt, kann man dann auch an eine bessere Ausführung der Straßen herangehen. So wird immer über Details diskutiert, obwohl die Grundlagen noch nicht einmal stimmen!

Guten Abend,

Du schriebst: “Die durchgezogene Linie kommt in OSM genau dahin, wo sie in der Realität ist.” Das hatte ich so interpretiert, dass ein entsprechender Weg an der Kreuzung geteilt werden muss, weil ja dort in der Realität für 12 m keine durchgezogene Mittellinie vorhanden ist.

Bzgl. der Diskussion zu den Implikationen stimme ich dir 100%ig zu.

Das wiederum klingt praktikabel. Man müsste mal einige Varianten durchspielen, um zu sehen, ob es auch in jedem Fall eindeutig ist.

Nein, die Analogie greift nicht. Ein way in OSM hat als Linie keine Breite, währenddessen die Unterbrechung der Mittellinie in Richtung des ways durchaus eine nennenswerte Länge haben kann. Im Moment kann ich aber nicht absehen, ob das schlimm ist.

Ok, die Linie wirkt dort, wo keine Kreuzungsknoten eingetragen sind. Da ist es aber unerheblich, ob das Taggen der Mittellinie auf das Abbiegen an Kreuzungsknoten einen Einfluss hat.

Diese Annahme ist gerechtfertigt, falls eine durchgezogene Mittellinie in > 95 % der Fälle an Kreuzungen und Einmündungen nicht unterbrochen wird. Das ist m. E. aber nicht so. Wirkt die Linie auch auf Kreuzungen, so macht der Mapper, der “nichts von der durchgezogenen Linie weiß” einen Fehler, weil dann eine Abbiegeeinschränkung angenommen wird, die real nicht existiert. Fehler können so oder so passieren.

Auch wenn die Geschichte mit den Grundstückszufahrten ein bisschen Zukunftsmusik ist, so scheint sie mir als Test gut geeignet um die Praktikabilität des Taggings zu überprüfen. Wenn sich beide Varianten (Mittellinie an Zufahrten unterbrochen oder nicht) mit vertretbarem Aufwand möglichst kompatibel zum bisherigen Verfahren taggen lassen, dann ist das schon mal nicht schlecht. Ich denke da mal noch ein bisschen drüber nach.

Gruß, Plasmon

Ok, ich habe mal darüber nachgedacht. Ich denke, dass deine Variante nicht stabil gegenüber Änderungen ist.

Man denke an so eine Kreuzung von 2 x highway=tertiary:

Bsp #1:
                      //   /   //
                     //   /   //
                    //   /   //
   =================    /   //
                       /   //
   --------------------    ||
                           \\
   =================    \   \\
                    \\   \   \\
                     \\   \   \\
                      \\   \   \\

Es sollte klar sein, wie hier abgebogen werden darf. Alle ways sind mit durchg. Mittellinie getaggt. So lange der way von links nach rechts oben nicht getrennt ist, ist es wahrscheinlich eindeutig. Trennt man ihn am Knotenpunkt (z. B. weil der Belag wechselt o. ä.), dann treffen drei gleichartige ways aufeinander, der Router kann nicht mehr entscheiden, wie man abbiegen darf. Es lassen sich noch weitere Bsp. finden, die früher oder später Probleme machen. Um denen aus dem Weg zu gehen, wird bei den Abbiegerestriktionen ja auch verlangt, dass kein Weg durchgeht und alles fein säuberlich mit from/via/to getaggt wird.

Das Auftrennen jeder Straße in zwei ways für die Fahrspuren in die beiden Richtungen ist wiederum eindeutig (alles als oneway=yes getaggt). Hier kann man die ways an der Kreuzung teilen und es hat keinen Einfluss auf das Routing. Siehe folgendes Bsp. Hier sind nur die ways abgebildet:

Bsp. #2:
                     ---
                    /
                   /   -->
                  /   /
   <--------------   /
                    +
   --------------+-/ \
                  \   \
                   \   --<
                    \
                     -->

Und es funktioniert auch für die Grundstückszufahrten, ohne dass massig Relationen benötigt werden:

Bsp. #3: durchg. Mittellinie an Zufahrt nicht unterbrochen

  <---------------------
 
  ----------+---------->
            |
            |
            |
Bsp. #4: durchg. Mittellinie an Zufahrt unterbrochen

  <---------+-----------
            |
  ----------+---------->
            |
            |
            |
Bsp. #5: Zufahrt an Straße ohne durchg. Mittellinie

  ---------+-----------
           |
           |
           |

Dennoch sträuben sich mir die Haare, wenn man hier die Straße in zwei ways aufsplitten soll (insb. bei zweispurigen Straßen). Im Moment scheint es aber am wenigsten Probleme zu bereiten. Und es ist die konsequente Fortsetzung vom separaten Einzeichnen von baulich getrennten Radwegen neben der Straße. Mal sehen, was draus wird oder ob jemand eine langfristig bessere Lösung hat :sunglasses:

Gruß, Plasmon

Wunderbar! Da haben wir eine Arbeitsgrundlage. Die zu beantwortende Frage heißt´also: Wie gebe ich eine durchgezogene Mittellinie und deren Unterbrechungen an Abzweigungen und Kreuzungen verkehrsregelgerecht und im Ergebnis möglichst 1:1 gerendert wider. Der letzte Punkt ist dabei wichtig, damit dem schon angesprochenen Anfängerfall entsprochen wird: Er kann mit dem allgemeinen Straßenverkehrswissen und ohne große OSM Fachkenntnisse an der bildlichen Darstellung zumindest bemerken, dass da an einer Abzweigung eine Unterbrechung fehlt oder nicht sein sollte. Wenn er dann möchte. kann er sich im Wiki schlau machen, wie er den Mangel heilen kann.

Hast Du ein Programm, um das zu zeichnen?

Ich sehe das Problem nicht darin, dass die Straße am Knotenpunkt getrennt ist. Führt man zwei Mittellinien bis unmittelbar an den Knotenpunkt heran und ist auch dieser “Mittellinie”, dann gilt die Linie als durchgehend, unabhängig davon, ob die Straße am Knotenpunkt geteilt ist oder nicht. In Deinem Beispiel führen drei Straßenäste zum Knotenpunkt. Hier liegt das Problem liegt eher darin begründet, dass man den Knotenpunkt entweder nur mittellinie=no oder mittellinie=yes taggen kann. Also sind entweder alle drei Äste bis zum Knotenpunkt mit Mittellinie oder aber kein einziger - und zwar unabhängig davon, ob eine Straße am Knotenpunkt durchgehend oder aufgetrennt ist oder nicht.

Abhilfe könnte jetzt nur eine Binde-Relation schaffen, welche die Äste mit durchgehender Mittellinie verbindet. Hierzu werden als Members die Knotenpunkt-Nachbarways der Äste mit durchgehender Linie aufgenommen, ähnlich einer Abbiegerelation. Bei allen Ästen, die da nicht drinhängen, gilt die Linie als unterbrochen. Dabei könnte man eventuell (bin mir noch nicht sicher) die Regel aufstellen, dass maximal zwei abgehende Äste von der Relation erfasst sein dürfen. Ich kann mir gerade keinen sinnvollen Fall vorstellen, wo mehr als eine durchgehende Linie über eine Kreuzung hinwegläuft. Zumindest wäre solch ein Fall eine seltene Ausnahme.

Ich kann nur einen theoretischen und in der Realität nicht vorkommenden Fall konstruieren, bei dem die Doppelspur nicht funktioniert: Angenommen, es “kreuzen” sich zwei Straßen beide mit durchgehender Mittellinie. Dann kann man an der Kreuzung - egal von wo man kommt - nur rechts abbiegen und sonst nichts. Teilt man beide Straßen zum Doppelway, dann sind - oh Wunder - alle Abbiegerelationen wieder möglich :wink:

“Kreuzt” daher eine Straße ohne durchgehende Mittellinie ein andere mit durchgehender Mittellinie, so muss die Straße ohne durchgehende Mittellinie an den Doppelways enden und darf dazwischen nicht weitergehen.

Obwohl es meinen Haaren nicht besser geht, sehe auch ich keine andere derzeit mögliche Lösung und fahre erste Versuche mit Doppelweg auch bei 1+1 Straßen. Dies würde aber dann überflüssig, wenn wir die Mittellinienfrage befriedigend lösen könnten. Und mit der Mittellinie könnte ich auch leben, ohne dass meine Haarpracht einem explodierten Mob gleicht :wink: