[Talk-de] Einigkeit bei Linienbündeldiskussion (Re: Kreuzung Radweg)

[Sebastian Hohmann]

Dimitri Junker schrieb:
> Hallo,
> 
> 
>> Würdest du also statt einfach footway=left lieber immer explizit
>> footway=left:track schreiben wollen?
> 
> 
> Entsprechend meines right/left Proposals würde ich die Keys/values 
> seitenunabhängig lassen wie bisher und bei Bedarf, also wenn er nur 
> einseitig vorkommt ein right oder left hinzufügen, also bei syymetrischen 
> Fahrradwegen alles so lassen wie bisher.
> 

Zumindest hier in der Gegend habe ich die Erfahrung gemacht, dass 
symmetrische Fahrradwege praktisch nicht vorkommen (also track oder lane 
auf beiden Seiten).

>> Eigentlich fände ich cycleway=both auch etwas einleuchtender, da es
>> direkt zeigt, dass es auf beiden Seiten ist. cycleway=track sagt das
>> nicht aus.
> 
> 
> Da es aber schon viele cycleway=track gibt und auch in Zukunft nach einer 
> ggf. erfolgen neuen Empfehlung noch viele es so taggen werden sollte 
> cycleway=track
> weiterhin bedeuten, daß es auf beiden Seiten einen abgesetzten Fahrradweg 
> gibt. Und da auch Sonst die OSM-Daten bisher immer eine symetrische Straße 
> annehmen (Geschwindigkeitsbeschränkung, Spurzahl,...) sollten wir das hier 
> nicht ändern, deshalb halte ich both außer in Einbahnstraßen mit 2 
> Fahrradwegen für unnötig, sollte aber erlaubt sein.
> 

Mein Proposal hat doch überhaupt nichts mit Einbahnstraßen zu tun. 
'both' bedeutet auf 'beiden Straßenseiten' nicht 'in beide Richtungen'. 
cycleway=both wäre damit gleichbedeutend mit cycleway=track, deswegen ja 
auch die Überlegungen bezüglich der Kompabilität.

>> Etwas problematisch finde ich auch, dass bei cycleway=track/lane im Wiki
>> nichtmal dabeisteht, dass der Radweg damit auf beiden Seiten ist.
> 
> 
> Ist ja wie gesagt bei allen OSM-Tags so.
> 

Nicht direkt. Es könnte auch bedeuten 'da ist ein Radweg auf dieser 
Straße', aber nicht zwangsläufig 'auf beiden Seiten der Straße ist ein 
Radweg'. Ich habe schon einige Straßen mit cycleway=track gefunden, bei 
denen nur auf einer Seite ein Radweg verläuft. Insofern neige ich eher 
dazu ein neues Schema zu entwickeln und nicht ein unklar definiertes 
weiterzubenutzen.

>> Ich sehe kein Problem darin einfach die gesamten Schlüssel und Werte
>> nach left/right zu durchsuchen
> Und irgendwann wird dann aus einer "Human right street" eine Human Left 
> Street". Auch wenn da gefragt wird, es gibt fragen die man genervt jedesmal 
> wegklickt. Aus meiner Programiererfahrung bin ich der Meinung wenn ein 
> Teilstring sicher erkannt werden soll muß er an einer bestimmten Stelle 
> stehen und durch ein Sonderzeichen abgegrenzt werden.
> 
> 
>> Zumal man Wege auch nicht so häufig dreht.
> 
> 
> Aktiv nicht, aber Wege verbinden kommt häufig vor, und dabei werden sie ggf. 
> gedreht.
> 
>> Davon ausnehmen könnte man auch Dinge die freien Text enthalten wie
>> note, FIXME oder name.
> 
> 
> Genau da ist das Problem, entweder muß der Editor eine Positivliste haben wo 
> er nach right/left sucht oder er muß eine Negativliste haben wo er es nicht 
> soll. In beiden Fällen muß diese Liste regelmäßig aktualisiert werden. Dies 
> ist bei einer eindeutigen allgemeinen Methode überflüssig. 
> 

Bei meinem Schema wäre das ein "left/right" im Wert und ein 
"*:left*/*:right*" im Schlüssel. Das dürfte doch wohl kaum in anderem 
Kontext vorkommen.

Die allgemeinere Lösung habe ich nur vorgeschlagen, da es immer mehr 
Nachfrage nach richtungsabhängigen Tags gibt. Und da jeder bei OSM sein 
eigenes Süppchen kocht, wird man da im Endeffekt wohl kaum ein 
einheitliches Schema dafür haben. Auch wenn ich Bestrebungen dahingehend 
gut finde und unterstütze, scheint sowas schwer durchzusetzen zu sein.

>> Dagegen bin ich, da es die Hierarchie durchbricht. Ich finde es besser
>> wenn alle Schlüssel die sich auf cycleway beziehen auch mit cycleway
>> beginnen.
> 
> 
> Auf der Proposal-Seite hatte ich 2 Varianten vorgeschlagen, auf Dein Bsp 
> angeppaßt:
> cycleway.width:left=1.5
> cycleway.width=left:1.5
> 
> Dürfte beides hirarchisch OK sein.
> 

Wie bei deinem Proposal auch jemand erwähnte kann man bei der zweiten 
Variante aber nur die Breite für einen der beiden Radwege angeben, da 
ein zweiter 'cycleway.width'-Schlüssel nicht angegeben werden kann.

Also das geht:
cycleway:left.width=1.5
cycleway:right.width=2.5

Das aber nicht:
cycleway.width=left:1.5
cycleway.width=right:2.5

>> Allerdings könnte man dann auch so Scherze machen wie:
>>
>> both:cycleway=track
>> left:cycleway=lane
>> right:cycleway=track
>> right:footway=track
>>
>> Was bedeutet das dann?
> 
> 
> Das kannst Du immer unabhängig wo das left steht.
> 

Nicht ganz. Bei meinem Proposal ist mit cycleway=both/left/right/none 
und entsprechend footway immer erstmal mit EINEM Schlüssel pro Wegtyp 
klar definiert was vorhanden ist.

Definiert man die Wege aber mit einem left/right/both im Schlüssel, hat 
man plötzlich drei mögliche Schlüssel pro Wegtyp, die sich gegenseitig 
widersprechen können. Das könnte man durch eine entsprechende Definition 
zwar umgehen, aber schön finde ich es nicht.

>> Eigentlich ein unlogischer Tag, eher eine Behelfslösung. Sowas wie
>> oneway:bicycle=no wäre doch viel konsistenter und logischer.
> 
> Wie gesagt würde ich cycleway=opposite durch
> cycleway:both=track/lane
> oder
> irgendein oneway=NO ersetzen. Je nachdem ob es einen fahrradweg für beide 
> Richtungen oder 2 Fahrradwege gibt.
> 

Wiegesagt, mein Proposal hat mit Einbahnstraßen nichts zu tun. Wenn da 
ein Radweg ist, dann darf man da sowieso fahren (in welche Richtung der 
Radweg gilt ist eine andere Geschichte). Wenn kein Radweg vorhanden ist, 
dann benutzt man eben zur Zeit cycleway=opposite, was bis auf den 
cycleway-Schlüssel aber nichts mit einem Radweg zu tun hat.

Gruß