Habe mal mein neues Spielzeug, digitaler Zollstock ausprobiert. Damit will ich auf Radtouren, die Breite der Radwege bzw. tracks vermessen.
Nun habe ich es aber mal in der Stadt versucht. Dabei sind aber viele Fragen aufgetaucht.
Macht es Sinn innerorts die Straßenbreite zu kartieren?
Wie genau soll man runden? Ich habe beispielsweise an jeder Kreuzung gemessen und die Breite von Bordstein zu Bordstein betrug 5,5-6,5 m. Soll man die ganze Straße den Mittelwert nehmen oder den kleinsten?
Vielleicht doch einfach mit 1. nein antworten, dann hat sich das alles erledigt.
Es gibt schmale und breite Straßen. In Verbindung mit erlaubten Parken (parking:lane) ergibt sich ggf. ein Anhaltspunkt wie angenehm die Straße zu fahren ist.
1: meiner bescheidenen Meinung nach ist’s nicht verkehrt, das zu erfassen. Die paar Byte zusätzlich in der Datenbank stören wohl auch nicht mehr – da wird mehr für weniger nützliche Informationen verbraten. Und vielleicht wird die Breite ja mal vom Renderer ausgewertet?
2: wieder nur meiner Meinung nach: die Straßenbreite ist die Breite der Straße, die üblicherweise von Fahrzeugen genutzt wird.
3: ich würde pro Abschnitt (der dadurch gekennzeichnet ist, dass man die Straße auf dieser Strecke nicht verlassen kann) die schmalste Stelle erfassen. Nutzt nichts, wenn ein breiteres Fahrzeug eine Straße zu 99% der Strecke befahren könnte, wenn es in der Mitte eine Stelle gibt, durch die es nicht passt.
Üblicherweise ist nicht wirklich genau. Es gibt Straßen, wo die Autos in Buchten parken, da ist klar, dass die nicht dazu gehören. Wenn die aber auf der Straße parken, wie wohl meist, dann ist das Übliche wohl der Rest. Auch die Richtlinine bringen uns nicht weiter. Wollen wir die genauen Daten aus dem Bebauungsplan eintragen, oder die letztlich nutzbare Fläche beispielsweise für LKWs.
Das Problem ist hier die mancherorts erlaubte Parkerlaubnis (1) am Straßenrand (oft mit seitig wechselnden Parkmarkierungen). Die eigentliche (dörfliche) Durchfahrtsstraße (wäre jetzt für LKW Verkehr wichtig und oft auch, noch parallel und gleichzeitig aber eng, im PKW Gegenverkehr) hat ja eine (vielleicht) genormte Gesamtbreite, aber effektiv, da Dauerparker, eben keine solche.
Es wäre müßig, hier die effektive Breite anzugeben, einzig die Gesamtbreite im freien Zustand des Weges ist relevant. Da diese Parkbereiche so oft wechseln oder unterbrochen sein können, ist ein “nutzbares” Straßenbreite Mapping fast unmöglich. (Wie oft muss man z.B. in Wohnstraßen Slalom fahren?)
Hier hilft eigentlich wohl wirklich nur das a:h tagging, um (markierte) Parkbereiche auch auf Karten sichtbar zu machen.
Nur schade, das es immer noch keinen Server gibt, um ganz DE / DACH / Eu mit a:h tagging zu rendern. (2)
Edit (1) Ist ja innerorts sowieso erlaubt, wenn keine Beschilderung dagegen spricht. (Hier hangelt man sich oft von freigehaltener Einfahrt zur nächsten, um mit dem Gegenverkehr klarzukommen)
Edit (2) Aber OsmAnd zeigt schon gute Ansätze für das Flächentagging von Strassen (amenity=parking_space wird leider noch nicht berücksichtigt - dieses tag sollte imho gefördert werden)
Über welche Tags sprechen wir hier eigentlich? Ohne jetzt in der Wiki nachgesucht zu haben, fällt mir spontan nur die Lane-Width ein. Oder wird “width” auch für sich allein auf ein “highway”-Element angewendet? Bei letzterem ist es klar, dass es Diskussionen gibt, was dazu gehört. Wenn man aber die lane-Witdh angibt, entfällt meines Wissens diese Diskussion. Daher würde ich auch immer nur diese taggen (selbst bei nur einer Lane).
Was die unterschiedlichen Breiten betrifft … da hatte ich mir auch schon mal Gedanken gemacht und überlegt, ob man die Breite an Wege oder an Punkte knüpfen sollte. Ersteres hat natürlich den Vorteil, dass es simpler und besser zu finden ist (im Editor). Allerdings müsste man einen Weg dann für jede Breitenänderung aufteilen.
Daher würde ich eine Punktbreite für sinnvoller halten, zumal es den Messvorgang auch besser abbildet: Man misst an einem Punkt die Breite(n) und trägt diese als Node-Eigenschaft ein. Für den Nutzer dieser Information (z.B. für den Renderer) würde das bedeuten, dass sich die Breiten von einem Node zum nächsten getaggten Node entsprechend “linear” ändern. Genauso werden ja auch Kurvenverläufe gemappt. Je genauer man das haben will, desto mehr Nodes braucht man.
Nachteil dieser Variante ist, dass sie zu etwas mehr Daten führen kann (sinnvollerweise taggt man ja zumindest Anfangspunt und Endpunkt einer vermessenen Strecke). Darüber hinaus ist die Frage, wie man mit Kreuzungen umgeht. Wobei … nein, man kann halt nur im Kreuzungspunkt keine Breiten Taggen (gleiches Problem wie bei Richtungsangaben von z.B. Ampeln, die man dann vor oder hinter dem Kreuzungspunkt taggen muss).
Beim Parken würde ich mich Rogehm anschließen. Das muss ignoriert werden. Und auch Verkehrsberuhigungsmaßnahmen (traffic_calming=chikane/choker/island) gehören da meines Erachtens nicht rein, sondern werden explizit hinzugefügt. An dieser Stelle würde sich übrigens die Punktbreite bezahlt machen
Ich kann mir kaum vorstellen, dass es zu diesem Thema nicht schon tonnenweise Proposals für gibt.
Gehwege, Seitenstreifen usw. werden auch bei anderen tags (surface, lanes, …) nicht berücksichtigt, deshalb trage ich die Breite der Fahrbahn ein, wenn Bordsteine vorhanden sind, die lichte Weite dazwischen. Auf dieser Breite kann man fahren.
Wenn Fahrzeuge auf der Fahrbahn parken, ist das für mein Verständnis irrelevant: width bezeichnet die Fahrbahnbreite, nicht die zurzeit nutzbare Breite. Die nutzbare Breite trage ich als maxwidth:physical ein, dabei berücksichtige ich aber nur unbewegliche Hindernisse.
Mein Laserentfernungsmesser misst zwar sehr genau, ich runde trotzdem auf ganze 10…50 cm.
Gleiches wurde auch hier: http://forum.openstreetmap.org/viewtopic.php?id=55532 angesprochen.
Ich plädiere dafür, eine einheitliche Lösung dann auch zu dokumentieren. Dabei helfen Gesetze und Richtlinien m.E. wenig, da sie meist einem anderen Zweck (z.B. Straßenbau) dienen. Hier geht es jedoch mehr um Komfort und Straßenbreite für Fahrzeuge.
Mein Vorschlag: originär “width” ist für die Breite der Fahrbahn. Weiterhin kann man die Breite von sidewalk, parking_lane, cycleway etc. getrennt angeben z.B. sidewalk:width=; cycleway:width=
Dann aber bitte width:lanes, width:sidewalk, width:cycleway usw.
Das erste Schlüsselwort soll den Datentyp des Werts bestimmen. Für width… wird eine Zahl erwartet (ähnlich maxspeed:forward, lanes:backward, turn:lanes, …).
-1
“sidewalk:width” bzw. “cycleway:width” sind Eigenschaften der Geh-, bzw Radwege. So wie “:surface=”, “:smoothness=”, :bicycle=, ":foot= etc.
Hinter “:lanes=” steht ein komplett anderes Konzept!
Hm? Verstehe ich jetzt nicht. Es ist doch genau das gleiche wie bei anderen Eigenschaften, die sich auf bestimmte Lanes beziehen, wie z.B. turn:lanes, change:lanes, direction:lanes und so weiter. Insofern ist width:lanes genau das, was getaggt werden sollte. Oft scheint es noch nicht vorzukommen, momentan aber immerhin rund 3500 mal.
width:lanes hat aber nicht mit width:sidewalk, width:cycleway zu tun sonder ist, wie du aufgelistet ja hast, im Bereich von “turn:lanes, change:lanes, direction:lanes und so weiter” einzuordnen.
Mit dem :lanes=" suffix werden z.B. ja auch die Position von Radfahrstreifen an Kreuzungen verdeutlicht.
Bsp.:
Dann sind wir uns ja einig Obgleich ich dann nicht genau weiß, wofür width:cycleway und dergleichen verwendet wird. Achso. Wenn man diese nicht als Lanes deklarieren kann. Also könnte Dein obiges Beispeil durchaus mit “width:sidewalk” ergänzt werden, weil der Bürgersteig in den sonstigen Tags nicht betrachtet und vor allem nicht explizit angenommen wird.
sidewalk und cycleway werden hier als Namensraum verwendet, sie bestimmen keinen Datentyp. Daher ist cycleway:width und sidewalk:width verbreiteter. Das Konzept gruppiert alles zum Gehweg: sidewalk:right:bicycle = yes z.B.
