Fahrspuren mit Richtungspfeilen erfassen; Wochenaufgabe in KW 47/48

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.

Bei meiner Neugier nach dem Trend der Erfassungen (schon wieder weltweit fast 1.300 mehr als gestern :slight_smile: ) stieß ich auf nodes mit dem key turn:lanes:*.
Hier wäre ein genauerer Blick nötig.
Ich denke, die Masse ist im Eifer des Gefechtes schief gegangen. :roll_eyes:

+1…

wenn mir nicht einer zuvor kommt… bereinige ich meine Fehler (an der A13 und A15) heute Abend.

Danke für die Meldung,

Sven

Mach mal. Aus Fehlern wird man klug.
Ich ging schon selbst durch dieses Tal der Tränen

Apropos:
Kann jemand spanisch oder katalanisch und den Verursacher mal ansprechen?

Fehler sind dazu da, gemacht zu werden und daraus zu Lernen.
:slight_smile:

Klasse, hab ich mir gestern mühselig über taginfo rausgesucht … so is das noch komfortabler…

wo ich grad dabei bin, mach ich das mal.

Müsste jetzt sauber sein, bis auf dieses Objekt, was nich ganz falsch is, aber auch nich richtig. Keinen Plan.