Höhengleiche straßenbegleitende Gehwege wie taggen ?

Detailliert kann man auch den hw=footway als separaten way eintragen:

https://wiki.openstreetmap.org/wiki/Tag:highway%3Dfootway

sidewalk ist der Weg mit Bordstein abgetrennt. Sollte ein Geländer zur Straße trennen, entfällt sidewalk. crossing sind auch mit abgesenkten Bordsteinen ausgeführt.

Mittlerweile sind immer mehr Details an einer hw-Linie eingetragen. Da nutze ich es nur wenn es einen höhengleichen Weg gibt.

Und was ist dann ein Gehweg der durch eine Pflastersteinreihe von der Straße abgetrennt, aber höhengleich ist ?

Fragende Grüße

Hab ich bezüglich der Radspuren auch mal gedacht, aber https://wiki.openstreetmap.org/wiki/Lanes#Crossing_with_a_designated_lane_for_bicycles sagt was anderes.

–ks

… mit den bekannten Nachteilen (vor allem die Notwendigkeit virtueller Verbindungswege an jeder gegenüberliegenden Einmündung).

–ks

Warum braucht es für dieses Thema mehr als sidewalk:right/left:kerb=no ?
Wir sollten nicht für jedes Spezialthema immer wieder neue Tags erfinden (KISS).

Meine Frage war:
Gibt es für die Unterscheidung höhengleich oder nicht höhengleich entspr. Tags.
Von neuen Tags habe ich nichts geschrieben!

Ja, bei baulicher Trennung. Aber das wurde ja schon oft genug diskutiert, muss hier nicht wiederholt werden.

da steht nichts anderes, lanes=3 für 3 Autospuren und 1 Fahrradspur.

als ob das ein Standard wäre der mehr etabliert ist als andere. Hier taginfo von heute:
footway=lane 103
footway:left=lane 32
footway:right=lane 23

sidewalk:both:kerb=no 1
sidewalk:left:kerb=no 8
sidewalk:right:kerb=no 2
sidewalk:kerb=* 2

wenn man mal kurz überlegt, wo man alles einen Bordstein erwarten würde, dann kann man sidewalk eigentlich auch weglassen:
kerb=no 2014

Ich kann dieterdreist nur zustimmen- für den Router sind Tags, die im Sub-Promillebereich genutzt werden, leider fast irrelevant. Aber es besteht ja Hoffnung, dass sich sinnvolle Notationen durchsetzen.

Aus Sicht des Routers solltest du unbedingt Standard-Notationen benutzen, und weitere Details gerne mit selteren Tags ergänzen- diese werden aber erst berücksichtigt, wenn sich einer von uns mal damit beschäftigt, und sie mit speziellem Code berücksichtigt. Ich begrüße aber die Nutzung der kerb-Tags sowohl zum sidewalk-tag als auch beim separaten Footway. Nur leider wird mir so schnell niemand komplett beantworten können, wie sich das genau auf das Routing auswirken soll- es gibt sogar aktuelle Forschungsvorhaben zu Leitkanten, und wie diese gefunden werden können… (z.B. Mind the Gap zu Leitlinien durch Hausseiten aus OSM, oder Shorelines-Bestimmung aus Bilddaten)

Ich selbst bin als Mathematiker kein Mobilitätsexperte für Blinde, aber ich arbeite ja mit einem blinden Kollegen und Freund zusammen, und konnte im Projekt natürlich mit Mobilitätsexperten schon mehrere Wege abgehen. Und aus dieser Sicht sind höhengleiche Gehwege extrem relevant: Wenn man den Unterschied zwischen Straße und Gehweg mit dem Langstock nicht mehr ertasten kann, ist die Nutzung dieser Gehwege sehr gefährlich. Ebenso wie komplett abgesenkte Bordsteinkanten sind so genannte Shared Spaces für Menschen mit Blindheit ein riesiges Problem. Von daher ist wahrscheinlich kerb=no (bzw. left/right/both oder separat) aktuell und für die Zukunft die beste Variante, aber dies lässt die von dir genannte Abtrennung durch eine Pflastersteinreihe außen vor. Ob das ein Problem für Blinde ist, muss man sich vor Ort ansehen und mit Langstock austesten. Für das Routing macht es aber eh keinen Unterschied, da die Angabe durch die geringe Nutzung (und unklare Bewertung s.o.) bisher noch nicht relevant war.

Oft genug werden auch Parkstreifen von der Fahrbahn durch Bordsteine abgetrennt.
Oder andere Fahrbahnteile als Gehwege.
Oder Grünstreifen zwischen Fahrbahn und Gehweg oder zwischen Geh- und Radweg oder zwischen Gehweg und Privatgrund. Oder unterschiedliche Gehwegteile …
Etc.

In Straßen, in denen ein Bordstein als Trennung zwischen Fahrbahn und Gehweg fehlt, mögen in der Regel auch alle anderen Bordsteinverdachtsfälle fehlen.
Aber für’s Positivtgging wäre diese Annahme zu gewagt …

Ich tendiere dazu, die höhengleiche Gehwege zusätzlich zu sidewalk=right noch mit sidewalk:right:kerb=no zu markieren.

Soweit ich das Wiki zu Key:kerb richtig verstehe, sollte kerb aber (nur ?) an Nodes verwendet werden. Von Ways ist da keine Rede. Andererseits werden dort 24310 Verwendungen an Ways aufgeführt.

Sehe ich das falsch und / oder hat die Realität das Wiki mal wieder “überholt” und die Verwendung an Ways sollte noch ergänzt werden ?

Grüße aus Oberschwaben

Im Wiki
https://wiki.openstreetmap.org/wiki/Key:kerb

steht rechts unter “used on these elements”: maybe used on ways

Das ist ein “Standart-Text” der so auf jeder Seite steht und sagt nur wie oft kerb bei welcher Objekt-Art verwendet wird.
Das ist keine Aussage, wie kerb verwendet werden soll.

Grüße

Ich versuche noch mal zu verdeutlichen, was ich meine: in dem Kasten auf der rechten Seite steht im oberen Drittel der Text “Used on these elements”. Dort sind die Elemente, für die kerb NICHT verwendet werden soll, durchgestrichen, während die Elemente node und way verwendet werden dürfen.

Weiter unten ist unter taginfo angegeben, wie häufig kerb für die verschiedenen Elemente schon verwendet wurde (immerhin auch 110 mal in Relationen, für die die Verwendung eigentlich ausgeschlossen sein sollte. :frowning:

Fazit: kerb kann man durchaus auch an ways einsetzen.

Wenn Fußwege nicht seperat erfasst werden sollen (Hilft Menschen, aber könnte einen Router verwirren!),
dann möchte ich, auch weil in #13 von Sehbehinderten gesprochen wurde,
mal fragen, wie mit
https://wiki.openstreetmap.org/wiki/DE:Key:tactile_paving
umzugehen ist.
Soll diese Info (neben Fußweg, Radweg, Parkplätzen, und Straßenbäumen)
auch noch an die zugehörige Straße?

Da gibt es keine allein selig machende Antwort.

  • Wenn die Gehwegeigenschaft sich ändert und diese an die Straße getaggt ist, muss die Straße gesplittet werden. Das kann sehr unübersichtlich werden.
  • Wenn die Gehwegeigenschaft auf einen parallelen way gelegt wird (bauliche Trennung ignoriert), muss man an jeder möglichen/gewünschten Überquerung der Straße z.B. zu eine Quergehweg auf der anderen Seite einen kurzen way legen. Das kann sehr schnell einen ziemlichen Wegeverhau geben, abgesehen davon, dass “on the ground” die Straße noch an vielen anderen Stellen überquert werden kann. Das Kriterium mit der baulichen Trennung wurde ja nicht aus Jux und Tollerei eingeführt.

“musss”, weil Router (Stand August 2018) zu blöd sind, dies selbst zu erkennen, es wäre also OSM-Wegebau für dumme Robotor, der für Menschen ggf. auch lebensgefährlich sein kann.

Der de:Wikipdia-Artikel zum “Kriterium”:
https://de.wikipedia.org/wiki/Bauliche_Trennung
oder ist eher dies der richtige Terminus:
https://de.wikipedia.org/wiki/Leerformel

Sorry, aber mein Eindruck: im OSM-Forum wird allzuoft nur meinungsstark von A nach B geroutet und gedacht.
Der Gesamtzusammenhang, oder was langfristig danach kommt … Fehlanzeige

Ebenfalls sorry, aber in OSM gibt es bisher nur eine Verbindung von A nach B, wenn es einen way dazwischen gibt. Die möglichen im Sinn von nicht lebensgefährlich sollte ein Mensch am besten mit Vor-Ort-Kenntnis anlegen. Ein nur auf der DB basierender Algorithmus kann das prinzipiell nicht, wird also immer “dumm” bleiben.

Von daher ist “bauliche Trennung” ein bisschen mehr als eine Leerformel, auch wenn dieser Begriff nicht in der deutschen Wikipedia vorkommt.

Woran sollen sie das denn erkennen können? Allein am parallelen Verlauf hoffentlich nicht – der schließt ja nicht aus, dass dazwischen ungemappt noch ein Zaun, eine Mauer, ein Wassergraben oder was auch immer ist.

Für parallele, nicht-getrennte Wege müssten wir dann einen eigenen Typ Relation einrichten, um sauber abbilden zu können, welcher Weg von der Straße physisch getrennt ist und welcher nicht. Dann können Router das zuverlässig erkennen. Aber ob das einfacher ist für Einsteiger, wage ich zu bezweifeln.

Das ist aber alles schon -zigfach durchgekaut worden. Ich wollte den Aspekt nur noch mal einwerfen, weil es einfach nicht stimmt, dass das nur an der Doofheit der Router(-programmierer) liegt.

–ks