User:Jongleur/Bürgersteige

Problemstellung

Bürgersteige, also Fußwege als Teil von bzw. direkt entlang von Straßen, werden in der OpenStreetMap bisher selten erfasst. Wenn sie erfasst werden, dann nicht immer als eigene Geometrie, sondern häufig als Eigenschaft der Straße (vgl. Proposed_features/Advanced_footway_and_cycleway. Dies hat seine Berechtigung. Es erlaubt, ohne zusätzliche Geometrie Eigenschaften für Fußwege anzugeben.

Für einige Anwendungen ist dies aber nicht ausreichend. Einige Gründe dafür:

• Hindernisse wie Poller befinden sich oft NUR auf dem Bürgersteig, Schranken dagegen z.T. NUR auf der Straße. Dies ist aber nicht zwingend. Um dies adäquat anzugeben, müsste barrier=* erweitert werden (z.B. barrier:sidewalk:left=*, barrier:sidewalk:right=*, barrier:*=* (?!))
• Querungsstellen nur als Punkt auf der Straße zu taggen, erlaubt es nicht, die einzelnen Seiten der Querung zu modellieren (vgl. User:Jongleur/Anforderungen#Fußwege)
• abweichende Geometrie (z.B. Führung rund um einzelne Bäume etc.) lässt sich nicht modellieren

Durch eine eigene Geometrie auch für Bürgersteige sind diese Probleme lösbar, es ergibt sich ein neues Problem: Die Zuordnung.

Angenommen, es existiert ein Fußweg parallel zu einer Straße. Dieser Fußweg kann ein Bürgersteig sein, er könnte aber ebensogut ein separater Fußweg sein. Diese Unterscheidung ist allein aus den Daten nicht möglich. Heuristisch könnte der Abstand genutzt werden. Bei fehlender Breitenangabe von Straße und Fußweg (vgl. width=* ist dies aber ungenau.

Lösungsvorschlag

• Eintragen des Bürgersteigs als eigene Geometrie.
• Tagging des Bürgersteigs wie bei Wegen sonst üblich:
  • highway=footway (in D. der Standard ohne sonstige Auszeichnung)
  • highway=path foot=designated bicycle=designated segregated=yes/no (in D. für geteilte oder gemeinsame Fuß/Radwege)
  • highway=footway bicycle=yes (in D für Fußwege mit Zusatzschild "Fahrräder frei")
  • (NEU) sidewalk=yes (gibt an, dass es sich um einen Bürgersteig handelt)
  • (NEU) name=* (Name der Straße, zu der der Fußweg gehört

Vorteile

• Rendering explizit ausschaltbar: sidewalk=yes nicht rendern
• In Kombination mit Querungen routingfähiges Netzwerk für Fußgänger-Routing möglich
• Relationen nicht notwendig
  • einfache Pflege der Daten
  • einfaches Tagging-Schema/leicht zu erfassen
• Anwendungen, die separate Fußwege interpretieren, können diese Lösung ohne Anpassungen nutzen.
  • das ist auch in Kombination mit der Interpretation des Proposed_features/Advanced_footway_and_cycleway) ohne Änderungen möglich (nur beides ist doof (Attribute und explizites Tagging)

Nachteile

• etwas höherer Erfassungsaufwand
  • Durch "Abwärtskompatibilität zu Proposed_features/Advanced_footway_and_cycleway nicht tragisch, da mächtiger.
• Verschieben im Editor schwierig: Beim Verschieben einer Straße ist darauf zu achten, auch die Fußwege anzupassen. Da vermutlich häufig Elemente relativ zu vorhandener Geometrie eingetragen werden (z.B: Bushaltestellen am Straßenrand), ist dies kein diesem Proposal eigenes Problem.

Kommentare

warum nicht lane group?

Das ganze wird doch schon von Proposed_features/lane_and_lane_group erschöpfend behandelt. Wie ist dein Proposal demgegenüber aufgestellt? --Bk 20:50, 12 August 2010 (BST)

Der key sidewalk ist schon vergeben

Nämlich durch das Proposal sidewalk. sidewalk=yes an einem footway hieße dann, dass der Bürgersteig einen Bürgersteig hat. --Bk 20:50, 12 August 2010 (BST)