Sidewalk vs. separater Fußweg

Borken/NRW ist auch Separat-verseucht… :sunglasses:

https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=51.84662%2C6.87862%3B51.84653%2C6.87897#map=17/51.84516/6.87986

Oh jeh, allerdings getraue ich mir kaum noch, so etwas zu reparieren, sprich die Dinge an die Wege zu schreiben und die separaten Geometrien zu löschen, nachdem ich massiven Gegenwind hier im Forum bekommen habe.

Mitunter finden sich Mapper vor Ort, die das genauso sehen und dann geht es. Woanders wird der Fernzugriff als Vandalismus wahrgenommen.

Also habe im Wiki ich alle genannten Vorteile und Nachteile gegenübergestellt, mit der Hoffnung, dass damit die Diskussionen dann nicht jedes mal bei null losgehen und klar wird, dass das Getrennt-Mapping viele Nachteile mit sich bringt.

Ich weiß gar nicht, wo jetzt das Problem ist… Das ist ein typisches Beispiel von Erfassungslücken… und ich mach erst mal…

Ich hab mir das zwar nur mit Esri-Hintergrund angeschaut, aber ich sehe immer wieder mal beetartige, und somit trennende Elemente und mittelprächtige Lagegenauigkeiten.

Natürlich mag das je nach Sichtweite ein Stück weit grenzwrtig sein, mit entsprechenden Verbesserungen an den Kreuzungen würde alles andere hinreichend funktionieren.

Ja und alle erdenklichen Möglichkeiten kann man eh nicht erfassen, um z.B. einen Router zu befriedigen…

Sven

Die Bürgersteige müssen dann wenigstens an den Kreuzungen miteinander verbunden werden, sonst macht der Router eben mal einen Kilometer Umweg um die Straße zu überqueren.

Wie wäre es mit Verbessern statt Löschen?

keine Ahnung ob das schon klargestellt wurde:

foot=use_sidepath würde heißen benutzungspflichtigen separat gezeichneten Gehweg benutzten (ist m.E. aber nicht dokumentiert) - der Router soll die Straße meiden
foot = no heißt auf der Straße ist das gehen verboten - der Router muss die Straße meiden

sidewalk=separate heißt separat gezeichneter Gehweg vorhanden - in Deutschland wäre der dann immer benutzungspflichtig - der Router soll die Straße meiden.
sidewalk=left/right/both heißt ein nicht separat gezeichneter Gehweg ist vorhanden
sidewalk=no heißt kein Gehweg vorhanden - in Deutschland darf man dann auf der Straße gehen
In den beiden letzten Fällen sollte der Router (mit unterschiedlichen Gewichten) über die Straße navigieren.

Wo wir gerade bei dem Thema sind und alte Fäden kurz vorm Verpacken in Umzugskartons abstauben …

Hier in der Gegend bei einem separat gemappten (für Radf. freigegebenen) Gehweg (grenzwertig zwar, aber so kann man Eigenschaften und Verlauf viel besser darstellen, also ist es m.E. besser, das so zu lassen) waren bisher alle Verbindungen zum Rest des Wegenetzes, die über abgesenkte Bordsteine führten und somit auch für Rollis und ja zugelassenen Radverkehr geeignet sind, schon drin.

Ein anderer Mapper hat kürzlich bei anderen, von der anderen Seite darauf zulaufenden Wege Verbindungen ergänzt. Für normale Fußgänger sicher nützlich, aber für Rollis und Radfahrer nicht unbedingt, denn die führen alle über nicht abgesenkte Bordsteine.

Ich habe dann in die meisten dieser Verbindungen (nur eine gelöscht, weil bestehende abgesenkte nahe bei und die neue eh nicht zielführend) noch einen Punkt reingesetzt mit
barrier=kerb
bicycle=no
wheelchair=no

Ist das so ok oder gibt es bessere Alternativen?

bicycle=dismount wäre diskutabel, aber für das Routing käme mit no wohl eher ein passendes Routing raus, wo Radler an geeigneter, also durchgehend befahrbarer Stelle runtergeführt werden. (Gibt’s eigentlich Router für Rollis?)

Ist ok bis auf das bicycle=no denn das soll ja nur bei legalem Verbot gesetzt werden.

EDIT: ok, bei Barrieren werden die access Tags nicht im rechtlichen Sinne verwendet. Mit normalen Fahrraedern kann man aber problemlos ueber Bordsteine fahren.

Warum willst du bicycle und weelchair VERBIETEN? Mit barrier=kerb ist doch alles gesagt.

Wenn ich mich dunkel richtig erinner, sagt die Barriere erst mal nix zu den daraus resultierenden Rechten, die soll man am Punkt extra setzen.

wheelchair=no wird aber m.E.n. eh als Zugänglichkeitswert, nicht als Verbot ja/nein/vielleicht interpretiert.

Richtig. wheelchair=* ist kein access-Tag, sondern bezeichnet die Rollstuhltauglichkeit (Barrierefreiheit).

Aufgrund meiner Erfahrung mit Blinden- und Rollie-Routing:

Nimm den kerb-Key an highway=crossing (also kerb=raised) denn das impliziert wheelchair=no. Wenn Du kein highway=crossing hast, dann stimmt barrier=kerb. Ob bicycle=no jetzt richtig ist, ist vermutlich Auslegungssache. wheelchair=no wird Dir aber jeder Rollstuhlfahrer danken. Wenn der Weg allerdings vom Bürgersteig auf die Straße führt, ist highway=crossing vermutlich das bessere Tagging.

als way oder als node?

Wenn als Node gemappt soll der Kerb laut Wiki an der wirklichen Stelle des Bordsteins platziert werden.

wenn das highway=crossing als node gemappt wird, dann kommt der an die Straße. Wie und wo willst Du dann kerb an die Stelle des Bordsteins platzieren?

Die nachträglich hinzugefügten Fußwegchen gehen auf der anderen Straßenseite zumeist als sevice weiter, da ist quasi nix mit crossing, der kerb hat einen eigenen Knoten zwischen straßenbegleitenden Gehweg und Fahrbahn als, nun mit kerb=raised. Die schon vorhandenen Verbindungen habe ich mit einem Knoten k=lowered, b=k, w=yes, b=yes ergänzt.
Hach, barriere=parking_lane gibt’s ja auch schon 50x, nun 51x …

Verbessern wäre, die Infos an die Straßenlinie zu schreiben und die alten Linien zu löschen. Aber das getraue ich mir nicht mehr. Verlaufen die Gehwege parallel zur Fahrbahn haben sie auch kaum geografische Zusatzinfos, die damit verlören gehen würden.

Alternative wäre, aller 1m eine Verbindung zur Straße zu zeichnen weil man sie ja überall queren kann. Das kann keiner wollen.

OK, es gäbe noch die Möglichkeiten, die bestehenden Linien für ein Flächentagging zu verwenden. Aber da steige ich nicht ein, dann wird man nie fertig.

Ich verstehe, dass man bei von der Fahrbahn abweichenden Gehwegführungen seperat mappt. Nicht aber, wenn die Wege aber parallel zur und direkt neben der Fahrbahn liegen.

Es gibt auch immerwieder Argumente, dass man das Seprerate Mapping braucht für das Mappen der abgesenkten Kanten. Das geht m.E. aber auch gut ohne seperate Linien.

Ich würde gerne wieder auf meinen Vergleich der Mappingmethoden verweisen. Wenn Argumente fehlen gerne ansprechen:
Vor- und Nachteile des Zusammen-, Getrennt- und Flächenmappings bei Gehsteigen und Radwegen

Guten Tag,

eine Frage zur Variante B (separate Linie)
Wie wird denn bei Gehsteigen defaultmässig das Attribut bicycle interpretiert? Ich ging bisher davon aus, dass dies wenn nichts angegeben ist, bicycle=no entsprechen würde.
Nun merkte hier aber bei einer Changeset-Diskussion ein User an, er würde mit dem Rad fälschlicherweise über die Gehsteige geroutet werden und hat daher recht inkonsequent vereinzelt separate Gehsteige gelöscht. Diese waren jeweils mit
footway=sidewalk , highway=footway ohne explizites bicycle=no getaggt. Muss man also bei Verwendung der Variante B dieses explizit setzen?

Hi,
highway=footway impliziert bicycle=no.
Ob das von allen Routern beachtet wird ist natürlich ne andere Frage.