[Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
steffterra
steffterra at me.com
So Aug 1 09:15:45 UTC 2010
Am 31.07.2010 um 21:39 schrieb Tobias Knerr:
> Am 27.07.2010 17:56, schrieb steffterra:
>>
>> Am 27.07.2010 um 15:09 schrieb Tobias Knerr:
>>> Daher eine prinzipielle Frage: Repräsentiert ein Way in deinem Modell
>>> * eine Fahrtrichtung
>>> oder
>>> * eine Fahrspur bzw. Gruppe von Fahrspuren
>>
>> Das Modell kann beides.
>
> Diese Eigenschaft macht es m.E. etwas verwirrend. "Ein zusätzlicher Way
> repräsentiert eine Fahrspur" wäre beispielsweise deutlich einfacher zu
> erklären (und im Editor darzustellen) als ein "kommt darauf an".
Aus dem Zusammenhang heraus gesehen stimme ich Dir zu. Doch wenn man es aus sicht des Bedarf siehst: Wenn man richtungsabhängige Tags nicht nötig wären auf _einem_ way, wozu dann Fahrspuren für jede Richtung erstellen? Einfache Logik, oder?
Ebenso grundsätzlich zur Fahrspur. Wenn die Fahrspuren sich nicht unterscheiden, wozu diese dann zeichnen, wenn ein lanes=2 es auch tun würde? Auch einfache Logik, oder?
> Diese Beurteilung meinerseits liegt natürlich auch daran, dass ich
> bekanntlich :forward/:backward nicht als echtes Problem sehe, so dass
> die Fahrspurdarstellung aus meiner Sicht der einzige gute Grund für die
> Einführung eines Linienbündel-Modells ist. ;)
Sehr gute Selbsteinschätzung :-)
>> Beispiel 1: in der "Wirklichkeit" sieht unsere Beispielstraße so aus: ganz normale Straße mit zwei Fahrspuren (pro Richtung eine Fahrspur) ohne Unterschiede, egal aus welcher Richtung man kommt. Geschwindigkeitsbegrenzung: 50km/h.
>> [...]
>> Beispiel 2: die gleiche Straße bekommt eine Geschwindigkeitsbeschränkung von 60 km/hverpasst, die nur in einer Richtung (z.B. in Richtung Süden) gilt. Eingezeichnet ist der way in JOSM von Nord nach Süd. Ausserdem werden Schilder für die Fahrrichtung aufgestellt, da es eine neuralgische Verbindugnsstraße wird. Die Süd->Nord-Richtung führt nach Hamburg, die Nord-Süd-Richtung nach München und ist auch so ausgeschildert (Es ist ein Beispiel ;-)
>> [...]
>> -way (Nord->Süd): maxspeed=60, destination=München
>> -daten-way: highway=secondary, name=Beispielstraße
>> -way (Süd-Nord): maxspeed=50, destination=Hamburg
>
> Beispiel 2a:
>
> Dasselbe, aber die Straße hat keine getrennten Fahrspuren - ist also
> einspurig. Wird das dennoch mit zwei Zusatzways dargestellt?
Wie jetzt - eine Spur? Dann muss es ja eine Einbahnstraße sein, oder meinst Du jetzt einen Feldweg? Ich bitte doch davon abzusehen, richtungsabhängige Tags an Feldwegen zu plazieren. Scherz beiseite. Aus Spaß wurde Ernst: Welche Straßentypen meist du - Wo hat man denn nur eine Fahrspur, auf der es Gegenverkehr gibt, die gleichzeitig richtungsabhängige Tags benötigt? Welche richtungsabhängigen Tags wären dass beispielsweise? Bitte beachte, dass nicht jede Straße, die _keine_ Mitellinien-Strichelchen besitzt automatisch "einspurig" ist. Darauf können selbstverständlich 2 Fahrzeuge, die sich entgegenkommen nebeneinander fahren, ohne dass einer davon zur Hälfte in den Graben ausweichen muss. Und selbst wenn so eine Straße dann von einem Radweg auf einer Seite begleitet wird, dann ist dieser baulich getrennt, weil sonst dies immer als Ausweichmöglichkeit bei Gegenverkehr genutzt würde .... Ich bin gespannt auf Dein Beispiel.
>> Beispiel 3: die gleiche Straße wird um eine Fahrspur in Richtung Norden->Süden erweitert, auf der anderen Seite jedoch nicht
>> [...]
>> Beispiel 4: die gleiche Straße bekommt auf der äußersten Fahrspur der Richtung Nord->Süd zusätzlich zur Fahrspur aus Beispiel 3 noch einen Radweg verpasst, weil diese Straßenseite so gefährlich wurde.
>> [...]
>> -> in meinem Modell:
>>
>> -way (außen eingezeichnet Nord->Süd): maxspeed=60, destination=München, cycleway=lane, bicycle=designated
>> -way (innen eingezeichnet Nord->Süd): maxspeed=60, destination=München
>> -daten-way: highway=secondary, name=Beispielstraße
>> -way (Süd->Nord): maxspeed=50
>
> Beispiel 4a:
>
> Nehmen wir weiter an, die äußere Fahrspur Nord->Süd ist 3m breit, der
> Radweg daneben 1,5m. Außerdem möchte ich die Oberfläche des Radwegs per
> surface/smoothness-Tags beschreiben. Wie werden diese diese
> Informationen ergänzt?
So, wie man es an _einem_ way auch machen würde. Nur dass Du das _jedesmal_ dann nötige :forward weglassen kannst, weil ja schon klar ist, auf welchem Richtungsway Du das taggst.
> Beispiel 4b:
>
> Nehmen wir an, es gibt einen Parkstreifen zwischen dem Radweg und der
> Fahrbahn. Wie sieht die entsprechende Ergänzung aus?
Du meinst nicht Fahrbahn, sondern Fahrspur. Denn die Fahrbahn ist das ganze, sofern keine bauliche Trennung zwischen der Radfahrspur, dem Parkstreifen oder ähnlichem vorliegt.
Also kommt es darauf an, ob eine bauliche Trennung (z.b. durch Bäume zwischen den Parkständen) vorliegt oder nicht. _Wenn bauliche Trennung_ , ist es klar, wie bisher auch: dann hat der Radweg eine eigenen way "verdient" und dessen tags dran, parking:lane an den Richtungsway. Doch dann darf der Radweg nicht mit in die Gruppe, da er ja durch die bauliche Trennung kein Teil der Fahrbahn mehr ist.
> Beispiel 4c:
>
> Anders als bei 4b ist der Radweg jetzt zwischen der Fahrbahn und dem
> Parkstreifen. Wie unterscheidet sich dieser Fall vom Tagging zu 4b?
4b und 4c unterscheiden sich ausschließlich durch die Lage von Radweg und Parkstreifen. Wenn man diesen Unterschied darstellen möchte oder muss, dass der Renderer das richtig interpretieren kann, wohin der was rendert, dann muss man für je beides einen eigenen way zeichnen und ihn in die Gruppe mit aufnehmen. Über tags liese sich das natürlich wieder mit left/right darstellen. Da das Modell aber Fahrspurtagging ermöglicht, würde es Sin machen, je einen eigenen way zu zeichnen, der in die Gruppe mit aufgenommen werden muss (da ja keine bauliche Trennung vorliegt).
Das gleiche gilt auch, möchte man eine Busspur extra eingezeichnet wissen, da diese ja auch zwischen zwei normalen Fahrspuren liegen kann. Abbiegespuren ebenso usw.
Aber gleich vorweg: ich kann mir beim besten Willen keinen Fall vorstellen, bei dem Parkstände/Radweg/Tram-Spur, etc. mitten auf der Straße _ohne bauliche Trennung_ (!!!) vorliegt. Falls doch einmal, dann muss auch dafür ein eigener way her.
btw, mir fällt soeben auf, dass ich in meinen Beispielen einen wichtigen tag vergessen hatte: oneway=yes muss natürlich an jeden Richtugnsway ;-) Wenn der Radweg in beiden Richtungen erlaubt ist, gibts dafür den opposite-key, und falls der Radweg einen eigenen way hat wegen einer baulichen Trennung, dann hat er ein oneway=no, gar keinen oneway-tag.
steffterra
Mehr Informationen über die Mailingliste Talk-de