[Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)

steffterra steffterra at me.com
Mi Jul 28 15:11:06 UTC 2010


Am 28.07.2010 um 16:38 schrieb Simon Kokolakis:

> Am 25.07.2010 20:43, schrieb steffterra:
> 
>> - Manche versuchen das Problem zu umgehen, indem sie zwei ways für jede Fahrrichtung zeichnen, was aber nur bei baulicher Trennung korrekt wäre, und deshalb falsch ist. 
> 
> Das kommt auf die Interpretation des Objektes "way" an.

Daran scheitern sich die Geister. Es scheint aber einen weltweiten Konsens darüber zu geben, dass ein way in osm eine Straße repräsentiert und eben nicht eine Fahrspur. Das ist sicher geschichtlich zu sehen, daß man froh war, dass überhaupt eine Straße eingezeichnet wurde.
Daß das immer noch so gesehen wird, konnte ich in vielen persönlichen Gesprächen in unserer lokalen OSM-Gruppe und auch hier recherchieren. Hauptgrund dafür ist die visuelle Wahrnehmung des Objekts im Editor. Gestützt wird diese These auch dadurch, dass viele meinen, dass es völig ausreichend ist, alles mit tags und Relationen an _einem_ way abzubilden.

> Warum ist es falsch die einzelnen Elemente einer Straße als eigene
> oneways darszustellen?

Ich erweitere obige Begründung mit dem (für mich am verständlichsten) Argument der "baulichen Trennung". Im Wik ist z.B. definiert, dass bei baulicher Trennung der Fahrspuren einer Straße auch je ein way pro Fahrtrichtung gezeichnet werden _muß_. Das heisst im Umkehrschluss: Ohne bauliche Trennung: ein way.

Die baulichte Trennung teilt beide Fahrrichtungen so vn einander, dass man die Trennung in der Wirklichkeit auch sehen kann, da es nicht eine durchgehende Fahrbahndecke ist, sondern ein Grünstreifen oder andere bauliche Maßnahmen vorhanden sind. Da diese Trennung der Fahrbahnen auch Verkehrsregelungen automatisch nach sich zieht (man darf und kann halt nicht mehr wenden, etc.).

Wenn man nun Deiner Meinung nach grundsätzlich zwei ways zeichnen würde, dann impliziert das nicht nur die optische Wahrnehmung der baulichen Trennung, sondern erstellt nebenbei auch die Verkehrsregeln, wie wenn baulich getrennt wäre, dem aber nicht so ist, da durchgehende Fahrbahndecke. Die Folge ist, dass bei Abzweigungen und ähnlichem künstliche Verbindungen zwischen beiden Fahrspuren geschaffen werden müssten, die in der Realität so gar nicht vorhanden sind. Deshalb ein way für eine geschlossene Fahrbahndecke. Da es auch selten bauliche Trennungen zu Gehwegen und Radwegen gibt, wird hier ebenso verfahren: alles wird an dem einen way getaggt, ausser es ist ein Grünstreifen zwischen der Straße und dem Gehweg. Dann kann der Gehweg auch einzeln eingezeichnet und entsprechend getaggt werden.

> Im Prinzip ist dein vorgeschlagenes Modell ja nichts anderes als eine
> Gruppierung von einzelnen (one)ways..

Deshalb heisst mein Vorschlag ja auch so. Um aber deutlich zu machen, dass es eben keine bauliche Trennung gibt, sollte alles nicht zu per Relation oder wie auch immer in einer Gruppe zusammengefasst werden, sondern dies auch visuell im Editor für die optische Wahrnehmung mit einer gemeinsamen Hintergrundfarbe kenntlich gemacht werden. Zudem ist auch im Modell enthalten, dass zunächst immer nur der datenway sichtbar ist, da auf ihm auch die richtungsunabhängigen Tags wie die der Straßenart und des Namens liegen, was die Straße eindeutig identifiziert. Erst wenn man auf den datenway klickt "gehen die anderen ways/Fahrspuren auf" und man kann detaillierter bis zur Fahrspur wenn nötig fein säuberlich getrennt taggen und ist dabei völlig flexibel, da so auf einfache Weise alles abgebildet werden kann, was nötig ist.
Der Editor und später auch der Renderer tragen jedoch maßgeblich dazu bei, dass eine Gruppe von ways als eine Straße und nicht als mehrere verschiedene Parallelstraßen interpretiert wird.

> Gegenvorschlag:
> 
> Einzeichnen aller Straßenuntereinheiten (Fahrbahn, Fahrspur,
> Fahrradspur, Parkplätze, je nach dem wie detailliert man es will) als
> oneways. Wenn man unbedingt mitgeben will dass diese Elemente
> zusammengehören und eine (baulich ungetrennte) Straße darstellen dann
> gruppiert man sie in einer Relation. associatedStreet wäre da eine
> Möglichkeit.

kann es sein, dass Du damit das Proposal der Linienbündel wiedergibst?

Während dieses Threads bin ich mehrfach auf die Unterschiede meines Gruppierungs-Modells zum Linienbündel-Modell eingegangen, denn es hat auch Gründe, warum sich dieses nicht durchgesetzt hat. Und dass sind nicht der Editor und der Rednerer alleine.

Danke für Dein Feedback,
steffterra



Mehr Informationen über die Mailingliste Talk-de