Moin!
Ich bin schon seit 15 Jahren dabei, war lange inaktiv, aber der Vortrag bei Bits&Bäume zur Parkplatzerfassung hat mich wieder angefixt:
Ich will gerne helfen, Fuß- und Radwege und Parkstreifen besser zu erfassen und ich weiß nicht, wie da der aktuelle Stand ist, denn man kann beide ja auf zwei Arten erfassen:
Als eigenen Weg parallel zur Autostraße
Als Feature von Straßen
Ich habe mir jetzt selbst zusammengereimt, dass es sinnvoll ist, das Feature zu benutzen, wenn der Weg zur Straße gehört. Eigene Linien sind nur dann sinnvoll, wenn sie zu keiner Straße gehören.
Auf dem Luftbild mag da manchmal viel Platz sein: Straße + Parkbuchten + Radweg + Fußweg (jeweils auf beiden Seiten). Aber das würde ich alles nur als Feature erfassen.
Beispiel:Kiel, Prinz-Heinrich-Straße. Da hat jemand schon rechts und Links die Radwege eingezeichnet. Das ist auch die Veloroute 5. Also ein wichtigerer Radweg. Ein Stück weiter südlich ist das aber nur ein Feature der Straße. Frage: Soll ich da jetzt die eigene Linie entfernen und den Radweg zum Feature der Straße machen?
Das würde ich dann auch so ändern, wo mir das begegnet.
Eigentlich könnte die Debatte aus meiner Sicht längst erledigt sein, weil wie will man etwas erweitern oder überhaupt detaillierter erfassen können, das nicht als Geometrie vorhanden ist? Es gibt bei dieser Endlosdiskussion seit Jahren keinen Konsens. Ja, ist traurig.
footway/cycleway=sidewalk am Weg reicht in der Mehrzahl der Fälle, weil man kann nach solchen Wegen in der Nähe der Straße suchen und dann deren ungefähre Hauptverlaufsrichtung auswerten. Deshalb spare ich mir sowas wie is_sidepath:of, aber wenn es jemand gerne ergänzen will, soll er das tun.
Ah! Ein bekanntes Profilbild! @3: Kann ich verstehen. Ich kenne den Frust, wenn jemand die eigene Arbeit wieder entfernt. Allerdings bekommt man so natürlich nie etwas einheitlich. Aber ok.
Nachtrag: @3: StreetComplete fragt ab, welche Straßen Bürgerstreige haben. Darüber werden jetzt viele Straßen Bürgersteige als Feature bekommen. Wenn es gleichzeitig einen Bürgersteig als Linie gibt - ist das ein Problem?
Die Arbeit, die man damit hat, getrennt gemappte Wege zusammenzulegen bzw. zusammen gemappte Wege aufzutrennen, die Relationen zu ändern, usw., das ist ein unnötiges Risiko und bringt im Grunde nichts, es sei denn, man kann einen Sachverhalt nur so erfassen. Viel wichtiger ist es, fehlende Details zu ergänzen und Fehler zu korrigieren.
Nicht, wenn separat erfasste Fußwege an der Straße mit sidewalk=separate erfasst wurden - so wie’s sich gehört.
Ergänzend zu den schon genannten Leitlinien könnte man den kleinsten gemeinsamen Nenner vielleicht so zusammenfassen - in Bezug auf Rad- und Gehwege:
alles was sich als Fahrspur auf der Fahrbahn befindet – also insbesondere Radfahrstreifen – sollte Teil der highway-Linie sein, die gewissermaßen die Fahrbahn mit all ihren Spuren repräsentiert.
alles, was sich in einem anderen Verkehrsbereich befindet, also beispielsweise “jenseits” des Bordsteins, kann separat gemappt werden – wo sich dann die Geister zu scheiden beginnen.
Wenn man die Daten für Datenanalysen (Stichwort Verkehrswende/Infrastrukturqualität) oder erweitertes Routing (Stichwort Barrierefreiheit) fit machen oder selber verwenden möchte, kommt man meiner Meinung und Erfahrung nach nicht um separates Mapping drum rum. In Berlin haben wir – ergänzend zu den allgemeinen Mapping-Leitlinien – recht weitgehende Anleitungen zum Mappen separater Gehwege und Radwege entwickelt, die für dich vielleicht interessant sein könnten.
Da du auch die Parkstreifen erwähnt hast: Das lässt sich nicht so gut mit den Geh- und Radwegen vergleichen, aber Leitlinien könnten sein:
alles, was sich auf längeren Streckenabschnitten gleichförmig auf oder neben der Fahrbahn befindet, lässt sich am besten mit dem parking:lane-Schema an der Straßenlinie erfassen,
alles, was geometrisch komplex oder ungewöhnlich ist, sowie untergliederte Parkbuchten, kann man statt dessen als separate Geometrien erfassen (amenity=parking + parking=street_side oder seltener parking=lane), wenn man es gern so genau hätte.
Beide Mappingbereiche können sehr komplex sein, daher lohnt es sich zum “(Wieder)Einstieg” vielleicht, mit kleinen Zielen oder einzelnen Schwerpunkten zu starten, um sich nicht erschlagen zu lassen. Sowas wie:
systematisch die Breite und Oberfläche von Radwegen ergänzen (unabhängig davon, ob sie separat gemappt sind oder nicht - vielleicht bei Gelegenheit mal einen “begonnenen” separaten Radweg fortsetzen),
alle Parkstreifen in einem Stadtteil mit StreetComplete mappen, oder
die Wohngegend mal systematisch auf Vollständigkeit z.B. von Fahrradständern prüfen.
Zur Veranschaulichung, wofür das alles nützlich sein kann – und damit als weitere Motivation zum Mappen – gab es übrigens einen weiteren Vortrag von Tobias auf der Bits und Bäume-Konferenz: “Mit OpenStreetMap die Verkehrswende begleiten – Tagging, Tools und Analysen”. Ich finde ihn sehr empfehlenswert – bin aber nicht ganz unparteiisch, denn ich bin einer der Vortragenden des anderen von dir genannten Vortrags und freue mich sehr, dass er dich motiviert hat, dich wieder mehr mit OSM zu beschäftigen
Persönliche Meinung, die nicht zwingend dem Konsens entsprechen muss:
Benutzungspflichtige Radwege (die mit dem blauen Lolli) werden immer als getrennte Wege eingezeichnet.
Nicht benutzungspflichtige Radwege (Fußwege mit Zusatzschild “Radfahrer frei” und solche ganz ohne Beschilderung) nur dann getrennt einzeichnen, wenn eine bauliche Trennung z. B. durch einen Grünstreifen besteht. Ansonsten kommen diese Wege als Tags an die Straße.
Das separate Mappen von reinen Bürgersteigen ist überflüssig wie ein Kropf und macht Probleme mit dem Routing, denn der Fußgänger wird dann erstmal über einen riesigen Umweg bis zur nächsten Kreuzung geschickt wenn er doch einfach an Ort und Stelle über die Straße könnte.
Das parking:lane-Schema ist in der Praxis völlig unbrauchbar, denn es zwingt zum Zerstückeln von Straßen in kleine und kleinste Segmente, wenn z. B. mal wieder ein Baum am Straßenrand steht oder im 5-m-Schnittbereich von Kreuzungen, wo nicht geparkt werden darf. Wenn (ausgeschilderte/markierte, also nicht einfach “hier darf man am Straßenrand stehen bleiben”) Parkplätze am Straßenrand gemappt werden sollen, besser als Fläche mit amenity=parking, das wird auch deutlich häufiger ausgewertet.
Den Bits&Bäume-Vortrag kannte ich schon. Der war der zweite Vortrag, den ich mir angeschaut habe, nachdem da auch schon der zur Parkplatzanalye wieder angefixt hat.
Mein Ziel für OSM in Kiel ist gerade, dass auch bei uns die Parkplätze so gut wie möglich erfasst werden. Das Thema ist hier gerade so groß wie überall sonst auch und eine Grundlage für Diskussionen wäre wichtig.
@kaffeeringe Du siehst, wie weit die “Mapping-Geschmäcker” auseinander gehen können
Das ist total ok – überspitzt ausgedrückt vielleicht sogar das Ziel solchen Mappings, denn das ist im Zweifelsfall genau der Weg, den du nehmen musst, wenn du mit einem Kinderwagen, Rollstuhl etc. unterwegs bist. Alle anderen müssen in solchen Situationen entweder mitdenken oder einen Router benutzen/entwickeln, der solche Routings vermeidet bzw. auf “Abkürzungsalternativen” hinweist, denn theoretisch ist das lösbar, wenn der separate Weg weiß, dass er zur Straße gehört (was er als “sidewalk” oder “is_sidepath” tut). Aber ja, die Softwareentwicklung steht hier noch genauso am Anfang wie teils der Mappingdiskurs. In der Praxis ist das ja auch nur – korrektes Mapping vorausgesetzt – entweder auf den letzten Metern oder an T-Kreuzungen ohne reale Querungsmöglichkeit ein Problem (wo der gemeine Fußgänger über den Grünstreifen geht oder sich zwischen geparkten Autos durchquetscht).
Das ist nicht notwendig, denn die “parkraumbeeinflussenden Phänomene” wie 5-Meter-Bereiche an Kreuzugen lassen sich aus den OSM-Daten ableiten (das ist der Kern des oben erwähnten Parkraumprojekts, auch hier in diesem Artikel beschrieben) und sowas wie kleinteilige Parkbuchten, wie du schon geschrieben hast, separat erfassen.
