Spezifische Breiteninformationen für Fuß- und Radwege

Liebe OSM-Community,

an der TU Freiberg arbeiten wir an OSM basierten Planungstools für autonome
Lieferroboter. Dafür bewerten wir die “Eignung” eines Tracks ausgehend von
einer möglichen Robotergröße und -geschwindigkeit. Da die Width und Surface
Informationen für Rad- und Fußwege nur anteilig vorhanden sind, arbeiten wir an
einer Software, die diese Informationen aus Kamerabildern extrahiert.

Wir wollen die gesammelten Daten gern wieder in OSM integrieren oder der
Community zur Verfügung stellen und entwerfen dafür ein Datenmodell. Dabei
haben wir uns gefragt, wie die Informationen am besten abgebildet werden, wenn:

a) der Fuß- und Radweg einer Straße zugeordnet sind und dort selbst als Attribut
erscheinen (https://www.openstreetmap.org/edit?relation=62428#map=19/48.14697/11.56955)

b) ein kombinierter Fuß- / Radweg vorliegt, die Width und Surface Daten aber
individuell zugeordnet werden sollen (https://www.openstreetmap.org/edit?relation=62428#map=19/48.14552/11.57399).

Nach unseren Recherchen haben wir für diese Fälle 2 Varianten für die separate
Eintragung gefunden:

für Variante A) mittels Lanes (Beispiel mit beidseitigem Fuß und Radweg)


  highway=secondary
  lanes=6
  sidewalk:lanes=yes|no|no|no|no|yes
  vehicle:lanes=no|no|yes|yes|no|no
  bicycle:lanes=designated|yes|no|no|yes|designated
  surface:lanes=concrete:plates|concrete|asphalt|asphalt|concrete|concrete:plates
  width:lanes=2|1.5|3|3|1.5|2
  ...

für Variante B) mit Typ und Attributbezeichner sowie “:”


  highway=path
  sidewalk:surface=paving_stones
  cycleway:surface=asphalt
  cycleway:width=1.5
  ....

Offenbar scheinen auch beide Varianten “sidewalk:surface” und “surface:sidewalk”
als Eintrag gültig zu sein. Ist das eine gültige Interpretation des Wikis oder
seht Ihr andere Formate als geeigneter und auch generischer zu verwenden?

Wir freuen uns auf Eure Hinweise!

Sebastian

Hallo Sebastian, ist immer schön von neuen Anwendungsfällen für OSM zu hören, und ich finde es gut, dass ihr auch etwas an OSM zurückgeben möchtet! :slight_smile:

Für den Fall A sind im Wiki z.B. auf Key:sidewalk#Additional_tags Tags wie

sidewalk:left:width = 1.2 m
sidewalk:both:surface = paving_stones
cycleway:right:width = 3

dokumentiert. Einen Gehsteig als Spur im Sinne von lanes zu modellieren wäre nach meiner Erfahrung sehr unüblich. (Falls ihr einen Gehsteig oder Radweg jeweils als separaten Way gemappt vorfindet, nutzt ihr dort natürlich width und surface ohne weitere Anhängsel.)

Die Variante cycleway:surface ist in der DB deutlich häufiger als andersherum (analog für sidewalk).

Bitte behaltet auch die Richtlinien zu Importen im Hinterkopf und bezieht sie mit ein, wenn ihr darüber nachdenkt, in welcher Form ihr der Community diese Informationen zur Verfügung stellt. Macht ihr die Kameraaufnahmen selber? Je nachdem wären da nämlich auch die Rechte an den Bildern zu beachten.

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.