Mal ne Frage zu lanes

Das steht im Konflikt zum Mapping von dreispurigen Straßen (lanes=3, lanes:forward=1, lanes:backward=1), funktioniert also nicht.

Prince Kassad wrote:

Das steht im Konflikt zum Mapping von dreispurigen Straßen (lanes=3, lanes:forward=1, lanes:backward=1), funktioniert also nicht.

Wenn ich wegavision richtig verstehe, will er/sie auf diese Weise eine durchgehende Mittellinie reintaggen (also keine bauliche Trennung, daher keine separaten Ways, aber eine verkehrsrechtliche Trennung).

Also bei 3 Spuren ohne Richtungszuweisung einfach lanes=3, bei 2 Spuren in forward- und 1 Spur in backward-Richtung lanes:forward=2 und lanes:backward=1 taggen. Der Vorschlag zielt darauf ab, daß im zweiten Fall klar ist, dass die Spuren den Fahrtrichtungen fest zugeordnet sind.

Schlecht ist die Idee nicht. Dann besteht aber viel Nachholbedarf bei allen Straßen mit durchgehenden Mittellinien, die schon mit der Summe getaggt sind.

--ks

lanes:forward=1 + lanes:backward=1 bei jeder "normalen" straße ist schon vollständighalber richtig, aber nicht notwendig bzw. ist doch der defaultwert i.V.m. mit lanes=2 oder?. ich fange mit diesen tags erst bei lanes=3 und mehr an. bei durchgezoger linie gibt es das tag overtaking=no.

Chenshi wrote:

bei durchgezoger linie gibt es das tag overtaking=no.

Nein, das steht für das entsprechende Verkehrsschild, das auch ohne durchgezogene Linie hängen kann.

Prince Kassad wrote:

Chenshi wrote:

bei durchgezoger linie gibt es das tag overtaking=no.

Nein, das steht für das entsprechende Verkehrsschild, das auch ohne durchgezogene Linie hängen kann.

Laut Wiki stimmt das nicht: "Überholverbot aufgrund Verkehrzeichen oder durchgezogener Linie" (http://wiki.openstreetmap.org/wiki/DE:Key:overtaking rechter Kasten)

Wenn man dazu noch die englische Version zu Rate zieht, sieht man, dass die deutsche Übersetzung mit dem Bespiel missverstanden werden kann.

Es gibt insgesamt vier Tags für die Zahl der Spuren: lanes, :forward, :backward und :both_ways. Wobei lanes die Summe der anderen drei ist. Da lanes:both_ways eher die Ausnahme ist, sollte man immer davon ausgehen, das lanes:both_ways=0 wenn nichts anderes angegeben ist.
Bleiben noch die üblichen lanes, lanes:forward und lanes:backward. Hier reicht es zwei der drei anzugeben, da die dritte immer berechnet werden kann. Ist nur lanes angegeben, dann werden die lanes gleichmäßig für beide Richtungen verteilt (z.B. lanes=4 -> zwei in jede Richtung)
Mehr Infos wie durchgezogene Linien ist nicht enthalten. Die gibt es mit overtaking=no (wenn Überholverbot) und mit change:lanes (wenn durchgezogene Linie). Bedenkt, dass eine durchgezogene Linie nicht bedeutet, dass nicht überholt werden darf!

Eine durchgezogene Linie wird durch change(:lanes)(:backward/forward)=* angezeigt.

Bedenkt, dass eine durchgezogene Linie nicht bedeutet, dass nicht überholt werden darf!

... aber ohne die Linie zu überfahren - auch nur teilweise (Radstärke) - z.B. Radfahrer überholen mit seitlichen Abstand:
http://www.bussgeldrechner.org/fahrstre … nzung.html

Das Schild Überholverbot heißt in D ja "nur": "Verbietet den Führern von Kraftfahrzeugen aller Art, mehrspurige Kraftfahrzeuge und Krafträder mit Beiwagen zu überholen."

Ich denke das ist im Wiki und in den Köpfen noch nicht genügend herausgearbeitet.

Ich habe mir das so gedacht, dass man immer wenn eine Trennung der Spuren, also auch nur eine gestrichelte Linie vorhanden ist, dann könnte man das in OSM sichtbar machen, indem man beide Richtungsspuren angibt. bedeutet also, es gibt für jeder Richtung eine abgegrenzte Spur.
Fehlt diese Trennung, also wie auf den meisten residentals aber auch tertiär und unklassifiziert, dann wird nur lanes=2 geschrieben. Bedeutet also, man muss sich mit dem Gegenverkehr vor Ort einigen, wo man fahren kann.
Man könnte natürlich auch argumentieren, dass durch lanes:r+l=1 mitgeteilt wird, dass die Gegenspur nicht benutzt werden darf, man je Richtung also nur eine hat. Das wäre dann die durchgezogene Linie, die wird ja aber schon andersweitig beschrieben.

Also ich sehe hier durch die impliziten Standardannahmen auch keinen großen Bedarf. Klar, für die Navigation wird es immer wichtiger, spezifisch zu taggen, und das mache ich auch immer, wenn es nötig ist. Aber das "nötig" ist hier das Schlüsselwort. Ich stelle mir immer die Frage, ob einer Navigation (sei es Mensch oder Maschine) wirklich eine Information fehlt, wenn ich ein "Minimal-Tagging" verwende. Wenn nicht, ist alles gut, dann brauche ich auch keine zusätzlichen Tags. Diese würden nämlich im Sinne von

wegavision wrote:

... eine weitere Größe in OSM bringen ...

lediglich für mehr Bytes in der Datenbank sorgen.

Ein anderer Aspekt ist natürlich die Darstellung in den Karten. Es gibt den Grundsatz "Wir taggen nicht für den Renderer". Das stimmt in meinen Augen allerdings nur so weit, dass man keine Eigenschaften "erfinden" oder "verbiegen" soll, nur, damit es besser aussieht. Wenn ich aber gerne die reale Anzahl von Fahrstreifen mit den richtigen Linien und vielleicht sogar Breiten sehen möchte (soweit es vom entsprechenden Renderer unterstützt wird), dann kann ich sicherlich die entsprechenden Tags vergeben, auch wenn diese nicht zwingend für eine Navigation erforderlich sind. Die Instrumente dafür wurden oben ja schon teils genannt.

Mein Grundsatz:
-lanes=* wird erfasst, wenn entsprechende Markierungen vorhanden sind.
-lanes=* sagt nichts über Straßenbreite oder die Fahrtrichtungsmöglichkeit aus.
-Für Breite gibt es die *width=*
-Für Fahrtrichtungsmöglichkeite gibt es oneway=*
Die Idee von wegavision muss nicht umgesetzt werden, weil die vorhandenen taggings ausreichen. Und bloß, weil Gegenverkehr möglich ist, hat eine Straße noch lande keine zwei Spuren.

hurdygurdyman wrote:

Und bloß, weil Gegenverkehr möglich ist, hat eine Straße noch lande keine zwei Spuren.

Genau das versucht er doch damit deutlich zu machen. Bei vielen Straßen mit Gegenverkehr existiert keine optische Trennung der Fahrspuren. D.h., die voreingestellte Annahme "lanes=2" bedeutet nur, dass sich hier zwei Fahrzeuge begegnen können.
Es gibt Straßen mit einer optischen Trennung durch eine gestrichelte oder geschlossene Linie (sog. Mittelstrich). Zur Verdeutlichung, dass hier tatsächlich zwei "getrennte" Fahrspuren existieren möchte er lanes:forward=* und lanes:backward:* hinzufügen.
Der Renderer hat dann die Möglichkeit, an diesen Straßen eine Fahrspurtrennung anhand des sog. Mittelstrichs optisch zu untermalen. Bei Straßen ohne diese Trennung gibt es die Anzeige des Mittelstriches dann nicht.
Jedenfalls habe ich es so verstanden (ohne jetzt eine Wertung über eine Sinnhaftigkeit abzugeben).

Abgesehen davon, dass ein Mittelstrich auf den Straßen in den Karten optisch ganz nett aussieht, aber nur da, wo er auch wirklich existiert, sollte aber folgendes bedacht werden:

Die Breite der Straße mit Mittelstrich ist in der Regel (jedenfalls hier bei uns) größer als die ohne.
Eine Angabe der Breite mit width=* halte ich für notwendig aber nicht ausreichend, denn die Fahrspuren können unterschiedliche Breite haben. Müssten wir dann nicht auch einen Tag wie "width:lanes:forward", einführen, und dies sogar "fahrspurengenau" wie
"lanes:forward=2" + "width:lanes:forward=3.5|2.4" ?

Die Angabe wird zu einer weiteren Zersplitterung von Straßenabschnitten führen, da es durchaus Straßen gibt, die immer nur in Teilstücken eine optische Kennzeichnung haben.

Es muss festgelegt werden, ob width dann einschl. Randstreifen/Bürgersteig angegeben werden muss, oder ob man bei Randstreifen sagt: width=*, und width:lanes:* bei Fahrspuren und ein widht:sidewalk=* immer zusätzlich angeben muss.

Das macht zumindest eine Menge Arbeit, aber was macht bei OSM keine Arbeit...
Thoschi

Thoschi wrote:

Müssten wir dann nicht auch einen Tag wie "width:lanes:forward", einführen, und dies sogar "fahrspurengenau" wie
"lanes:forward=2" + "width:lanes:forward=3.5|2.4" ?

Dieses Tagging wird bereits verwendet.

Es muss festgelegt werden, ob width dann einschl. Randstreifen/Bürgersteig angegeben werden muss, oder ob man bei Randstreifen sagt: width=*, und width:lanes:* bei Fahrspuren und ein widht:sidewalk=* immer zusätzlich angeben muss.

Meines Wissens ist die Breite der Straße die Breite der Fahrstraße.

MKnight wrote:

Meines Wissens ist die Breite der Straße die Breite der Fahrstraße.

Jo, das deckt sich auch mit meinen Erfahrungen mit der StVO.

Wollte mal vor einiger Zeit dort herausfinden, was eigentlich einen "Bürgersteig" ausmacht, und dessen Definition in der StVO finden: nada. Die schreibt nur (sinngemäß): Die Straße beginnt und endet an den Bordsteinkanten, ...

Gruss
walter

wambacher wrote:

Wollte mal vor einiger Zeit dort herausfinden, was eigentlich einen "Bürgersteig" ausmacht, und dessen Definition in der StVO finden: nada. Die schreibt nur (sinngemäß): Die Straße beginnt und endet an den Bordsteinkanten, ...

Gut zu wissen... das sollte man dann mal im Wiki dokumentieren (oder bin ich mal wieder blind?)

Moin,

Thoschi wrote:

Gut zu wissen... das sollte man dann mal im Wiki dokumentieren (oder bin ich mal wieder blind?)

damit wäre ich vorsichtig, denn

wambacher wrote:

[...]Definition in der StVO finden: nada. Die schreibt nur (sinngemäß): Die Straße beginnt und endet an den Bordsteinkanten, ...

ich lese da einen anderen Sinn heraus:

Wie kann eine Straßenverkehrsordnung denn dann überhaupt Regeln und Verkehrszeichen definieren, die nicht den Bereich zwischen den Bordsteinen betreffen?

StVO

§ 25
Fußgänger
(1) Wer zu Fuß geht, muss die Gehwege benutzen. Auf der Fahrbahn darf nur gegangen werden, wenn die Straße weder einen Gehweg noch einen Seitenstreifen hat.

Fazit:
Die Fahrbahn beginnt und endet an den Bordsteinen (in der Regel, bei Seitenstreifen u. ä. Ausnahme).

Siehe auch

Straßengesetz

§ 2
Öffentliche Straßen

(1) Öffentliche Straßen im Sinne dieses Gesetzes sind Straßen, Wege und Plätze, die dem öffentlichen Verkehr gewidmet sind.

(2) Zu den öffentlichen Straßen gehören:

1. der Straßenkörper; das sind insbesondere
a) der Straßenuntergrund, der Straßenunterbau, die Straßendecke, Dämme, Gräben, Entwässerungsanlagen, Böschungen, Stützmauern, Durchlässe, Lärmschutzanlagen, Brücken und Tunnel;
b) die Fahrbahnen, Haltestellenbuchten, Gehwege, Radwege, Parkplätze, Trenn-, Seiten-, Rand- und Sicherheitsstreifen sowie Materialbuchten;

Grüße, Georg

Kurz gesagt: Man muss zwischen Straße und Fahrbahn (Teil davon) unterscheiden.
"lanes" (Fahrstreifen) bezieht sich mMn auf Fahrbahn.

Die Fahrbahn kann aber auch schon an der Fahrbahnbegrenzungslinie enden, deswegen heißt sie ja so ...
Deswegen sind Radspuren auch nicht Teil der Fahrbahn im Gegensatz zu Schutzstreifen.
Und Seitenstreifen sind auch ohne gemalte Linie nicht Teil der Fahrbahn nach § 2.
Stellt man ein Gehwegschild neben die Fahrbahnbegrenzungslinie, dann ist rechts der Linie sogar ein Gehweg ...

Mueck wrote:

Die Fahrbahn kann aber auch schon an der Fahrbahnbegrenzungslinie enden, deswegen heißt sie ja so ...
Deswegen sind Radspuren auch nicht Teil der Fahrbahn im Gegensatz zu Schutzstreifen.
Und Seitenstreifen sind auch ohne gemalte Linie nicht Teil der Fahrbahn nach § 2.
Stellt man ein Gehwegschild neben die Fahrbahnbegrenzungslinie, dann ist rechts der Linie sogar ein Gehweg ...

Man kann es sogar noch weiter treiben:
Ist ein Radstreifen zwischen zwei Normalfahrstreifen Teil der Fahrbahn oder nicht?
(Anm.: Ich verzichte auf eine juristisch fundierte Antwort 😉 )

Für solche Spitzfindigkeiten empfehle ich das verkehrsportal.de
Am besten mit einem Packen Bilder unterm Arm ;-)

Es geht aber doch darum, festzulegen auf was sich der Tag "width=*" in OSM bezieht. Und dafür hilft das Straßengesetz nur wenig weiter. Ich lese daraus, grds. wird gesetzlich eine Straße in Fahrbahn, Gehweg und ggf. Seitenstreifen, Gräben unterteilt, das sind für uns aber doch nur Begriffsdefinitionen. Aber das Gesetz kann nicht vorgeben, wie der Tag "width" an dem Tag "highway" zu werten ist. Wird mit width die Breite der Straße einschl. der Entwässerungsgräben rechts und links genommen, wird nur die Breite des befestigten Bereichs genommen oder nur der für ein Fahrzeug befahrbare Teil (das wäre bei spurgetrennten Wegen wie Autobahnen sinnvoll, denn lt. Gesetz gehört der Mittelstreifen ja zur Straße).

Wambacher schlägt vor, das width nur für die Fahrbahn genutzt wird. Das bedeutet für den Bürgersteig und Radweg müssen andere Tags her:
width:sidewalk
width:footway
width:path
width:cycleway
Eben für alle, die mit highway=* zusätzlich an einem way vergeben werden.

Thoschi wrote:

Es geht aber doch darum, festzulegen auf was sich der Tag "width=*" in OSM bezieht. Und dafür hilft das Straßengesetz nur wenig weiter. Ich lese daraus, grds. wird gesetzlich eine Straße in Fahrbahn, Gehweg und ggf. Seitenstreifen, Gräben unterteilt, das sind für uns aber doch nur Begriffsdefinitionen. Aber das Gesetz kann nicht vorgeben, wie der Tag "width" an dem Tag "highway" zu werten ist. Wird mit width die Breite der Straße einschl. der Entwässerungsgräben rechts und links genommen, wird nur die Breite des befestigten Bereichs genommen oder nur der für ein Fahrzeug befahrbare Teil (das wäre bei spurgetrennten Wegen wie Autobahnen sinnvoll, denn lt. Gesetz gehört der Mittelstreifen ja zur Straße).

Wambacher schlägt vor, das width nur für die Fahrbahn genutzt wird. Das bedeutet für den Bürgersteig und Radweg müssen andere Tags her:
width:sidewalk
width:footway
width:path
width:cycleway
Eben für alle, die mit highway=* zusätzlich an einem way vergeben werden.

In Nepal habe ich schon
width=4
width:carriage=5
width:shoulder=0.5
gesehen.
Wurde im Rahmen eines ILO-Projektes zusammen mit etlichen weiteren undokumentierten Tags vor Ort erfasst.

Thoschi wrote:

Wambacher schlägt vor, das width nur für die Fahrbahn genutzt wird. Das bedeutet für den Bürgersteig und Radweg müssen andere Tags her:
width:sidewalk
width:footway
width:path
width:cycleway
Eben für alle, die mit highway=* zusätzlich an einem way vergeben werden.

Wambachers Vorschlag halte ich jetzt schon für "best practice".
Im Übrigen hat sich zum Angeben der Breite von Geh-/Radwegen als Attribut der "Straße"
sidewalk:width=*
cycleway:width=*
etabliert.

Ich halte es mit Hubert87: Das etablierte sidewalk(:left|:right):width für die Breite der Bürgersteige. Es ist üblich, zuerst das Objekt und dann die Eigenschaft zu nennen, z.B. gibt es roof:height aber nicht height:roof.

width=* vermeide ich lieber, sobald nicht mehr ganz klar ist welche Breite gemeint ist (Fahrbahn, mit Radstreifen, mit Parkstreifen, mit Bürgersteig etc.). Dann kommt width:lanes zum Einsatz, was ja ohnehin mehr Informationen enthält.

Mach OSM-Definition sollte width an sich die Gesamtbreite des Objekts angeben, also inklusive aller zusätzlich getaggten Nebenobjekte (Wege und Parkstreifen). Die StVO interessiert in diesem Zusammenhang nicht, da es sich um ein Tag handelt das an beliebigen Objekten vorhanden sein kann und selbstverständlich auch weltweit eigesetzt wird.

Hubert87 wrote:

Wambachers Vorschlag halte ich jetzt schon für "best practice".
Im Übrigen hat sich zum Angeben der Breite von Geh-/Radwegen als Attribut der "Straße"
sidewalk:width=*
cycleway:width=*
etabliert.

Nichts gegen einzuwenden, habe die Tagkombination im Wiki halt nicht gefunden.

Moin,

ehrlich gesagt grinse ich mir Einen, wie hier der Zusammenhang zu Walters sinngemäß 'fehlerhafter' Behauptung und Thoschis darauf beruhendem Umdefinitionswunsch von width beim highway zerrissen wird. 😉

Aber solange wir den gleichen Konsens haben:
- width bezieht sich auf das OSM-Objekt
- und da nicht klar ist, was genau das Objekt highway nun darstellt / darstellen soll, ist eben auch width unklar
- width jetzt auf die Fahrbahn zu definieren ist eben eine Umdefinition des früheren Verständnis
solls mir egal sein.

Eine bestehende Definition in einem laufenden Prozess (*), von dem noch nicht einmal klar ist, ob er je abgeschlossen wird, zu ändern, ist selten sinnvoll.
Eine klare Definition bringt zwar unzweifelhaft Vorteile für die Zukunft - aber eine Umdefinition verfälscht nach Murphy alle bereits vorhandenen Daten.

Vorschlag:
Nehmt für den Straßenteil Fahrbahn wie für die anderen Straßenteile lieber einen eindeutigen tag (vielleicht carriageway:width) und lasst ihn von Muttersprachlern absegnen.

Grüße, Georg

(*) highway-tags oder getrennt mappen

GeorgFausB wrote:

...Thoschis darauf beruhendem Umdefinitionswunsch...

Mein Ziel ist keine Umdefinition sondern eine eindeutige Klarstellung und Beschreibung. Wenn bisher niemandem wirklich klar ist, wie width genau anzuwenden ist, dann sind die Daten jetzt schon chaotisch. Folglich sollte man Eindeutigkeit herstellen (und beschreiben). Die Alternative ist wie bisher, jeder mappt so, wie er es verstanden hat.
Das bei einer Klarstellung bereits gemappte Daten dadurch "fehlerhaft" sein /werden, versteht sich von selbst unter der Prämisse, dass der gleiche Tag schon jetzt mit unterschiedlicher Bedeutung getaggt ist.

Dein implizierter Vorschlag, alles so zu lassen wie es ist, ist somit eine Festschreibung des Chaos und die Tatsache dass diese Daten unauswertbar und damit überflüssig sind.
Dein Vorschlag einen neuen Tag zu verwenden beseitigt das Chaos und die Verwirrung beim jetztigen immer noch nicht, sondern schafft im Zweifel reduntante Daten.