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

Mario Salvini salvini at t-online.de
Mi Dez 31 19:41:28 UTC 2008


der Workaround mit dem JOSM-lane-plugin wäre

- Weg auswählen.
- lane links hinzufügen
- lane rechts hinzufügen
- attribute setzen
- fertig

und damit hätten wir eine ziemlich genaue Darstellung der Realität im 
Rahmen der möglichen Genauigkeit (>5m)
Dann könnte man jeder Spur Atrribute wie Breite, maxspeed, direction, 
etc. geben.
Wenn der Radweg dann einen krassen Schlenker (z.B. weil er in einer 
Spirale ein Level hoch runter (Tunnel/Brücke) geführt wird, oder einfach 
da chaotisch sich von der STraße abwendet, dann zeichnet man ab dieser 
Stelle eben einen seperaten cycleway. Manchmal verstehe ich nicht, warum 
die Leute so komplitziert denken ;-)

Guten Rutsch euch allen :-)

--
 Mario

Sebastian Hohmann schrieb:
> Dimitri Junker schrieb:
>   
>>> Versteh ich nicht. Das gibt doch nur an auf welcher Seite der Radweg
>>> liegt. Oder bemängelst du damit, dass man zusätzlich noch
>>> cycleway.type=lane angeben muss?
>>>       
>> Bisher haben wir zum Key cycleway u.a. track und lane. Das von Dir 
>> vorgeschlagene right/left ist keine Alternative dazu sondern ein Zusatz. Man 
>> muß angeben können, daß der rechte Fahrradweg ein lane und der linke ein 
>> track ist. Deshalb z.B.
>> cycleway=left:track
>> Ein
>>
>>     
>>> cycleway.type=lan
>>>       
>> würde da auch nicht helfen.
>>
>>     
>>> Natürlich könnte man auch optional einen Wert wie left:track definieren,
>>> um gleich beide Informationen auf einmal angeben zu können.
>>>       
>> Man muß sie zusammen angeben, weil es ja 2 Fahrradwege geben kann.
>>
>>     
>
> Also wenn es dir nur darum geht, dann ist es kein Problem. 
> cycleway.type=lane setzt den Typ auf alle cycleways, egal ob man nun 
> right/left oder auch both angegeben hat. Möchte man nur für eine Seite 
> den Typ angeben (das macht nur bei 'both' Sinn), dann kann man dies mit 
> cycleway:right.type=lane machen.
>
> Das Ganze ist halt quasi hierarchisch aufgebaut:
>
> both
> - right
> - left
>
> Lässt man die Angabe von right/left im Schlüssel weg, wird automatisch 
> 'both' angenommen. cycleway.width=2.5 setzt also die Breite für 'both' 
> und 'vererbt' es an 'right' und 'left'. Was zuvor mit 
> cycleway=right/left/both/none angegeben wurde ist dabei egal, es setzt 
> einfach die Breite für beide Seiten. Wenn auf einer Seite keiner 
> vorhanden ist, wirkt es sich logischerweise eben nur auf eine Seite aus.
>
> Gibt man keinen 'type' an, wird automatisch angenommen, dass es sich um 
> einen 'track' handelt.
>
> Willst du allerdings den Typ ohne ein extra-Tag angeben, könnte man 
> natürlich auch sowas wie left:lane benutzen. Allerdings würde man dabei 
> halt etwas aus dem Rahmen fallen im Vergleich zu footway=right/left/both 
> das auch Teil des Proposals ist und bei dem 'lane' wohl eher selten 
> vorkommt. Nimmt man weiterhin zusätzlich an, dass ein Weglassen des 
> Types automatisch ein 'track' ist, hätte man eben statt 4-Hauptwerten 
> plötzlich 7: right/left/both/none/right:lane/left:lane/both:lane.
>
> Zusätzlich müsste man dann noch die bisherigen cycleway=track/lane mit 
> einberechnen, die einen Radweg des jeweiligen Typs auf beiden Seiten 
> definieren. Man hat dann also z.B.:
>
> - cycleway=lane für 'lane' auf beiden Straßenseiten
> - cycleway=both für 'track' auf beiden Straßenseiten
> - cycleway=right:lane für 'lane' rechts
> - cycleway=right für 'track' rechts
> Allerdings wären andere Schreibweisen wohl auch gültig, also:
> - cycleway=right:track für 'track' rechts
> - cycleway=both:track für 'track' auf beiden Straßenseiten
> usw.
>
> Das kann man natürlich auf die Spitze treiben. Und da sind noch nichtmal 
> footway und path mit dabei. Das kommt halt davon wenn man zum einen 
> versucht bisherige Tags zu berücksichtigen und es zusätzlich auch noch 
> versucht 'einfacher' zu machen indem viele Werte impliziert werden. :)
>
> Ob man das will ist halt die Frage, das macht irgendwie alles noch 
> komplizierter, sowohl für den Mapper als auch den Benutzer. Wobei der 
> Mapper es natürlich auch als angenehmer weil kürzer empfinden könnte. 
> Aber wiegesagt, irgendwie fällt es so aus dem Rahmen. Die Renderer 
> könnte z.B. anstatt Regeln für alle Fälle zu erstellen die Wege vor dem 
> Rendern in ein einheitliches Schema umschreibem, so wie sie es eben 
> brauchen.
>
> Alternativ könnte man natürlich auch ganz streng sein und sagen: Wir 
> geben immer einen Typ an. Also:
>
> - cycleway=lane für 'lane' auf beiden Straßenseiten
> - cycleway=track für 'track' auf beiden Straßenseiten
> - cycleway=right:lane für 'lane' rechts
> - cycleway=right:track für 'track' rechts
>
> Somit hätte man das bisherige Tagging beachtet und gleichzeitig nicht 
> mehr so viele Ausnahmen. Oder man macht es halt einfach so wie in meinem 
> Proposal. Was ist nun besser? Man weiß es nicht. :)
>
>   
>>> cycleway=none/both:track/right/.. sollte dann aber auch möglich sein.
>>>       
>> Der Nutzen von none ist mir noch nicht klar, both wäre z.B. bei 
>> Einbahnstraße sinnvoll als bessere Alternative zu cycleway=opposite
>>
>>     
>
> 'none' sagt einfach aus, dass sich dieser Typ nicht an der Straße 
> befindet. Nach dem aktuellen Proposalstand macht das aber nur bei 
> footway Sinn, da footways bei einigen highway-Typen implizit vorhanden 
> sind (bei residentials zum Beispiel). Wenn auf solchen Straßen dann doch 
> kein Fußweg vorhanden ist, kann man footway=none angeben.
>
> 'both' bezieht sich auf 'beide Seiten', nicht auf 'beide Richtungen'. 
> Insofern ist es keine Alternative zu cycleway=opposite. Eine Alternative 
> dazu wäre eher sowas wie oneway:bicycle=no, also ein Tag das die 
> Einbahnstraße gezielt für Fahrräder aufhebt.
>
>   
>>> Könnte man nicht mal schauen wo bei meinem Vorschlag die Schwachstellen
>>> sind
>>>       
>> I.W. habe ich ihm ja zugestimmt.
>>
>>     
>
> I.W.?
>
> Gruß
>
> _______________________________________________
> Talk-de mailing list
> Talk-de at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>
>   





Mehr Informationen über die Mailingliste Talk-de