Hallo, und nur zum Grundverständnis - bezieht sich obiges kleines “a)” und “b)” der TU Freiberg auf diese Straßenabschnitte der Gabelsbergerstraße in München: https://www.openstreetmap.org/way/362368395 https://www.openstreetmap.org/way/241674893
?
und gibt es bzgl. des Projektes und seiner gesammelten Daten eine online verfügbare Dokumentation oder Information?
Das Beispiel b) halte ich für falsch getaggt. Laut Tagging handelt es sich um einen Radweg, der einen von sich abgesetzen Radweg und einen Bürgersteig hat. Das stimmt aber nicht, da es ein Pfad ist der selbst sowohl der Bürgersteig als auch der Radweg ist.
Den Pfad und die Eigenschaften von Fuß- und Radanteil könnte man mit :lanes-Tagging beschreiben, aber nicht mit sidewalk/cycleway tags.
Das erstere ist üblich, das zweite sehr selten und es entspricht auch nicht der üblichen Logik zwischen Key und Subkey (das zweite wäre zu lesen als “Der Bürgersteig einer Oberfläche”).
… Die Frage kam bei mir halt auf, weil Freiberg ein paar Kilometer von obiger Straße entfernt liegt und es sinnvoll sein kann, OSM-Dinge erstmal vor der eigenen Haustür zu tun.
Ist ja ein interessantes Projekt, leider muss ich auch warnen, der ganze Komplex ist OSM-Katastrophengebiet. Es fehlt (in DE) an Konsens und einer darauf beruhenden konsistenten und verständlichen Dokumentation. Was es stattdessen gibt sind viele private Ideen und viel missionarischer Eifer diese eigenen Ideen und Wünsche “irgendwie” umzusetzen [damit meine ich jetzt ausdrücklich nicht obigen Beitrag #5].
Wenn ihr beispielsweise einen extern erfassten Fuß- und/oder Radweg nach Variante B) vermeintlich korrekt bearbeitet, müsst ihr damit rechnen, dass nächste Woche oder nächstes Jahr ein selbsternannter “Experte” vorbeikommt, der den löscht und dessen Infos “irgendwie” nach seinen Vorstellungen an die nächstgelegene Straße hängt, also nicht unbedingt so, wie ihr das nach Variante A) vermeintlich für korrekt haltet.
Der ganze Komplex urbaner Fuß- und/oder Radwege ist ein peinliches OSM-Chaos - muss ich Euch leider so sagen, als jemand der das Projekt im Grunde schätzt.
Wir werden uns erstmal nicht in diese Diskussion des richtigen taggens einmischen wollen sondern vorerst nur auf width, smoothness und surface beschränken. Diese versuchen wir so gut es geht in die vorhandenen Einträge einzufädeln, sonst stoßen wir nur auf unmut.
Das ist sehr hilfreich, danke.
Wir haben mit der TU München zusammen gearbeitet deshalb sind uns diese beiden Beispiele aufgefallen.
Großstädte bieten in der Regel auch einen “bunteren Mix” an Tags und Taggern.
Aber du hast recht wir bleiben vorerst hauptsächlich vor der Haustür.
Danke für den Hinweis. Die Diskussion ist ja wirklich unschön.
Deshalb hatten wir gleich von Anfang an das Forum mit einbezogen, damit uns das später (hoffentlich) weniger passiert.
Okey danke, das hat geholfen.
Werden wir machen.
Danke für die Ratschläge bisher, wir stehen für weitere Diskussion bereit.
Vorab, ich äußere mich nur zur Variante b), weil ich aus grundsätzlichen Überlegungen nichts davon halten (immer mehr) Umgebungsinformationen an den Straßenway zu packen, statt die Fuß-/Radwege sauber getrennt zu erfassen - dies sollen also diejenigen beantworten, die dies für eine zukunftsfähige Idee halten.
zu b)
Es gibt auch nach 16 Jahren keinen klaren Tag für das Massenprodukt kombinierter Fuß-/Radweg (Zeichen 240 + 241), dieser wird daher aus mehreren Tags “zusammengerührt”, dabei gibt es zwei “Schulen”, mit zwei Haupttags:
Euer Beispiel mit den Breitenangaben, https://www.openstreetmap.org/way/48136081
zeigt gut, warum die path-Variante die logischere ist, denn width=3.7 als Gesamtbreite bzieht sich eben nicht auf den cycleway.
Insofern wäre zu klären, ob im Zusammenhang mit der Einfügung der Breitenangaben auch ein umtaggen auf das path-Schema sinnvoll, bzw. (lokal) erwünscht ist.
Mmh, nach einer diesbezüglichen lanes-Dokumentation bei Fuß-/Radwegen zu fragen ist wahrscheinlich sinnlos.
Da Du nicht mal auf ein Beispiel verlinkst, musste ich mir eine Suchabfrage basteln.
Nach laaaanger Suche festgestellt, dass dies gelinde gesagt bisher wenig Verbreitung in D gefunden hat, neben wenigen verteilten Kuriositäten habe ich einige Fuß-/Radwege in Bremen gefunden, bei denen wohl ernsthaft versucht wurde/wird, dies umzusetzen, Beispiel: https://www.openstreetmap.org/way/589491702
Was mir dabei auffällt:
offensichtlich vertrauen die Mapper dem Schema nicht allzusehr, denn bei surface wurde es dann wiederum nicht verwendet.
Über die Tagging Kombination highway:lanes=cycleway|footway + width:lanes=2.2|2.0 läßt sich auf die Einzelbreite schließen, allerdings gibt es ohne :forward/:backward doch gar keine Lageinformationen und insofern auch keinerlei Vorteile?
In erster Linie gilt die Wegrichtung als Bezugsgröße und dann ist die Interpretation von links nach rechts. Nur bei Spuren in bestimmte Richtungen ist :forward und :backward (gegebenenfalls auch :bothways) nötig.
Ja das Beispiel ist inkonsistent und die Tags widersprüchlich wobei ich mir gerade auch unsicher bin, wie ich den Fall löse, dass auf der linken Seite die Spur nur in eine Richtung erlaubt ist. Wir haben faktisch Linksverkehr. Habe deßhalb mal auf forward/backward verzichtet.
Mmh… lanes=3
scheint ein Sonderfall zu sein, wie es da konkret ausieht fällt mir offen gestanden schwer bis unmöglich, das aus dem Tagging mental zu rekonstruieren.
Der Standardfall bei Zeichen 241 segregated=yes dürfte ja wohl lanes=2 sein.
(wobei ich bei meiner lanes-Recherche auch segregated=no (also wohl Zeichen 240) aber + lanes=2 gefunden habe - was Mapper damit ausdrücken will ist mir schleierhaft)
Kurzum ich persönlich sehe das mit den lanes-Schema am “normalen” kombinierten Fuß-/Radweg sehr skeptisch - wenn die TU Freiberger sich dafür erwärmen können sollte dies unbedingt als Anlass genommen werden, die Sache mal nachvollziehber zu dokumentieren.
Ja, ist ein spezial Fall mit geteilten Fahrtrichtung für das Rad und einem getrennten Fußweg.
Ich halte es nicht so besonders gut cycleway und footway Tags bei Seitenwegen von Straßen zu verwenden. Zugegeben bei footway=sidewalk haben wir es schon, aber bei einem separat eingetragenen Rad-/Fußweg entlang einer Straße will ich kein cycleway=track/lane sehen.
So gut dein KISS gemeint ist, es kann auch nach hinten losgehen, wenn es zur Vermischung/Verwechslung kommt, welche Tags jetzt explizit für welche highway=* verwendet werden sollten.
cycleway=lane ist per Definition “an inherent part of the road” ein Teil der Straße selbst, und in
cycleway=track lese ich einführend ganz klar: “Alternatively, this kind of object may be mapped as a separate way and tagged as highway=cycleway, or as highway=path+bicycle=designated.”
und nur darüber rede ich hier.
(und will dabei das lane-Schema weder verdammen noch verbieten, für Spezialfälle mit mehr als einer Rad-Fahrbahn an einem highway=path mag es durchaus angebracht sein, und hat im Kontext eines Ausbaus der Radinfrastruktur ja möglicherweise durchaus Zukunftspotential)
Ich bin ja auch nur am oneway:bicycle=yes gescheitert, was generell noch nicht klar geregelt ist. Ist oneway=yes generell für foot uninteressant und muss ich oneway:foot=yes explizit taggen?
Eine Möglichkeit wäre den “Linksverkehr” anzugeben:
So hat man sich m. W. geeinigt.
Andernfalls wäre eine Einbahnstraße ohne Bürgersteig auch ein Einbahnfußweg …
Ist zwar ein wenig paradox bei echten Fußwegen mit Einbahn-Regelung - aber wenn, dann sollte man es schon einheitlich gestalten.
@skyper, wie schon geschrieben kann ich keine rechte Begeisterung dafür aufbringen, für den einfachen Fuß- und Radweg mit Trennlinie (Zeichen 241) das lanes-Schema zu etablieren.
Sollte die minimale Breite eines Weges separat von der “durchschnittlich auf dem Weg vorhandenen” Breite unterschieden werden,
oder würdet ihr bei “width” schon immer die minimale Breite eintragen?
Mmh … leider ist die Dokumentation da nicht so wirklich klar, aber die einführende Verlinkung von barrier-Elementen und das Brücken-Bild lässt mich mal vermuten, dass der Tag tendenziell nur besonderen Engstellen zugeordnet werden sollte.
Das deckt sich auch mit der überwiegenden Verwendung an nodes und nicht an ways (s. unterhalb von “taginfo [More…]” rechts).
Und an punktförmigen besonderen Engstellen ist der Tag wohl sinnvoll.
Grundsätzlich würde ich an ways, den problematischsten - also hier minimalsten - Wert wählen.
Wenn es einen extremen Versatz gibt, kann der way - analog zum surface-Wechsel - auch mal gesplittet werden, das sollte aber in einem vernünftigen Rahmen bleiben.
Ich interpretiere width bei highway=* als die Breite der eigentliche Wegoberfläche. Bei Gehwegen z.B. die gepflasterte begehbare Fläche. Nun kann diese Wegbreite an Stellen eingeschränkt werden. Z.B. durch ein Poller, eine Straßenlaterne, Bäume, Geländer, Hecken etc. Jetzt kann man diese Stellen einzelnd als separate nodes (auf der highway-Linie) erfassen und dort die einzelnen maxwidth:physical Werte eintragen. Man kann es auch vereinfachen und für den gesamten way eine maxwidth:physical Angabe mit dem kleinsten Wert machen. Wie Jo Cassel schon schrieb, würde ich den Weg aber dann splitten, wenn es da deutliche unterschiedliche Abschnitte gibt.
maxwidth:physical muss aber nicht unbedingt kleiner width sein. Es kann durchaus sein, dass die Wegbreite am Boden (Oberfläche) relativ schmal ist und die mögliche Breite im Luftraum (zwischen Wänden, Geländern, Bäume etc.) wesentlich Breiter ist. So können z.B. Radfahrende herausfinden, ob sie dort entlang kommen.
Hattest vollkommen Recht, das lanes-Schema funktioniert nicht bei Fuß- und Radwegen. Vor allem “Spuren” auf der linken Seite in Wegrichtung und rechts daneben “Spuren” in beide Richtungen sind nur bei Linksverkehr vorgesehen. Dort bräuchte ich aber genau das Gegenteil.