Vorschlag Mittelstreifen und Seitenbereiche
Hier wird ein Vorschlag für die Notation von Anlagen auf Mittelstreifen und in Seitenbereichen beschrieben, der nur mit wenigen neuen Tags auskommt. Eine andere Alternative ist hier beschrieben.
Problematik
Vor allem für Fahrradkarten stellt sich die Frage, wie man straßenbegleitende Radwege in OSM aufnimmt. Die bisherige Notation ist nur sehr beschränkt dafür geeignet, differenziert Informationen zu solchen Radwegen aufzunehmen. Einerseits fehlt die Möglichkeit, nach linkem und rechten Radweg zu unterscheiden, anderseits ist es nur beschränkt möglich, diesen Wegen verschiedene Eigenschaften zuzuordnen.
Das Gleiche gilt auch für andere Dinge in Seitenbereichen, so z.B. für Gehwege oder Reitwege oder wenn man weiter spinnt Parkstreifen, Grünstreifen, Baumreihen oder Ähnliches. Anspruch sollte erstmal nicht sein, weltweit all diese Wege mit allen deren Eigenschaften komplett aufzunehmen. Das wird vermutlich nicht zu leisten sein. Der Anspruch sollte vielmehr der sein, in OSM die Möglichkeit dafür einzurichten, themenbezogene Karten und Routingfunktionen da anzubieten, wo sich Menschen finden, die bereit sind diese Daten aufzunehmen und zu pflegen.
In unseren Fahrradklub diskutieren wir gerade, wie wir einen neuen gedruckten Fahrradstadtplan erstellen können. Bisher haben wir dazu eine Kartengrundlage der Stadt verwendet und per mühsamer Handarbeit kompizierte Tabellen ausgefüllt, die die Radverkehrsanlagen und ihre Qualität beschreiben. Einerseits suchen wir nach einer leichteren Bearbeitungsmöglichkeit, idealerweise über eine grafische Weboberfläche, anderseits wünschen wir uns eine Möglichkeit, dass unsere mühsam aufgenommenen Informationen durch einen breiten Nutzerkreis gepflegt wird, so dass sie immer aktuell sind. OSM könnte dafür eine Lösung sein, in Frage kommen aber auch andere Möglichkeiten, wo die Rechte an den Daten bei uns verbleiben würden.
Neben Fahrradstadtplänen sind auch andere Anwendungen denkbar, z.B. Stadteilkarten fürs Parken oder für den Einkauf zu Fuß, Reitkarten oder Anwendungen, auf die wir heute noch gar nicht kommen. Dafür ist das derzeitige Notationssystem von OSM aber zu starr und unflexibel.
So gibt es aus meiner Sicht keine grundsätzlich befriedigende Lösung. Benutzt werden meist zwei grundsätzliche "Workarounds", die beide irgendwie gehen, aber beide auch gravierende Nachteile haben:
1. Hilfslösung: Straßenbegleitende Radwege als eigene Wege aufnehmen
Dieser Ansatz löst das Problem, dass es derzeit nicht möglich ist, Radwegen beliebige Eigenschaften zu geben und diese richtungsbezogen zu unterscheiden. Die Daten können so recht sauber aufgenommen werden. Für einige scheint dewegen das Problem grundsätzlich gelöst. Ist es aber nicht, denn man muss auch bedenken, wie die Rendermaschine vorgehen soll, um die Daten darzustellen.
Das derzeitige Ergebnis der Radfahrerkarte ist furchtbar, die Radwege überlagern auf unübersichtliche Art und Weise die Straßendarstellung. Richtig wäre es, wenn die Radwege unabhängig von der Zoomstufe neben die Straßen gezeichet würden. In gröberen Maßstäben müsste vielleicht nur noch anhand von Straßenfarben dargestellt werden, ob eine Straße Radverkehrsanlagen hat.
Dazu muss die Renderingmaschine wissen, zu welcher Straße der Radweg gehört. Entweder wird vorgeschlagen, das über "Relations" zu lösen (*1.A*) oder es wird davon ausgegagen, dass die Programmierer der Renderermaschine schon eine Lösung finden werden, wie automatisch nahe liegende Radwege als straßenbegleitende Radwege erkannt und dargestellt werden (*1.B*).
Ansatz: Verbindung Radverkehrsanlage zur Straße über Relations-Objekte
Damit ließe sich das Problem umgehen. Es wäre meines Erachtens aber doch nur eine Hilfslösung und zudem eine aufwändige. Bisher werden Relations in Sachen Radwege vor allem dafür verwendet, die Kanten von ausgeschilderte oder andwerweitig beworbenen Wegen zusammenzufassen, damit sie in der Karte entsprechend dargestellt werden können. Relations zusätzlich nun auch für die Zuordnung der Straßen zu Radwegen zu verwenden, birgt die Gefahr der Unübersichtlichkeit, da zwei grundverschiedene Aufgaben mit den selben Mittel gelöst werden.
Jede Relation ist ein neues Objekt und will man alle Radwege einer Stadt den Straßen zuordnen, an denen sie verlaufen, so braucht man eine Unzahl solcher Objekte. Das macht einerseits viel Arbeit und anderseits recht unübersichtlich. Zudem scheint das Eingeben der Relations aufwendig oder schwierig, sonst würden das heute sehr viel mehr Leute machen.
Zu hoffen, dass sich später jemand findet, der für jeden Straßenabschnitt eine Relation erstellt, finde ich nicht gut. Eine solche umfangreiche Datennachbearbeitung von Wegen, die man nicht selber aufgenommen hat, ist wenig attraktiv. Deswegen glaube ich, dass das lange liegenbleiben wird. So etwas sollte bereits bei der Datenaufnahme gemacht werden, aber ich glaube, dass viele gar nicht wissen, was Relations sind oder wie man diese verwendet (ich so richtig auch nicht).
Zudem halte ich es auch logisch gesehen nicht für richtig. Straßenbegleitende Radwege, Radfahr- oder Parkstreifen, Reitwege und Gehwege sind Teil des Straßenzuges, sie haben ja auch den selben Namen. Diese als eigene Verkehrszüge zu erfassen widerspricht der Wahrnehmung in der Realität. Teilweise sind sie nur durch einen Farbstrich voneinander getrennt.
Probleme mit Relations könnten meines Erachtens dann entstehen, wenn Radweg und Straße nicht die gleiche Anzahl von Knoten haben oder die Knoten an unterschiedlichen Orten sind. Dann könnte die Zuordnung über Relations schwierig werden, oder?. Ggf. müsste das dann die Renderingmaschine erkennen und die Wegekanten der Straße entsprechend teilen. Das ist vermutlich recht aufwendig zu programmieren und wird wohl nicht so schnell passieren. Besser wäre es, die Notation anzupassen, um solche Probleme zu vermeiden.
Ansatz: Verbindung Radverkehrsanlage zur Straße durch die Renderingmaschine
Das finde ich noch problematischer, denn hier muss die Renderingmaschine erraten, ob ein Radweg zu einer Straße gehört oder nicht. Problematisch wird das vor allem dann, wenn mehrere Straßen dicht beieinander liegen. Hier wird es fast zufällig, zu welcher Straße der Radweg zugeordnet wird.
Sicher wird sich eine Lösung finden lassen, die in 90% der Fälle richtig funktioniert. Gerade aber die restlichen 10% werden ein Problem für die Qualität und die Nutzbarkeit der Karten werden und somit für die Akzeptanz von OSM insgesamt.
2. Hilfslösung: neue Tags einführen für rechten und linken Radweg und für Eigenschaften des rechten und linken Radweges
Hiermit ließen sich eigentlich alle Probleme lösen, der Renderingmaschine wird die Zuordnung sehr leicht gemacht und die Eingabe ist einfach. Lediglich beim Drehen von Kanten muss sichergestellt werden, dass der Editor eine Warnmeldung ausgibt und fragt, ob die Daten der Radwege rechts/links auch gedreht werden sollen.
Diese vorgehensweise hat aber ein Problem. Auch die Pferdesportler, Skater, Parkplatzsuchenden usw. werden für die Eigenschaften ihrer Wege und Flächen eigene Tags haben wollen. Jedesmal, wenn jemand eine neue Nutzung einfällt, müssen neue Tags generiert werden. Wenn man das ordentlich machen will müssen die vorher breit diskutiert werden - ein sehr unflexibler Ansatz. Das schlimme daran ist aber vor allem, dass wir zum Schluss eine Unzahl neuer Tags haben, die es eigentlich schon gibt, nur eben nicht für Seitebereiche, darunter leidet extrem die Übersichtlichkeit! Schon heute ist die Anzahl der Eigenschaftentags schon so groß, dass es nicht leicht ist, alles zu überschauen. Wichtig für die Attraktivität und Akzeptanz des Datenaufnehmens ist aber eben genau die Überschaubarkeit und eine kurze Einarbeitungszeit.
Zurecht wird deswegen dieser Vorschlag von vielen abgelehnt.
Vorschlag einer erweiterten Notation
Die Lösung liegt meines Erachtens in einer Kombination beider Ansätze. Anbei mein Vorschlag einer dahingehenden erweiterten Notation. Sie ist mit der bisherigen kompatibel, soll diese aber um die Möglichkeit erweitern, Angabe zu Wegen und deren Eigenschaften in den Seitenbereichen zu machen, ohne dass dafür eine Unzahl neuer Eigenschaftentags erfunden werden müssen. Für eine Straße können dann beliebig viele Wege in den Seitenbereichen definiert werden. DiDbie Eigenschaften werden dann wie bisher entweder der Straße selber, oder durch die erweiterte Notation einem der definierten Wege zugeordnet.
Die Notation gibt die Möglichkeit, Wege nur für eine Straßenseite zu definieren oder für die Straßenseiten unterschiedliche Eigenschaften zu setzen. Nach dem bisherigen Verfahren eingetragene Eigenschaften gelten dabei immer für beide Straßenseiten.
Die Notation ähnelt der Schreibweise objektorientierter Programmierung:
Grundobjekte
- main. = Grundlage alle Tags, welche die Hauptfunktion betreffen (sollte weggelassen werden!)
- left. = Grundlage für alle Tags, die Anlagen der linken Seitenbereiche betreffen
- right. = Grundlage für alle Tags, die Anlagen der rechten Seitenbereiche betreffen
- middle. = Grundlage für alle Tags, die Anlagen zwischen den Hauptfahrbahnen betreffen
ggf. auch
- both. = Grundlage für alle Tags, die Anlagen der rechten und linken Seitenbereiche gleichermaßen betreffen
Das main. würde ich grundsätzlich weglassen. Alles, das kein left., right. oder ggf. both. hat, ist dann automatisch main. und betreffen somit die Hauptfunktion der Straße, so wie bisher. Somit bleiben alle bestehenden Tags erhalten und kompatibel zur erweiterten Notation.
Objekte in den Seitenräumen rechts und links
left, right. und both. alleine sagen noch nichts aus. Da es mehrere Dinge neben der Hauptfahrbahn (oder Hauptgehbahn) geben kann, muss es die Möglichkeit geben, mehrere Dinge zu definieren. Im Extremfall können das z. B. sein: Parkstreifen, Grünstreifen mit Bäumen, Radweg, Gehweg _und_ daneben noch einen Reitweg:
- left.parkinglane=true left.treelane=true left.cycleway=true left.footpath=true left.horspath=true
Im Prinzip kann neben der Straße alles definiert werden (z.B. auch eine im Seitenraum fahrende Straßenbahn), außer dem, was die Straße schon selber ist. Also eine Autobahn mit einer Autobahn rechts daneben sollte es nicht geben. Eine Radweg (oder Fahrradstraße) mit Gehweg daneben ist aber schon vorstellbar oder sogar ein breiter Gehweg mit einseitigen Radweg (z.B. neben einer Fußgängerzone). Was dann Hauptnutzung ist und was Seitenraumnutzung muss dann der Erfasser entsprechend der Breiten und der Nutzungsintensivitäten entscheiden. Zwei Radwege in einem Seitenbereich zu definieren, würde mit dieser Notation nicht gehen, sehr wohl aber, dass der Radweg zweispurig ist (siehe Eigenschaften unten).
Ggf. Anordnung der verschiedenen Seitenwege
In der Regel wird sicherlich immer nur einer dieser Wegearten für Spezialkarten angezeigt werden. Aber alleine die Kombination aus Alleebäumen und Fahrradkarte scheint schon interessant, um zu zeigen, dass dies eine grüne und damit für Radfahrer attraktive Straße ist. Hier werden schon zwei Streifen angezeigt, womit die Info wichtig wird, in welcher Reihenfolge sie angeordnet sind. Mein Vorschlag ist, die Reihenfolge von der Straßenmitte aus zu definieren. Für den Fall, dass neben der Straße ein Parkstreifen dann ein Radweg und dann ein Gehweg verläuft sähe das so aus:
- left.parkinglane.order=1 left.cycleway.order=2 left.footpath.order=3
Existieren zwischen den Hauptfahrbahnen mehrere Anlagen (z.B. zwei Baumnreihen mit Gehweg dazwischen), so können auch negative Zahlen verwendet werden, um den Streifen in Wegrichtung links der Mitte zu zeichnen.
Eigenschaften der Seitenwege
Mit der Anordnung der Seitenwege ist schon gezeigt, wie man dafür Eigenschaften definiert. Man kann jedem Streifen im Seitenraum beliebig viele der vorhandenen Eigenschaften zuweisen, ohne nur einen Tag neu erfinden zu müssen. Die Diskussion um Sondertags für Radwegoberfläche links und rechts dürften somit ein Ende haben. Weitere Beispiele für die Definition von Eigenschaften:
- left.cycleway.surface=cobblestone left.footpath.width=2.0
Wenn man einem Weg im Seitenraum eine Eigenschaft zuweist, muss man ihn eigentlich nicht mehr wie oben beschrieben definieren. Ein Objekt, das eine Eigenschaft hat, ist alleine schon damit als existent gekennzeichnet, so dass man left.cycleway=true weglassen kann, wenn man zuvor "left.cycleway.surface=asphalt" zugewiesen hat. Das spart Tags und Taggingaufwand.
Renderingmaschine
Die Renderungmaschine müsste mit der Fähigkeit versehen werden, rechts und links eines Weges mehrere unterschiedliche Linien zu zeichnen. In einer ersten Stufe wäre es schon gut, wenn man eine Linie zeichnen kann (z. B. für Radwegkarte oder Karte der Parkmöglichkeiten). Farbe und Linienform der Linien müssten dann in Abhängigkeit der Eigenschaften oder von Eigenschaftenkombinationen über css eingestellt werden. Straßenbegleitende Radstreifen und -wege würden in einer Ebene unter den Straßen gezeichnet werden, so dass sie an Kreuzungen unterbrochen werden. Nur wenn der Layer des Radweges per Tag höher gesetzt wurde, wird dieser über die angrenzenden Straßen gezeichnet.
Zur Abwärtskompatibilität mit bisher aufgenommenen eigenständigen Radwegen müsste die Renderingmaschine aber auch Relations unterstützen.
Editoren
Editoren müssten diese Seitenbereichs-Eigenschaften unterstützen. Beim Drehen von Kanten sollten die Editoren erkennen, wenn für die Seitenbereiche Wege definiert sind und diese sich in irgendwelchen Details rechts und links unterscheiden. In diesem Fall sollte immer eine Warnung kommen und die Nachfrage, ob die Seitenbereiche auch gedreht werden sollen. Vorauswahl sollte Nein sein.
Mit dieser Notation können Navigationsgeräte wunderbar für Radfahrer genutzt werden, da bekannt ist, ob die Straße in der betreffenden Richtung einen Radweg hat und welche Eigenschaften der hat. Das Auswerten von Relations-Objekten für diese Funktion ist dann nicht notwendig.
Mittels Setzen von Wichtungsfaktoren kann die Routensuche beeinflusst werden. Rennradfahrer werden Asphalt hochsetzen und Radwege eher niedrig, meine Großeltern genau umgekehrt. Gut wäre dann eine Eigenschaft, die Benutzungspflicht setzt oder aufhebt (je nach Länderregelung). Die Routensuche soll ja nichts Illegales vorschlagen. Ebenso wäre eine Eigenschaft hilfreich, die eine Straße als unquerbar für Radfahrer markiert (z.B. bei mittigen Straßenbahngleisen mit Geländer). Querungen wären dann nur an Kreuzungen und Querungshilfen möglich.
Taggingaufwand
Wer eine solche Karte erstellen will (z.B. lokaler Fahrradclub) der wird auch bereit sein, diese Werte zu pflegen. Die Seitenräume in den Objekten der Straßen zu pflegen scheint mir wesentlich übersichtlicher als über eigene Wege mit zusätzlichen Relations-Objekten
Bisher Geleistetes
Bisher Geleistetes wäre vorerst nicht verloren. Eine Straße mit Radweg ist vom der Renderingmaschine so zu verstehen, dass auf beiden Seiten ein Radweg ohne zusätzliche Eigenschaften vorhanden ist.
- "cycleway=yes" entspricht dann "both.cycleway=yes"
Eigenständig aufgenommene Radwege bleiben eigenständige Straßen. Dort, wo straßenbegleitende Radwege als eigene Straßen aufgenommen wurden, bleibt alles beim Alten, sie lassen sich schlecht rendern. Diese sollten nach und nach entweder durch die neue Notation ersetzt werden oder mittels Relations einem Seitenraums einer Straße zugeordnet werden, so dass die Renderingmaschione einen selbstständigen Radweg wie oben als straßenbegleitenden Radweg im Seitenraum versteht.
Entstehen Probleme mit Relations, weil z.B. die Wegeanzal von Radweg und Straße nicht identisch sind, so kann es zu Darstellungsproblemen kommen. Dann sollten die Tags auf die neue Notation umgestellt werden.