Fahrspuren mit Richtungspfeilen erfassen; Wochenaufgabe in KW 47/48

Fertig ist relativ: Es werden ja nur die Straßensegmente angezeigt, die bereits ein lane-tag haben. Zumindest hier in der Gegend sind aber die mehrspurigen Kreuzungen ohne irgendwelche lanes in der Überzahl.

Erst wenn auch die größtenteils erfasst sind, macht ein Spurassistent auf OSM-Basis mMn Sinn. (Mühsam nährt sich das Eichhörnchen.)

Hallo,
bin gerade dabei mich hier ein bisschen einzuarbeiten.
Kann sich das hier bitte mal jemand anschauen, ob das soweit i. O. ist.

http://www.openstreetmap.org/changeset/27129748

Gruß
Rainer

Hallo Rainer,
die Fahrspuren sehen gut aus. Man könnte natürlich noch ein paar change:lanes hinzufügen, da ja gerade Richtung Süden ein sehr langer Bereich mit durchgezogener Mittellinie versehen ist.
Einige Mapper würden auch noch die Straßen links und rechts der vier Verkehrsinseln aufsplitten in getrennte highways. Das wäre wohl in Ordnung, aber sicherlich nicht notwendig. Im Nordosten würde ich persönlich die Spur (nur im Bereich der Insel, nicht davor!) einzeichnen, alleine schon um die Geometrie des Fußgängerüberwegs ordentlich abbilden zu können.

Ich hab mich bisher von nicht-KFZ-Spuren weitgehend ferngehalten, aber interessehalber, da mir hier etwas kniffliges unterkommt;
Ich habe eine mittlere Spur nur für Fahrradabbieger, sieht etwa so aus:

(recht neu, auf dem sat-bild sieht man das noch nicht).
Die Kreuzung ist hier: http://www.openstreetmap.org/node/216291481#map=19/50.98943/11.33014
Was macht man da?

Ganz normal eintragen, wie eine normale Abbiegespur. Danach noch die Berechtigungen:

lanes:forward=2
turn:lanes:forward=left|through
access:lanes:forward=no|yes
bicycle:lanes:forward=designated|yes

Sieht gut aus, danke:

€: Wer kuckn will, sind die Wege: http://www.openstreetmap.org/way/232019387 und http://www.openstreetmap.org/way/315205007

Die Art der Erfassung wäre aus meiner Sicht zu überprüfen.
Siehe http://forum.openstreetmap.org/viewtopic.php?pid=468068#p468068 ,
wonach lanes:* nur sie Spuren des motorisierten Verkehrs zählt :confused:

Die gestrigen Erfassungen können sich auch wieder sehen lasssen:
https://drive.google.com/file/d/0B_3PJBM5cOz5NVdPYUhwS0JyNW8/view
Veränderungen der Anzahl an turn:lanes gegenüber der ersten Auswertung am vorletzten Donnerstag:
Deutschland: 10.279 (+15,9%)
Österreich: 553 (+7,7%)
Schweiz: 235 (+14,4%) (Ein toller Endspurt)
Insgesamt 1.516 neue Erfassungen seit gestern früh.
Insgesamt sind es jetzt 11.067 Neuerfassungen seit Start der Wochenaufgabe :slight_smile:

Ich bedanke mich bei allen, die mitgemacht haben.
Ich denke jedoch, dass diese Wochenaufgabe gezeigt hat, wieviel da noch erfasst werden kann. Wir sind sicher noch nicht durch mit dem Thema, denn wenn wir wollen, dass Router die turn:lanes auswerten, müssen wir auch eine entsprechende Datendichte bieten. In Deutschland sind wir da auf einem guten Weg. International müssen wir das noch pushen, damit die Aussage welche diesen Stein ins Rollen brachte, so weltweit irgendwann nicht mehr aufrecht erhalten werden kann.

Ich werde die Sache weiter im Wochenabstand auswerten und in den nächsten Tagen ein Fazit in den Blog stellen.

Man kann auch noch ein anderes Resumee ziehen: wo können wir noch die Datenqualität verbessern…

  1. Schwierig fand ich den Umgang, wenn Landuses an highways “geklebt” wurden.

  2. noch schwieriger war es, wenn der Highway Teil einer Landuse-Relation oder einer Tram-Strecke war.
    → in diesen beiden Fällen bekommt man auch unnötige Stützpunkte, was ein Ausrichten der Straße erschwert.

  3. Fehler, auf die ich gestoßen bin: -
    -Lanes stimmte nicht mit lanes:forward und lanes:backward überein (im meinem Gebiet teilweise selbst mal produziert, als JOSM eine entsprechene Fehlerauswertung noch nicht hatte)
    -destination:lane : Werte mit Komma anstatt mit Semikolon getrennt.
    -Verwendung von turn:lanes=* ohne daß ein oneway=yes verwendet wird: nichtssagend: in turn:lanes:forward oder turn:lanes:backward ändern.
    -Der Zahlwert in lanes:forward muß mit turn:lanes:forward übereinstimmen (analog backward ect.)

was war noch?

fragte Sven

Meine Rede seit letztem Jahrhundert …

Rein theoretisch könnte man die Zahl in lanes:forward aus turn:lanes:forward bestimmen, genau so wie lanes=* aus lanes:forward + lanes:backward.
Ich habe aber festgestellt, dass nicht alle Anwendungen (z.B. Mappaint-Stile) “richtig rechnen” können.
Trotz lanes=4 (und lanes:forward=3) wurden drei hin und zwei zurück dargestellt. Erst mit einem lanes:backward=1 stimmte es dann.

Ich bin daher dazu übergegangen, alle Angaben einzutragen, auch die eigentlich redundanten.
Wir taggen zwar nicht für den Renderer, man kann ihm aber beim Rechnen helfen (er müsste sonst ja eine Stufe höher mit auswerten).

Wenn’s interessiert:
weltweiter Überblick
Vergleich der Entwicklung in den letzten sechs Tagen. Die Summe aller ausgewerteten Länder liegt bei über 98% aller turn:lanes weltweit.
Wer will, kann den Rest gerne suchen :slight_smile:

Im Wiki zu :lanes (http://wiki.openstreetmap.org/wiki/Lanes) ist nur allgemein von Spuren die Rede. Busspuren werden ausdrücklich erwähnt. Im proposal werden Fahrradspuren bei turn:lanes ebenso mitgezählt.
Ich wüsste keinen Grund, warum man einzelne Arten von Spuren außen vor lassen sollte, nur weil sie nicht zwei Meter breit sind sondern nur einen und einer bestimmten Art des Verkehrs dienen.
Forenbeiträge mit Diskussionen gibt es viele, aber beim Mappen sollten wir uns wohl nur am wiki orientieren.

Auf deutsch: jede Menge Arbeit wäre nur zu diesem einen Problem noch zu tun… :frowning: (nicht, dass ich die Definition nicht nachvollziehen könnte und wollte)

Wieso eigentlich ‘NO’ in der Berechtigung ‘access:lanes:forward/backward=no|yes’ ?
Das bedeutet imho, dass für diese Spur gilt: “Benutzung nicht erlaubt oder nicht möglich.”
siehe: http://wiki.openstreetmap.org/wiki/DE:Key:access

Ist das wirklich so gemeint? Die Beschreibung mit ‘bicycle:lanes:forward/backward=designated’ sollte doch reichen?

In JOSM (mit Style Fahrspur-/Straßenattribute) ist die Spur bei ‘access=no’ auch noch rot gestreift. Das spricht für mich nach “gesperrt”.

Robert

Genau. Mit bicycle=designated wird dieses Verbot dann wieder “aufgeweicht”. Hätte man nur das bicycle-Tag, wären Fahrräder zwar diejenigen, für die diese Spur wäre, aber alle anderen dürften sie auch noch benutzen. Vergleiche mit Straßenschildern: “Anlieger frei” alleine verbietet niemandem das Fahren. Erst ein “Durchfahrt verboten. Anlieger frei” ergibt den gewünschten Effekt.

Leider geht die Formel lanes.forward + lanes.backward = lanes nicht auf. Im Wiki ist dazu sogar ein Beispiel mit Bild (key:lanes):

lanes=3
lanes:forward=1
lanes:backward=1

Die mittlere Spur ist eine Sperrfläche.

Wenn man dem Redering vom “Lane and road attribute” map paint style folgt reicht sogar ein lanes=3, lanes=5, lanes=7, … aus, um die mittlere Spur als nicht befahrbar zu zeichnen.

Als Ergänzung oder Vereinfachung:

Genau. Aber sämtliche danach formulierten Freigaben überschreiben die Begrenzung. Extrem vereinfachtes Beispiel:

(=horse=yes)
Andersrum würde* access den Zugang überschreiben:

(=access=no)

  • theoretisch, keine Ahnung, was $Router daaus machen

Für die mittlere Spur, egal ob Sperrfläche oder beidseitig befahren gibt es meines Wissens noch keine allgemeingültige schöne Lösung.

Tags haben keine Reihenfolge. Es ist aber so definiert, dass allgemeinere Access-Tags von spezifischeren “überschrieben” werden.

Das Unschöne ist nur, dass das nicht im Datenmodell festgelegt wird, sondern durch das Auswerteprogramm. Da gibt es zwar meist einen “common sense”, aber eben nicht garantiert.