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 <[email protected]>:
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
_______________________________________________
Talk-de mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-de
