Wie könnte man so ein Spurmapping wie das hier in der Heckentalstraße sinnvoll umbauen? Der Fahrradstreifen mittendrin stört etwas.
–ks
Mag sein, dass es “stört”; das Bing-Luftbild bestätigt aber die Richtigkeit.
Solche Konstruktionen gibt es immer mehr, damit der rechtsabbiegende Autoverkehr nicht erst an der Kreuzung selbst durch den geradeausfahrenden Radverkehr durchmuss.
Mit Spurtagging gegen das Spurmapping:
lanes:forward = 3
turn:lanes:forward = left|left;through|through|right
access:lanes:forward = yes|yes|no|yes
bicycle:lanes:forward = no|no|designated|yes #Linksabbieger müssen wahrscheinlich auf der Insel in der Mitte der Kreuzung abbiegen
width:lanes:forward = 3|3|1|3
bis kurz vor den Beginn der Verkehrsinsel / schraffierten Fläche, danach hat die Rechtsabbiegerspur dann einen eigenen Way, weil baulich getrennt.
Richtig ist, daß die Spuren so verlaufen. Nicht richtig ist, sie als jeweils eigene Ways zu mappen, da sie hier nicht baulich getrennt, sondern auf ein und derselben Fahrbahn markiert sind. Darum ging es mir. Ich wußte nur nicht, was ich mit dem Radweg (also der Radspur) anfangen sollte.
Ich sehe, ich habe bezüglich Spurtagging noch einiges zu lernen 
Danke! Aber heute geh ich da nicht mehr ran.
–ks
Guten Morgen,
ich habe hier ein Verständnisproblem und bitte um Hilfe:
Es werden zuerst 3 Spuren mit lanes:forward = 3 getaggt, soweit klar.
In der nächsten Zeile werden jedoch 4 Eigenschaften angegeben, also links, links und geradeaus, geradeaus, rechts. Müsste die Anzahl der Eigenschaften nicht mit der Anzahl der davor angegebenen Spuren übereinstimmen?
Das selbe Problem bei den folgenden Zeilen, es werden immer 4 Eigenschaften für nur 3 Spuren angegeben.
Müssten hier nicht 4 Spuren, 2 Auto + 1 Fahrrad + 1 Auto, also lanes:forward = 4 getaggt werden?
Grüße aus Kufstein
Guck mal https://wiki.openstreetmap.org/wiki/Lanes#Crossing_with_a_designated_lane_for_bicycles
Die Community ist sich noch nicht ganz einig, ob der key lanes=* sämtliche Spuren zählt oder nur die für motorisierten Verkehr. Das Suffix :lanes zählt aber immer alle Spuren auf. Etwas verwirrend ist das schon.
–ks
Moin Erwin,
das sieht unglücklich aus (und ist es so auch, finde ich), aber es kann korrekt sein. Ich weiß nicht genau, ob sich die Geister darüber streiten, aber ich persönlich gebe immer explizit die Anzahl der Lanes an. Im obigen Beispiel würde also, wenn man es so trocken liest, einfach das “lanes:4” fehlen. Die erste Zeile bedeutet nur, dass es 3 Lanes in Richtung “Forward” gibt. Die folgenden Angaben deuten dann implizit darauf hin, dass es darüber hinaus noch mehr Spuren gibt.
Allerdings müsste das Beispiel ganz oben eigentlich ein “lanes:5” drin haben, denn das ist die Realität. Mit den impliziten Angaben wird die fünfte Spur ganz rechts in Gegenrichtung einfach verschwiegen, und kein Renderer wird sie ggf. zeichnen können. Ich würde als Navi sogar nicht dort durch routen, um ehrlich zu sein, weil ich keine Kenntnis von dieser Spur ableiten kann.
Und die Rad-Spur ist auch nicht korrekt, da man da sicherlich auch rechts abbiegen kann. Das fehlt aber in der Turn-Angabe. Das kann man allerdings bei Bing kaum erkennen.
Also ich persönlich halte das derzeitige Tagging für sehr schlecht, aber ich habe da ja was von “lernen” gelesen 
Und dabei hilft das hier ganz bestimmt:
https://wiki.openstreetmap.org/wiki/DE:Lanes
Da ist übrigens die mittige Radspur auch behandelt. Vorsicht aber damit, da streiten sich wirklich die Geister. Manche wollen da keine Radspuren drin haben (was ich unsinnig finde), manche wollen sogar gesperrte Spuren drin haben.
Edit: Link korrigiert (falsche Zwischenablage).
PS: Ich sehe gerade, dass da auch nur “lanes:3” steht bei dem Fahrradbeispiel. Geht für mich gar nicht, weil es einfach nicht konsistent ist. Der Gegenentwurf dazu scheint im fünften Beispiel hier zu stecken: http://wiki.openstreetmap.org/wiki/DE:Key:lanes#Beispiele (was für mich konsistent wäre, wenn man die Mitte als Spur im weitesten Sinne betrachtet, nämlich als eine Spur der Straße unabhängig von ihrer Nutzung).
Das Problem ließe sich sehr einfach durch ein lanes:total (Anzahl ALLER Spuren) lösen.
“lanes” nachträglich umzudefinieren wäre die schlechteste aller Lösungen.
Der Versuch ist gut, aber noch nicht ganz ausgereift. Das Problem ist, dass dass lanes Schema nicht für jede Situation eine (brauchbare) Lösung kennt.
Die vorherige Version war ein Versuch die Verwirrung gering und für Router auswertbar zu halten. Keep it simple and map what’s on the ground. Einen 1m breiten Fahradweg zwischen 2 Autospuren hätte ich jetzt einfach als “Bauliche Trennung” und kleineres Übel hingenommen.
Aktuell sind an der Kreuzung jetzt Kraut (falsche lanes) und Rüben (freihengende residentials) vorherschend, hier sollte noch nachgebessert werden, sonst war die Änderung nur gut gemeint …
Was meinst du mit freihängenden Residentials?
–ks
Genau darum geht es Erwin ja: Zählt die Radspur bei den lanes mit oder nicht?
Nö, sie wird einfach nicht erwähnt. Das gesamte Spurtagging behandelt nur die forward-Richtung. Und das reicht IMHO auch, es besteht kein Zwang, an jedem Straßenstück immer sämtliche Lanes in sämtlichen Richtungen anzugeben. Es reicht, die Besonderheiten (Richtungsfahrstreifen) zu taggen, der Rest ist dann Default (z.B. 1 Spur pro Richtung).
Was macht der Renderer denn bei einem highway=residential ohne jedes Spurtagging? Genau das macht er hier auch. Wieso sollte er da was nicht zeichnen können?
Verstehe ich nicht. Das ist ein ganz normaler highway=residential ohne oneway=yes, da kann jeder Router der Welt beruhigt davon ausgehen, daß man den in beliebigen Richtungen benutzen kann, ob nun lanes angegeben sind oder nicht. Ohne die lanes-Angaben in backward-Richtung weiß er lediglich nicht, wieviele Spuren da nebeneinander liegen. Aber wieso soll ihn das davon abhalten, überhaupt da lang zu routen? Er wird sagen: Fahr da lang und schau selbst, was für Spuren es gibt. Genau das, was er auch sagt, wenn gar keine lanes getaggt sind.
–ks
Also ich würde glaube ich, wenn ich so eine Straße neu einzeichnen würde, die Fahrradspur ganz weglassen und statdessen cycleway=lane benutzen. Und da Fahrradspuren in D im Regelfall rechts neben der rechten Hauptfahrbahn angelegt werden, sollte die Lage der Spur so auch eindeutig sein.
Sehe ich nicht so. Das lanes:forward beschreibt explizit nur die Fahrspuren in einer Richtung. Das schließt nicht aus, das es in der anderen Richtung keine Fahrspuren gibt. Da hier kein oneway=yes existiert, sollte für die Gegenrichtung das selbe default verwendet werden, wie auf Straßen komplett ohne lanes=*.
Nein, denn dann würdest du dich als Radfahrer plötzlich auf der linken Seite der Abbiegerspur wiederfinden und das ist nicht zulässig. Wer abbiegen will muss sich auf einer Abbiegespur einordnen, so sie denn vorhanden ist. Und die Fahhradspur geht gradeaus weiter und ist somit keine Abbiegespur.