[Talk-de] Abbiegespuren mit Fahrradspur

[Tom Pfeifer]

Martin Vonwald wrote on 2014-12-05 09:05:
> Nur zum Verständnis: ich finde es extrem unglücklich, dass der
> lanes-Schlüssel nicht einfach alle Spuren zählt und man mit Unterschlüsseln
> konsequent weiter aufsplittet, z.B. lanes=3 + lanes:bicycle=1 +
> lanes:psv=1. So wie es beim lanes-Schlüssel definiert ist, ist es wenig
> intuitiv und fehleranfällig (Bsp: werden Spuren die nur manchmal befahrbar
> sind mitgezählt oder nicht? Weiß das jeder auswendig? Manche Spuren werden
> mitgezählt und extra ausgewiesen, manche nicht -> inkonsistent!).

Ja gut, dann sind wir uns ja doch einig. Die von Chris zitierte Proposal-Seite,
unter Common questions,
https://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#The_issues_with_the_lanes_tag
sieht ja das lanes=N tag quasi nur für die Rückwärtskompatibilität.

Das darüberstehende Beispiel benutzt cycleway:lanes:...=, während
https://wiki.openstreetmap.org/wiki/Bicycle hier bicycle:lanes=
einführt?

Das Beispiel B1 ist besonders unglücklich, da es beim Spurlayout kein
forward/backward benutzt. Ohne die  "lanes=3 + lanes:forward=2"
bin ich komplett ratlos in welche Richtung die Spuren gehen. Selbst
wenn ich das kenne, muss ich aus "bicycle:lanes=designated" vermuten
dass "designated" eine Halbspur ist (falls nicht auch noch ein Bus mit
langfährt), während "yes" eine Vollspur benutzt. Nun kann ich die
beiden bicycle=designated subtrahieren und komme auf die Vollspuren,
die ich nun endlich dem lanes=count zuordnen kann.

Implementiere das mal bitte jemand auf einem Android. Wenn das fertig ist,
kommt noch die Variante, falls die Rad/Busspur zufällig rechts aussen ist,
das als cycleway:right=share_busway zusammenzufassen (B3).

B4 erfindet noch "service=bus" obwohl das ja ein access-Recht ist und
keine Art der Strasse.

 > Aber an
> der Definition von lanes können wir jetzt nichts mehr ändern.
>
> Um genau diese Unklarheiten zu vermeiden werden bei xxx:lanes-Schlüsseln
> alle Spuren betrachtet. Ausnahmslos. Was man sieht, das mappt man. Dann
> gibt es keine Unklarheiten und hoffentlich weniger Fehler.
>
> Übrigens sehe ich auch nicht die Notwendigkeit irgendwie die lanes=x
> Angaben mit jenen der xxx:lanes-Angaben in Verbindung zu bringen. Je nach
> dem was ich benötige und was vorhanden ist, kann ich das eine oder das
> andere Auswerten. Eine Notwendigkeit beides gleichzeitig auszuwerten sehe
> ich nicht. Wenn ich an einen Spurassistenten denke, dann würde ich zuerst
> die xxx:lanes-Angaben verwenden und wenn es diese nicht gibt die lanes=x
> Angaben (mit zusätzlichen Annahmen) und wenn es diese auch nicht gibt, dann
> eben nur sinnvolle Annahmen treffen. Wozu xxx:lanes und lanes=x
> gleichzeitig auswerten? Die einzige Anwendung dafür sehe ich bei
> Prüfprogrammen, z.B. lanes=x kann nicht größer sein als die Anzahl der
> Werte eines xxx:lanes-Schlüssels.
>
> bg,
> Martin
>
> P.S. Ich unterstelle, dass die lanes=x und xxx:lanes-Angaben vollständig
> sind. Wenn man z.B. nur turn:lanes=left|through|right hat und lanes=2, dann
> stimmt etwas nicht, denn es fehlt die Angabe welche Spur nicht für den
> motorisierten Verkehr ist. Aber dies ist ein unvollständiges Tagging und
> kein Mangel des Taggingschemas. Ich würde in so einem Fall übrigens davon
> ausgehen, dass lanes=2 falsch ist, da diese Angaben so wie sie aktuell in
> der Datenbank sind, gerade in Kreuzungs- und Ab/Auffahrtsbereichen oft
> inkonsistent sind, da bis vor kurzem noch kaum jemand einen Weg extra
> aufsplittete, nur weil hier kurz mal ein Verzögerungsstreifen o.ä. ist.
> Diese Situation bessert sich erst seit kurzem, vor allem seit wir auch ein
> Schema haben um erlaubte Spurwechsel anzugeben.
>
>
>
> Am 4. Dezember 2014 um 16:53 schrieb chris66 <chris66nrw at gmx.de>:
>
>> Am 04.12.2014 13:44, schrieb Martin Vonwald:
>>> Das Tagging - auch im Beispiel B1 - ist komplett konsistent. Die
>>> lanes-Schlüssel liefern dir die Anzahl der Spuren für den motorisierten
>>> Verkehr. Und die Werte in den xxx:lanes-Schlüssel liefern dir das
>> Layout(!)
>>> und die Eigenschaften aller Spuren.
>>
>> korrekt, so steht's auch im ursprünglichen Proposal:
>>
>> <
>> http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension
>>>
>>
>>
>> Chris