Spezifische Breiteninformationen für Fuß- und Radwege

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?

Hallo,
Es handelt sich im Beispiel um diese beiden Abschnitte der Gabelsbergerstraße in München:

a.) Fuß- und Radweg einer Straße zugeordnet
https://www.openstreetmap.org/way/362368395

b.) ein kombinierter Fuß- / Radweg
https://www.openstreetmap.org/way/48136081

Bisher gibt es noch keine öffentliche Dokumentation oder Informationen außer dem BMVI Eintrag:
https://www.bmvi.de/SharedDocs/DE/Artikel/DG/mfund-projekte/akhoch2.html

Aber wir arbeiten daran das so bald wie möglich zu ändern.

LG Martin

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.

Ich würde euch gerne auf meine eigene Dokumentation verweisen, in dem ich die üblichsten Tags zusammengefasst habe:
https://wiki.openstreetmap.org/wiki/User:Mueschel/PropertiesOfRoads#Footways_and_Cycleways (die Spalten der Tabelle sind weiter oben beschrieben)

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.

vgl. z.B. diese aktuelle, aber x-te Diskussion zum Thema https://forum.openstreetmap.org/viewtopic.php?id=70280

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.

Grüße
Jo

Liebe Mapper,

Nach einiger Zeit des Beratschlagens, Suchens und Lesens, habe ich mich entschlossen für die zwei Beispiele die Breiten einzutragen.

a.)
https://www.openstreetmap.org/changeset/92459614

b.)
https://www.openstreetmap.org/changeset/92459524

Hättet Ihr die Einträge auch so getätigt?

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.

Grüße,
Martin

Ah, ihr habt euch nicht abschrecken lassen;-)

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.

Was das Tagging der Breitenangaben als solche anbelangt, scheint mir dies sinnvoll, vgl.
https://taginfo.openstreetmap.org/keys/cycleway:width cycleway:width 2296 Verwendungen vers.
https://taginfo.openstreetmap.org/keys/width:cycleway width:cycleway 44 Verwendungen

Gutes Gelingen
Jo

flöt schnelleditier 16 …

Als Anhänger des path-Schema lasse ich bei hw=path aber cycleway: bzw footway: komplett weg und verwende dann doch gleich das :lanes-Schema.

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?

Sorry, hier ein Beispiel: https://www.openstreetmap.org/way/674379548

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.

highway=path
path/footway=sidewalk
bicycle=designated/official
foot=designated/official
lanes=2
segregated=yes
surface=paving_stone
oneway:bicycle=yes
width=4.5

bicycle:lanes=designated/official|no
foot:lanes=designated/official|no
width:lanes=2.3|2.2

is_sidepath=yes

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.

(dazu fühle ich mich allerdings nicht berufen, erkläre mich aber ausdrücklich bereit, die width-Variante von Kolumdium s.o.
https://www.openstreetmap.org/changeset/92459524#map=19/48.14537/11.57611
an geeignet Stelle, z.B. unterhalb von
https://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dpath#Verwendung_als_Universal-Tag
zu dokumentieren, sofern die Freiberger dabei bleiben und hier kein grundsätzlicher Einspruch dagegen besteht - einfach weil ich dies als eher KISS-Lösung auch verstehen kann)

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.

Das sehe ich genauso

  • 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:

driving_direction=left
lanes=2
lanes:forward=1
lanes:both_ways=1
access:lanes:forward=no
access:lanes:both_ways=no
bicycle:lanes:forward=official
foot:lanes:both_ways=official
surface:lanes:forward
surface:lanes:both_ways
width:lanes:forward
width:lanes:both_ways

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.

@alle, Eine Dokumentation auf Basis des Ansatzes von Kolumdium #7 könnte so aussehen:
https://wiki.openstreetmap.org/w/index.php?title=User:Jo_Cassel/Schreibtisch&oldid=2050089

Nachtrag Link-update, s. unter “Breiteninformationen”

Danke für die Aktive Diskussion bisher.

Wir hatten uns das lanes-Shema auch schon angeschaut, sind aber auch zu dem Schluss gekommen, das lanes nur für Straßen genutzt werden sollen.

Ich hätte noch eine weitere Frage, die ich gerne zur Diskussion stellen würde.

Es gibt den wenig verbreiteten Tag
maxwidth:physical

Wie würdet Ihr diesen Tag einsetzen?

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.