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:
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?
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?
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.