Fußgängerrouting auf der OSM

Danke erst einmal auch für das Vorstellen.

Ich habe es einmal für den "Sicheren Schulweg" in unserer Stadt (mit detaillierten Fußwegen) genutzt. Es gibt zwar ein paar "kleine" Fehler. Das Routing ist allerdings sehr genau mit den Angaben zu Übergängen. Auch deckt sich fast der persönliche Vorschlag mit dem Routing.

Günstig wäre das Erzeugen eines "Permalinks". Da mit könnte man auch die "kleinen" Fehler im Routing klären. Und eventuell auch helfen, Problemchen zu klären. So wird "auf" einer Straße linksseitig geroutet, obwohl rechts ein footway vorhanden ist mit der dortigen Querung ca 10 m längeren Weg benötigt.

Es sollte jeder einmal in seiner näheren Umgebung mit Sicht auf "sicheres Routing" testen.

Danke geri-oc für den ersten Eindruck. Ja, Permalinks sind auch bei mir ganz oben auf der Wunschliste, dabei hatte ich zuerst an die aktuelle Position der Karte gedacht (aktuell starten wir immer in Karlsruhe), aber natürlich wäre es sehr gut, wenn wir auch fertige Routen so verfügbar machen können- das hatten wir bisher immer mit Screenshots gemacht. Ich werde das mit den Kollegen diskutieren. Diese Dinge werden wir aber frühestens im September nach der Urlaubszeit angehen können.

Für Schulwege brauchen wir natürlich ein etwas anderes Bewertungsprofil gegenüber der Anwendung für Menschen mit Blindheit: Da zählen weniger die Ausstattung von Ampeln mit Vibration und taktilen Bodenbelägen, dafür sind Nebenstraßen und Zebrastreifen vorzuziehen. Sobald wir verschiedene Profile anbieten können, ist Routing für Kinder auf jeden Fall auch eine wichtige Rubrik.

Intern werden Straßenseiten nicht wie bei Nathanael Lang gelöscht, aber sehr negativ bewertet, wenn explizit ein sidewalk dort ausgeschlossen oder als "separate" angegeben ist. Hat die Straße keine Angabe, so werden explizite Wege leicht präferiert; dann hängt es von den lokalen Gegebenheiten ab. Muss man schauen, was bei dir der spezielle Fall war, auf jeden Fall haben wir viel Optimierungspotential; in den Bewertungen und in den Daten. Der Schwerpunkt liegt aber klar auf der generellen Route, die exakte Lokalisierung der Wege können wir nur im Rahmen von Heuristik und der Daten abschätzen.

Bei mir zu Hause klappt es auch nicht mit dem idealen Schulweg, aber da fehlt aber schlicht noch ein Zebrastreifen mit Verkehrsinsel, den ich nur mal eintragen müsste.

sritterbusch wrote:

Routing für Kinder auf jeden Fall auch eine wichtige Rubrik.

Ich finde es aber auch für Kinder durchaus angebracht, das nur an sicheren Stellen gewechselt wird. So unterschiedlich ist das Profil nicht. Auch als Rollator-Benutzer ist passt dies schon besser mit den Angaben.

sritterbusch wrote:

die Ausstattung von Ampeln mit Vibration und taktilen Bodenbelägen

ist aber in OSM sehr dünn. Am meisten bei Haltestellen genutzt; bei uns sind fast keine Kreuzungen damit ausgestattet.

geri-oc wrote:

Ich finde es aber auch für Kinder durchaus angebracht, das nur an sicheren Stellen gewechselt wird. So unterschiedlich ist das Profil nicht. Auch als Rollator-Benutzer ist passt dies schon besser mit den Angaben.

Da stimme ich voll zu, natürlich geht es bei Kindern und bei bewegungseingeschränkten Menschen ebenso um die sicheren Wege und Kreuzungen! Die Unterschiede sind nicht groß, aber wir können sie sehr detailliert abbilden und wollen das in Zukunft durch unterschiedliche Profile auch tun.

geri-oc wrote:

(...Ausstattung von Ampeln mit Vibration und taktilen Bodenbelägen...) ist aber in OSM sehr dünn. Am meisten bei Haltestellen genutzt; bei uns sind fast keine Kreuzungen damit ausgestattet.

Hier geht es mir auch um das Henne-Ei-Problem: Ohne ein Routing mit Straßenseiten machte es kaum einen Unterschied, ob erweiterte Informationen zu Kreuzungspunkten vorhanden waren oder nicht. Jetzt können wir zeigen, dass wir damit etwas anfangen. Wenn die OSM-Daten fehlen, gibt es halt einen Fallback auf sinnvolle Annahmen.

Hi,

fein, dass sich bei dem Thema was tut und sogar getestet werden kann.

Ich habs mal in meiner kleinen Testumgebung hier ausprobiert, wo sidewalk=* häufiger vorkommt. Erwartet hätte ich sowas wie die blaue Linie im Bild, bekommen habe ich die rote:

Der Umweg über die Ampel ist Geschmacksache. Es scheint aber auch so, als ob die beiden Gehwege der Ismaninger Str. nicht so richtig berücksichtigt werden oder der Router den Einstieg auf die Bürgersteige nicht findet. Die Routing-Anweisung verwirrt auch eher mit ihren 4 Querungen der Ismaninger Straße:

auf Sternstraße auf linker Seite
Nach 39 m: Links auf Industriestraße auf linker Seite
Nach 168 m: Rechts Ismaninger Straße überqueren dann bald Geradeaus Ismaninger Straße überqueren
Nach 4 m: Geradeaus Ismaninger Straße überqueren
Nach 32 m: Geradeaus Ismaninger Straße überqueren
Nach 27 m: Links auf Tannenstraße auf linker Seite

Irgendwie werden die Gehwege schon erkannt, aber zu viele (oder so...) und angezeigt wird die Strassenmitte.

Grüße
Max, der sich über jeden freut, der erst mit dem Vorhandenen rechnet und dann überlegt, wie man mappt 😉

maxbe wrote:

fein, dass sich bei dem Thema was tut und sogar getestet werden kann.

Irgendwie war mir alles zuvor so theoretisch und lokal, und damit wollte ich mich für das Projekt nicht abfinden. Ich bin echt froh, dass die Idee dann am Ende auch geklappt hat. Deswegen ist mir die Live-Demo auch so wichtig.

maxbe wrote:

Die Routing-Anweisung verwirrt auch eher mit ihren 4 Querungen der Ismaninger Straße

Das ist ein tolles Beispiel: Kannst du mir erklären, wie die Ismanginger Straße B471 als Hauptstraße ein foot=yes bekommt, und was soll das hier heißen? Bisher haben wir foot=yes wie foot=designated, also als Fußgängerzone, behandelt und laufen daher zentral. Und das bringt den Router hier völlig aus der Rolle, da natürlich so eine Bundesstraße klassisch überquert gehört. 🙄

Ähnliches haben wir in Karlsruhe in Tempo30-Anwohnerstraßen gesehen, wo man aber eher die explizit ausgeführten Sidewalks als die Straße nutzen sollte.

maxbe wrote:

...
Nach 4 m: Geradeaus Ismaninger Straße überqueren
Nach 32 m: Geradeaus Ismaninger Straße überqueren
Nach 27 m: Links auf Tannenstraße auf linker Seite

Irgendwie werden die Gehwege schon erkannt, aber zu viele (oder so...) und angezeigt wird die Strassenmitte.

Die Routenbeschreibung hat noch so ein paar Macken, da sind Beispiele wichtig, dass man das ausbügeln kann. Hier liegt es aber sicher am foot-Tag, der offensichtlich falsch interpretiert wird, oder da nicht hingehört.

maxbe wrote:

Max, der sich über jeden freut, der erst mit dem Vorhandenen rechnet und dann überlegt, wie man mappt 😉

Gerne, aber idealerweise fangen wir gar nicht groß global mit künstlichem Mappen an, sondern nutzen das optimal, was da ist. Und arbeiten wie alle nur lokal, wo wir uns selbst auskennen. Bisher kriegt die OSM-Community das mit dem guten Erfassen der Situation ja schon verdammt gut hin.

sritterbusch wrote:

Kannst du mir erklären, wie die Ismanginger Straße B471 als Hauptstraße ein foot=yes bekommt, und was soll das hier heißen?

foot=yes heißt schlicht, dass Fußgänger auf der Straße erlaubt sind. Ist aber bei highway=primary eh der default.

sritterbusch wrote:

Das ist ein tolles Beispiel: Kannst du mir erklären, wie die Ismanginger Straße B471 als Hauptstraße ein foot=yes bekommt, und was soll das hier heißen?

Nicht von mir 😉

Aber ich finde es hier auch nicht verkehrt. Die Straße ist ohne separate Rad- und Fußwege gemappt, die Tags beziehen sich also auf die gesamte Straße mit 2 Autofahrstreifen, 2 Radstreifchen und 2 Gehwegen. Da ist foot=yes auch angebracht, man darf und soll ja einen der Gehwege benutzen. Bis vor 2 Jahren stand da "foot=use_sidepath", was ich für unglücklich halte, wenn besagter use_sidepath nicht in OSM steht (und ich denke, er stand damals auch nicht drin).

Ja, diese Warnung fehlt leider in der deutschen Version.

englisches WIKI wrote:

Please do not use bicycle=use_sidepath in combination with cycleway=track on the main highway, if there is no separate cycleway drawn on the map.

chris66 wrote:

foot=yes heißt schlicht, dass Fußgänger auf der Straße erlaubt sind. Ist aber bei highway=primary eh der default.

Nun, sie ist secondary.

Und richtig "erlaubt" habe ich mich (de-facto) bisher mitten auf solchen Straßen nicht gefühlt- daher wundert mich diese Interpretation. Es geht aber natürlich nicht um meinen Eindruck, sondern es soll natürlich das Verständnis der Mapper umgesetzt werden.

1. Bist du sicher, dass die deutliche Mehrheit der Mapper foot=yes so versteht?
2. Wie sollte man dann foot=designated interpretieren, und wie erklärt sich das Verhältnis zum Wert yes?
3. Wenn es eher um die theoretische Erlaubnis geht, wo sollte man es überhaupt aufführen?

Bisher kamen wir mit foot=yes als tatsächlich und ungefährlich für Fußgänger frei verfügbare Fläche gut zurecht, aber es gab auch fragliche Stellen. Die Frage ist am Ende, was für eine Auswirkung hat diese Angabe für Fußgänger, an die sich die Angabe offensichtlich richtet, sofern sie angegeben wird gegenüber wenn sie fehlt.

maxbe wrote:

Straße mit 2 Autofahrstreifen, 2 Radstreifchen und 2 Gehwegen. Da ist foot=yes auch angebracht, man darf und soll ja einen der Gehwege benutzen.

Bei zwei angegebenen Gehwegen braucht es noch ein foot=yes der Straße? Also wenn ich das falsch interpretiert habe (mit Unterstützung eines langjährigen Mappers), so fühle ich mich zumindest nicht ganz so schuldig. 🙂

Foot=yes sollte vom Router ignoriert werden, wenn er nicht auf highways steht, die implizit ein foot=no haben (siehe https://wiki.openstreetmap.org/wiki/OSM … strictions )

sritterbusch wrote:

Bei zwei angegebenen Gehwegen braucht es noch ein foot=yes der Straße? Also wenn ich das falsch interpretiert habe (mit Unterstützung eines langjährigen Mappers), so fühle ich mich zumindest nicht ganz so schuldig. 🙂

Es braucht es nicht, ich halte es für unnötig und verwirrend, aber wenn man unbedingt ausdrücken will, dass man da laufen darf, ist es ok.

Wenn ich mir die highway=primary/secondary/.../residential mit foot=yes in meiner Gegend so ansehe, kann man daraus keine Attraktivität für Fußgänger ableiten. Was die Leute dazu motiviert, weiss icgh nicht, ich vermute einen Drang, Formulare vollständig auszufüllen 😉

Bei foot=designated siehts anders aus. Das sind Wege (allerdings selten Straße, oft path oder footway), wo jemand sagt (oder die Behörde widmet), das sei ein Fußweg und vielleicht sogar ein blaues Schild hinstellt. Die würde ich auch als für Fußgänger attraktiv berücksichtigen.

Eher würde ich noch die anderen access-Werte heranziehen. Ein innerstädtischer Weg mit (motor_)vehicle=no wäre zum Beispiel ein schöner Fußweg.

Discostu36 wrote:

Foot=yes sollte vom Router ignoriert werden, wenn er nicht auf highways steht, die implizit ein foot=no haben

Ah, sehr schade, jetzt wird es klar. Aber warum.... 🙄 Sei's drum. Vielen Dank auf jeden Fall für den Hinweis auf die de-jure Interpretation auf der Wiki-Seite zu Access-Restrictions, das werde ich im nächsten Update (...nach der Urlaubszeit...) korrigieren.

Bis dahin kann der Router bei solchen Fällen von foot=yes falsche Ergebnisse liefern. Im Fall von maxbe (und sicher vielen anderen) könnte der redundante Eintrag natürlich gelöscht werden, weil es ohnehin default ist. Dann wäre morgen das Routing dort in Ordnung.

Danke an Alle für den Hilfe!

maxbe wrote:

Es braucht es nicht, ich halte es für unnötig und verwirrend, aber wenn man unbedingt ausdrücken will, dass man da laufen darf, ist es ok.
Wenn ich mir die highway=primary/secondary/.../residential mit foot=yes in meiner Gegend so ansehe, kann man daraus keine Attraktivität für Fußgänger ableiten. Was die Leute dazu motiviert, weiss icgh nicht, ich vermute einen Drang, Formulare vollständig auszufüllen

Ja, da gibt es auch sicher regionale Unterschiede, wie Tags genutzt werden, daher ist es auch so wichtig, das System auch mit Ortswissen an anderen Stellen zu testen. Ich werde das auf jeden Fall im nächsten Update korrigieren. Danke, dass dir das so schnell aufgefallen ist.

maxbe wrote:

Eher würde ich noch die anderen access-Werte heranziehen. Ein innerstädtischer Weg mit (motor_)vehicle=no wäre zum Beispiel ein schöner Fußweg.

Wir versuchen so viel zu nutzen, wie geht. Aber ich glaube vehicle=no war noch nicht auf meiner Liste, toller Vorschlag! Aber leider kommt er nicht sooo oft vor. Update: Bei motor_vehicle=no sieht es besser aus, großartig!

Seltsamer Umweg in Kiel:

Woran liegt das?

Ich sehe gerade, dass die "richtige" Fußgängerampel gar nicht als "crossing" eingetragen ist, damit könnte es wohl zu tun haben.

Discostu36 wrote:

Seltsamer Umweg in Kiel:
https://www.dropbox.com/s/3ckmbad9qqrp9 … g.png?dl=1
Woran liegt das?

Hier der Kartenausschnitt. Die gewählte Überquerung ist (eingetragen&) für Blinde besser ausgestattet (tactile_paving=yes), und die Anzahl der unkontrollierten Übergänge bleibt gleich. Ein Umweg ist da vertretbar.

Es liegt also an dem aktuellen Fokus auf Personen mit Blindheit. Mit einem anderen Profil käme sicher die nähere Überquerung heraus.

OK, danke für die Info. Laut Wiki wohl eine falsche Verwendung für das Tactile-Paving-Tag? Die Rillen begleiten hier ja nicht den ganzen Überweg. Müsste man das nicht an die Bordsteinkanten mappen, wie hier?

Discostu36 wrote:

Laut Wiki wohl eine falsche Verwendung für das Tactile-Paving-Tag? Die Rillen begleiten hier ja nicht den ganzen Überweg. Müsste man das nicht an die Bordsteinkanten mappen, wie hier?

Hm, da kannst du Recht haben, ich weiß es nicht genau. Ich versuche die praktische Anwendung durch die Mapper robust für das Routing umzusetzen. Für das Routing ist es im aktuellen Fokus ja schon ein großer Magnet, wenn überhaupt assistive Technologie angedeutet werden- oben wurde ja gerade schon zurecht beklagt, dass das noch viel zu selten passiert. Ich bin sicher, dass wir das verfeinern müssen, wenn die Nutzung der Angaben genauer und häufiger wird.

Würde es für deine Auswertung einen Unterschied machen, wo der Tag steht?

sritterbusch wrote:

Bisher haben wir foot=yes wie foot=designated, also als Fußgängerzone, behandelt und laufen daher zentral.

Oooauerha!

1. foot=yes an einem Objekt heißt schlicht und einfach „Dieses Objekt kann zu Fuß benutzt bzw. passiert werden“ (letzteres, wenn es ein Hindernis wie z.B. barrier=gate ist). Mehr nicht. An einem highway=secondary ist es default, aber falsch ist es nicht, es dazuzutaggen, höchstens überflüssig. Allgemein gesprochen: foot=* ist ein Access-Tag, und Access-Tags definieren keine Klassen von Verkehrsräumen, sondern Erlaubnisse.

2. foot=designated heißt nicht Fußgängerzone. Eine Fußgängerzone ist in OSM highway=pedestrian.

sritterbusch wrote:

1. Bist du sicher, dass die deutliche Mehrheit der Mapper foot=yes so versteht?

Ich war zwar nicht gefragt, aber ich bin. Steht auch so auf der Wikiseite zu access.

sritterbusch wrote:

2. Wie sollte man dann foot=designated interpretieren, und wie erklärt sich das Verhältnis zum Wert yes?

foot=yes heißt: Die Einrichtung darf von Fußgängern benutzt werden.
foot=designated heißt: Die Einrichtung sollte von Fußgängern bevorzugt benutzt werden, weil sie extra für sie gedacht ist.

Praxisbeispiele:
Ein kombinierter Rad- und Fußweg ist bei uns highway=path + foot=designated + bicycle=designated.
Ein Radweg, der auch Fußgängern offensteht, ist bei uns highway=cycleway + foot=yes.

--ks

Discostu36 wrote:

Würde es für deine Auswertung einen Unterschied machen, wo der Tag steht?

Gute Frage, da muss ich in den Source schauen und es kommt sehr auf die genaue Konstellation an. Ich gehe normalerweise so vor, dass ich prüfe, welche Tags überhaupt regelmäßig genutzt werden. Und da ist die Nutzung von tactile_paving=yes an Punkten und an Crossings am häufigsten. Im Detail wird man das per Hand kaum perfekt spezifizieren können. Ich plane hier die Gewichte über eine große Anzahl von Experten definierten Testfällen automatisiert anzupassen, dann passt sich das auch von selbst an, wenn die Nutzung sich mit der Zeit ändert.

kreuzschnabel wrote:

Oooauerha!

Absolut berechtigter Aufschrei, und wird ja gefixt. Bin ja froh, dass wir so schnell Dinge zum verbessern finden! 🙂

kreuzschnabel wrote:

Praxisbeispiele:
Ein kombinierter Rad- und Fußweg ist bei uns highway=path + foot=designated + bicycle=designated.
Ein Radweg, der auch Fußgängern offensteht, ist bei uns highway=cycleway + foot=yes.

Und genau in dem zweiten Praxisbeispiel hat foot=yes eine völlig andere Bedeutung für Fußgänger als auf einer Hauptstraße, wo der Tag eigentlich fast immer völlig unnötig, aber wie ich jetzt gelernt habe, nicht fehl am Platze ist. 🙄

Wenn sich also jemand an den falschen Routings an Hauptstraßen mit foot=yes stört, kann sich überlegen, kurzfristig eine überflüssige Angabe zu löschen, und ich werde auf jeden Fall im nächsten Update die Interpretation korrigieren.

sritterbusch wrote:

Und genau in dem zweiten Praxisbeispiel hat foot=yes eine völlig andere Bedeutung für Fußgänger als auf einer Hauptstraße,

Inwiefern? In beiden Fällen heißt er: „Fußgänger dürfen hier langgehen“.

Merke: Der OSM-Way der Hauptstraße steht für das gesamte Verkehrsbauwerk inkl. aller Fahrspuren und Bürgersteige, nicht nur für die Mittellinie. Freilich gilt das foot=yes in dem Fall für die Bürgersteigbestandteile, die im Way ebenso enthalten sind wie die Fahrbahnen. Das vor Ort zu entscheiden trauen wir dem Fußgänger zu.

--ks

kreuzschnabel wrote:

Inwiefern? In beiden Fällen heißt er: „Fußgänger dürfen hier langgehen“.
(...)
Das vor Ort zu entscheiden trauen wir dem Fußgänger zu.

Vielen Dank für den guten Hinweis. Für Menschen mit unterschiedlichen Fähigkeiten liegen die praktischen Bedeutungen meilenweit auseinander, und darum muss ich mich kümmern. Dass es eine logische Darstellung gibt, in der die angegebene Informationen einen Sinn macht, sehe ich doch völlig ein. Wir brauchen über das Thema aber nicht diskutieren oder uns gegenseitig belehren. Was zählt, ist, wie es in der OSM genutzt und verstanden wird, und entsprechend wird die Interpretation ab dem nächsten Update korrigiert, damit in diesen Spezialfällen bessere Routen herauskommen.

In Reaktion auf die hilfreichen Hinweise von maxbe, discostu36 und kreuzschnabel habe ich die bisherige Bewertung von foot=yes zumindest in der topologischen Erweiterung und dem Routing auf Rad- und Pferdewege beschränkt. Dadurch wird im Beispiel von maxbe nun die erwartete Ampel benutzt.

Wie im Video auf der GPN18 beschrieben, ist der Erweiterungsprozess aber zweistufig: Deshalb ist die die Darstellung und Beschreibung noch bis zum nächsten Serverupdate leider in diesem Beispiel noch nicht ganz so gut, solange der eigentlich nicht benötigte und falsch interpretierte Tag foot=yes beibehalten wird.

Danke für eure Hilfe!

kreuzschnabel wrote:

Freilich gilt das foot=yes in dem Fall für die Bürgersteigbestandteile, die im Way ebenso enthalten sind wie die Fahrbahnen

M.E. sollte aber ähnlich wie bicycle:lane=both/left/right auch sidewalk=both/left/right an so eine Straße, wenn ich schon mit foot=yes den default-Wert überschreibe.

Was ist , wenn nur einseitiger sidewalk vorhanden ist? Dann muss ich die Straße queren, was routingmäßig erschwerend wirken sollte. Ist dazu kerb=* als Erleichterung eingetragen?

Der Router benutzt im Moment track=cycleway. Zumindest in Deutschland ist der Standard für diese Wege foot=no (siehe Wiki-Link, den ich auf Seite 1 gepostet habe). Diese Wege sollten also nicht genutzt werden, wenn sie kein explizites foot=yes haben.

Mir sind gerade zwei Dinge aufgefallen, die auf jeden Fall schnell geändert werden sollten:

1. Der Router weigerte sich an einigen stellen über highway=service zu routen. Er schick dafür sogar durch den Wald mit tracktype=grade5.
An einer anderen stelle schickte er dagegen über einen highway=service, der zusätzlich mit maxspeed=30; surface=sand und tracktype=grade5 getaggt ist.

2. Der Router scheint Barrieren(Im getesteten Fall: barrier=gate; access=no) noch nicht zu beachten.

geri-oc wrote:

M.E. sollte aber ähnlich wie bicycle:lane=both/left/right auch sidewalk=both/left/right an so eine Straße, wenn ich schon mit foot=yes den default-Wert überschreibe.

Was ist , wenn nur einseitiger sidewalk vorhanden ist? Dann muss ich die Straße queren, was routingmäßig erschwerend wirken sollte. Ist dazu kerb=* als Erleichterung eingetragen?

Nach der bisherigen Diskussion hat foot=yes außer bei Radwegen oder Pferdepfaden (und Autobahnen) keine Information und ist dann immer redundant. Ich vermute, dass es aber häufig anders gemeint war, aber soweit es auch an Hauptstraßen verwendet wird, muss ich es explizit ignorieren.

Ja, wenn ein sidewalk nur auf einer Seite ist, so wird man erst eine Überquerung machen müssen. Das ist ja die Grundidee.

Die meisten kerb-Tags müssten übrigens für Nutzer mit Blindheit eher negativ gewertet werden: Diese helfen Rollstuhlfahrern, aber erschweren das Ertasten der Kanten mit dem Langstock. Dazu gibt es eine lange Diskussion zwischen den beiden Nutzergruppen über die Mindest- und Maximalhöhe. Es wäre daher tatsächlich relevant bei kerb die Höhe mit aufzuzeichnen.

Aktuell werte ich kerb nicht aus.

Discostu36 wrote:

Der Router benutzt im Moment track=cycleway. Zumindest in Deutschland ist der Standard für diese Wege foot=no (siehe Wiki-Link, den ich auf Seite 1 gepostet habe). Diese Wege sollten also nicht genutzt werden, wenn sie kein explizites foot=yes haben.

Tatsächlich gibt es überhaupt keine grundsätzlichen Verbote, sondern eine Abstufung in der Bewertung. Aber tatsächlich werden auch cycleways relativ präferiert genutzt, weil das meines Erachtens der praktischen Realität entspricht. Gibt es in der Nähe einen Fußweg, so sollte dieser vorgezogen werden. Das ist ein Maß der Abwägung.

Wenn der cycleway aber ein foot=yes hat, so ist er äquivalent mit einem footway.

SpaLeo wrote:

Mir sind gerade zwei Dinge aufgefallen, die auf jeden Fall schnell geändert werden sollten:
1. Der Router weigerte sich an einigen stellen über highway=service zu routen. Er schick dafür sogar durch den Wald mit tracktype=grade5.
An einer anderen stelle schickte er dagegen über einen highway=service, der zusätzlich mit maxspeed=30; surface=sand und tracktype=grade5 getaggt ist.

Danke für das Testen! Dass highway=service irgendwo komplett vermieden wird, muss ich mir ansehen. Das sollte nicht so sein. Der grade5 ist definitiv ein Fehler, das hatten wir schon früher mal, aber vielleicht ist uns das wieder untergekommen. Kannst du einen Beispiel-Track als Bild oder Start und Ziel-Koordinaten posten?

SpaLeo wrote:

2. Der Router scheint Barrieren(Im getesteten Fall: barrier=gate; access=no) noch nicht zu beachten.

Ja, bei den Barrieren sind wir noch nicht alle genau durchgegangen, welche in Ordnung sind und welche nicht. Kannst du mir den Fall wie oben als Testkandidat zur Verfügung stellen?

sritterbusch wrote:

Tatsächlich gibt es überhaupt keine grundsätzlichen Verbote, sondern eine Abstufung in der Bewertung. Aber tatsächlich werden auch cycleways relativ präferiert genutzt, weil das meines Erachtens der praktischen Realität entspricht.

Ich weiß nicht so genau, was du damit meinst. In wie fern entspricht es der praktischen Realität, dass man auf ausgezeichneten Radwegen laufen sollte? Hier in Kiel begibt man sich damit zumindest in Lebensgefahr - und als Blinder wohl erst recht.

Gibt es in der Nähe einen Fußweg, so sollte dieser vorgezogen werden.

Geschieht hier anscheinend nicht (auf der anderen Straßenseite von Wilhelmplatz ist ein getaggter Fußweg, wird aber meist nicht verwendet).

Discostu36 wrote:

Ich weiß nicht so genau, was du damit meinst. In wie fern entspricht es der praktischen Realität, dass man auf ausgezeichneten Radwegen laufen sollte? Hier in Kiel begibt man sich damit zumindest in Lebensgefahr - und als Blinder wohl erst recht.
...
Geschieht hier anscheinend nicht (auf der anderen Straßenseite von Wilhelmplatz ist ein getaggter Fußweg, wird aber meist nicht verwendet).

Ich habe es mir angesehen, diese starke Trennung nach Seiten gibt es hier in Karlsruhe eher nicht. Ausgezeichnet, dass wir hier so unterschiedliche Orte testen! Ich habe die Penalty für den Radweg (ohne foot=yes...) so erhöht, dass es nicht mehr dazu kommen sollte. Wird spannend, ob dann in Karlsruhe einige erwartete Routen brechen...

Discostu36 wrote:

Geschieht hier anscheinend nicht (auf der anderen Straßenseite von Wilhelmplatz ist ein getaggter Fußweg, wird aber meist nicht verwendet).

Da fällt mir auf, dass der Überweg genau des Fußwegs über die Eckernförder Straße kein Crossing hat, dabei glaube ich da im 3D-Satellitenbild eine Fußgänger-Ampel zu sehen. Dadurch wird an der Kreuzung die Radfahrer-Seite benutzt, da es da zumindest laut OSM tactile_paving und Ampeln gibt. Das hatte den zusätzlichen Effekt das Routing auf die Radfahrseite zu ziehen, und dann den auch zuvor schon etwas schlechter bewerteten Radweg trotzdem zu nutzen, statt dann wieder zu queren. Sehr gut, dass sowas jetzt auffällt. 🙂

Ich sollte wohl lieber mal anfangen, die Crossings in meiner Gegend zu prüfen, bevor ich mich über das Routing beschwere.

sritterbusch wrote:

Deshalb ist die die Darstellung und Beschreibung noch bis zum nächsten Serverupdate leider in diesem Beispiel noch nicht ganz so gut, solange der eigentlich nicht benötigte und falsch interpretierte Tag foot=yes beibehalten wird.

Ich hab das foot=yes vorgestern gelöscht, schaun wir mal nach dem nächsten Update.

Kann es sein, dass Ihr surface=gravel recht schlecht bewertet und das eher nichtssagende surface=unpaved recht gut? Ich vermute zwar, Ihr interessiert Euch eher für Städte als für Wanderwege in der Wildnis, aber auch im Stadtpark könnte der Kiesweg interessant sein....

Ich wollte den Weg am Kanal entlang (hw=path, bicycle=yes, smoothness=bad, surface=gravel) laufen. Alternativ hätte ich auch den etwas breiteren parallelen Weg (track, grade2, surface=gravel, smoothness=good) genommen. Ihr lasst mich einen halben Kilometer weiter laufen, nur um den Trampelpfad (footway, surfce=unpaved, width=0.5, bicycle=yes) zu nutzen. Das wird vermutlich keiner Zielgruppe gerecht, nicht mal den Trampelpfadliebhabern:

(Diese Gegend)

Fallsdieses Ergebnis wirklich an der Gewichtung von surface und smoothness liegt: Ich würde bei surface=gravel|unpaved... die smoothness genauer ansehen. "smoothness=good" halte ich für recht fußgängerfreundlich.

Grüße
Max

PS: Jo, Link auf 2 Koordinaten wäre echt gut, grad zum Testen 😉

maxbe wrote:

dass Ihr surface=gravel recht schlecht bewertet

Wozu man wissen muss, dass surface=gravel häufig für wassergebundene Decken aus verdichtetem Mineralgemisch verwendet wird, was damit zusammenhängen dürfte, dass man das im Deutschen umgangssprachlich als „geschottert“ oder „Schotterweg“ bezeichnet. Einklich ist surface=gravel nur lose geschütteter Schotter (schwer zu gehen), während eine wassergebundene Decke (gut zu gehen) in OSM surface=compacted sein sollte.

--ks

kreuzschnabel wrote:

... dass man das im Deutschen umgangssprachlich als „geschottert“ oder „Schotterweg“ bezeichnet. Einklich ist surface=gravel nur lose geschütteter Schotter (schwer zu gehen), während eine wassergebundene Decke (gut zu gehen) in OSM surface=compacted sein sollte.

--ks

+1 ... war übrigens auch einer meiner Anfängerfehler, zu sehr auf die "Übersetzung" geachtet, als auf die eigentliche Definition ... habe zwischendurch einige meiner surface=gravel durch surface=compacted ersetzt.

sritterbusch wrote:

SpaLeo wrote:

Mir sind gerade zwei Dinge aufgefallen, die auf jeden Fall schnell geändert werden sollten:
1. Der Router weigerte sich an einigen stellen über highway=service zu routen. Er schick dafür sogar durch den Wald mit tracktype=grade5.
An einer anderen stelle schickte er dagegen über einen highway=service, der zusätzlich mit maxspeed=30; surface=sand und tracktype=grade5 getaggt ist.

Danke für das Testen! Dass highway=service irgendwo komplett vermieden wird, muss ich mir ansehen. Das sollte nicht so sein. Der grade5 ist definitiv ein Fehler, das hatten wir schon früher mal, aber vielleicht ist uns das wieder untergekommen. Kannst du einen Beispiel-Track als Bild oder Start und Ziel-Koordinaten posten?

Hier Screenshots und die Koordinaten:

Routing um highway=service, hier mit service=parking_aisle:

https://www.openstreetmap.org/#map=17/52.58590/13.17672

Routing um highway=service:

https://www.openstreetmap.org/#map=18/52.57280/13.19845

Routing über highway=service mit surface=sand und tracktype=grade5. Außerdem etwas fehlplatzierte Linie.

https://www.openstreetmap.org/#map=18/52.56931/13.21074

sritterbusch wrote:

SpaLeo wrote:

2. Der Router scheint Barrieren(Im getesteten Fall: barrier=gate; access=no) noch nicht zu beachten.

Ja, bei den Barrieren sind wir noch nicht alle genau durchgegangen, welche in Ordnung sind und welche nicht. Kannst du mir den Fall wie oben als Testkandidat zur Verfügung stellen?

Die Barriere ist hier:https://www.openstreetmap.org/#map=19/52.57544/13.19276 (Inzwischen in access=private geändert.)

SpaLeo wrote:

hier mit service=parking_aisle

… das, nebenbei bemerkt, falsch ist. Die Zufahrt zu einem bzw. Durchfahrt über einen Parkplatz bekommt _kein_ parking_aisle, nur die kleinen Parkgässchen von da zur einzelnen Parkposition haben es. Im Wiki ist ein deutliches Bild dazu.

--ks

Wie kommen denn diese Zacken zustande, statt den Übergang zu verwenden?

Was anderes: Ich habe mir über Routing für Blinde noch nie Gedanken gemacht und bin auch nie mit Sehbehinderten unterwegs. Sind für die Kurven unangenehm? Ich habe nämlich den Eindruck, dass der Router gerne abbiegt statt ein paar Schritte mehr zu laufen. Diagonal über den Hofgarten kann ich entweder am Rand mit einer 90-Grad-Kurve gehen oder dem Router folgend quer durch mit 8x Abbiegen, 2 Viertelkreisen um die Brunnen und einem Halbkreis um den Pavillion in der Mitte. Der Weg durch die Mitte mag schöner sein, aber die Gefahr der Verwirrung ist auch hoch.

(ist schon klar, dass wir hier mühsam die wenigen fiesen Grenzfälle suchen und die eine falsche Strassenüberquerung anmeckern und die 1000 richtigen gar nicht erwähnen?)

maxbe wrote:

Ich hab das foot=yes vorgestern gelöscht, schaun wir mal nach dem nächsten Update.

Danke, aktuell läuft er aber noch auf der Straße, ich weiß aber nicht, ob die Änderung schon beim Provider durch ist, und ob unser täglicher Update womöglich hängt (hoffentlich nicht).

maxbe wrote:

Kann es sein, dass Ihr surface=gravel recht schlecht bewertet und das eher nichtssagende surface=unpaved recht gut? Ich vermute zwar, Ihr interessiert Euch eher für Städte als für Wanderwege in der Wildnis, aber auch im Stadtpark könnte der Kiesweg interessant sein....
Ich wollte den Weg am Kanal entlang (hw=path, bicycle=yes, smoothness=bad, surface=gravel) laufen. Alternativ hätte ich auch den etwas breiteren parallelen Weg (track, grade2, surface=gravel, smoothness=good) genommen. Ihr lasst mich einen halben Kilometer weiter laufen, nur um den Trampelpfad (footway, surfce=unpaved, width=0.5, bicycle=yes) zu nutzen. Das wird vermutlich keiner Zielgruppe gerecht, nicht mal den Trampelpfadliebhabern

Das wird etwas komplizierter. Zunächst einmal sollte laut deutschem Wiki ein "nicht einmal Trampelpfad" eher kein "Footway" sein: Hier wird highway=path für "Mehrzweck-Pfade" (Rad-/Fußwege, Wanderwege, Trampelpfade) empfohlen. Der zentrale Weg ist als Track in der Bewertung als "Wirtschaftsweg" einer wenig befahrenen Straße gleichgesetzt- das überflüssige foot=yes ist hier sicher als gut gemeinter Hinweis gemeint, wird aber wegen der bisherigen Diskussion nun ignoriert. Dieser Fall lässt mich auch überdenken, ob man nicht doch den Tag entgegen der "Regeln" etwas vorteilhafter ansehen sollte. Der direkte "track" wird nicht besser als ein "path" bewertet, weil Trampelpfade nicht für die betrachtete Klientel in Frage kommen. Tatsächlich sind die Unterschiede aber nicht so groß, je nach Start- und Endpunkt ging bei mir der vorgeschlagene Pfade oft über den mittleren "path".

Schwierig wird es in der Abwägung, welche Bodenqualitäten und Wegtypen man wie gegeneinander abwägt. Hier sind eigentlich alle Wege relativ schlecht für Menschen mit Blindheit, daher wundert mich etwas komischeres Verhalten nicht so sehr. Aber wenn man später sehende Personengruppen berücksichtigt, muss man das irgendwann angehen, und dabei auch berücksichtigen, dass nicht alle Mapper gleich die Wege eintragen, man also alles auch mit etwas Unschärfe betrachten muss.

maxbe wrote:

PS: Jo, Link auf 2 Koordinaten wäre echt gut, grad zum Testen 😉

Hey, im Screenshot wären die Koordinaten ja zu sehen, wenn du sie nicht löscht... 😄

Ich habe gerade wenig Netz, daher kommen meine Antworten aktuell nicht so schnell.

sritterbusch wrote:

Zunächst einmal sollte laut deutschem Wiki ein "nicht einmal Trampelpfad" eher kein "Footway" sein:

Ja, aber leider, leider ist das sehr uneinheitlich, weil ein gepflasterter Rad-und Fußweg im Wohngebiet für uns ebenso hw=path ist wie ein Trampelpfad im Gebirge.

Das wird in England und Wales besonders schlimm, wo es Wegerechte gibt (public rights of way), die je nach Nutzungsfrequenz unter Umständen gar nicht als Weg in der Natur sichtbar sein müssen, sondern nur das Recht abbilden, da langzugehen. Eine Karte muss diese Wegerechte darstellen, sonst ist sie für Wanderer, Radfahrer und Reiter ziemlich unbrauchbar (wer will schon nur auf öffentlichen Straßen wandern). Und diese Wegerechte sind noch sehr, sehr oft als highway=footway ohne jede weitere Einzelheit getaggt, als seien es angelegte Fußwege.

--ks

sritterbusch wrote:

Danke, aktuell läuft er aber noch auf der Straße, ich weiß aber nicht, ob die Änderung schon beim Provider durch ist, und ob unser täglicher Update womöglich hängt (hoffentlich nicht).

Sieht ganz danach aus.
Ich habe in meinem Dorf am 16. + 17.8. an verschiedenen Straßen sidewalk=yes/both/left/right/no ergänzt. Das wird beim Routing aber (noch ?) nicht berücksichtigt.

Grüße

Wie werden / sollen die Routinganweisungen eigentlich an Blinde weitergegeben werden? Per Sprachansage oder wie ?
Wie genau sollen / müssen die Routinganweisungen sein ? Normale Handys bzw. Navis haben ja Abweichungen vom tatsächlichen Standort von mehreren Metern.

Fragende Grüße

PS: Fragen haben sich - nach Sichtung des Videos - erledigt.

Danke SpaLeo für die vielen Beispiele. Aus Vorsicht hatte ich highway=service nicht so gut wie Anwohnerstraßen ohne Angaben zu Bürgersteigen bewertet, da es hier normalerweise keine Bürgersteige oder sonstige Vorkehrungen für Fußgänger gibt. Damit fielen sie aber in die gleiche Sparte wie z.B. highway=primary ohne Angabe zu Bürgersteigen, die natürlich unbedingt umgangen werden sollte. Tatsächlich liegen sie aber wohl eher dazwischen, und das habe ich nun darauf angepasst. Wie immer ist das eine Abwägung, es kann also Stellen geben, wo das schief geht.

SpaLeo wrote:

Routing um highway=service, hier mit service=parking_aisle:
https://share.leolenz.de/terrain-screen-1.png
https://www.openstreetmap.org/#map=17/52.58590/13.17672

Läuft jetzt wie erwartet. Die Breite von Service-Wegen wird nur falsch eingeschätzt.

SpaLeo wrote:

Routing um highway=service:
https://share.leolenz.de/terrain-screen-2.png
https://www.openstreetmap.org/#map=18/52.57280/13.19845

Läuft jetzt wie erwartet.

SpaLeo wrote:

Routing über highway=service mit surface=sand und tracktype=grade5. Außerdem etwas fehlplatzierte Linie.
https://share.leolenz.de/terrain-screen-3.png
https://www.openstreetmap.org/#map=18/52.56931/13.21074

Das muss ein Bug in der Datenextraktion sein, die Bewertung sollte alles über grade2 eher ausschließen, mir scheint, dass die Daten nicht weitergereicht werden. Wird später noch untersucht. Die wackelnde Linie, sofern sie sich nicht schon durch die unterschiedlichen Wegtypen erklärt, ist schon auf der ToDo-Liste.

SpaLeo wrote:

Die Barriere ist hier:https://www.openstreetmap.org/#map=19/52.57544/13.19276 (Inzwischen in access=private geändert.)

Da habe ich noch nichts geändert; aktuell wird das Gate mit 1000m Aufwand bewertet, das ist schon sehr viel. Geht man etwas weiter weg vom Gate, so wird eine alternative Route vorgeschlagen. Wie gesagt sind die barriers sowieso noch ein offener Punkt, an dem wir noch arbeiten müssen. Ich weiß auch noch nicht, wie wir mit Fällen umgehen sollen, die von Zeit zu Zeit offen sind. Auf jeden Fall danke für das Beispiel, wo es so noch nicht gut klappt.

PT-53 wrote:

sritterbusch wrote:

Danke, aktuell läuft er aber noch auf der Straße, ich weiß aber nicht, ob die Änderung schon beim Provider durch ist, und ob unser täglicher Update womöglich hängt (hoffentlich nicht).

Sieht ganz danach aus.
Ich habe in meinem Dorf am 16. + 17.8. an verschiedenen Straßen sidewalk=yes/both/left/right/no ergänzt. Das wird beim Routing aber (noch ?) nicht berücksichtigt.

Grüße

Das Update läuft anscheinend immer noch nicht.

Grüße aus Oberschwaben

maxbe wrote:

Wie kommen denn diese Zacken zustande, statt den Übergang zu verwenden?
https://geo.dianacht.de/bilder/terrain_ … ndorff.png

Ohne crossings sind das zwei unmarkierte Übergänge wie der so genannte "Sicherheitsübergang" über nur eine Fahrbahn, den der Router vorschlägt. Das Verhalten für "Sicherheitsübergänge" ist nicht einprogrammiert, sondern kam einfach bei der Bewertung automatisch so heraus. Nach Rücksprache mit einem Blinden ist das typisches und empfohlenes Verhalten (da lernte ich auch die Bezeichnung), um die kritische Phase des Überquerens zu minimieren. Ein diesem Fall sollte aber mit entsprechenden crossing-Nodes die Lage geklärt werden können.

Die Haken sind natürlich generell nicht schön, keine Frage. Sowas gibt es auch an anderen Stellen, und wir arbeiten an Methoden, wie man sie umgehen kann.

maxbe wrote:

Was anderes: Ich habe mir über Routing für Blinde noch nie Gedanken gemacht und bin auch nie mit Sehbehinderten unterwegs. Sind für die Kurven unangenehm? Ich habe nämlich den Eindruck, dass der Router gerne abbiegt statt ein paar Schritte mehr zu laufen. Diagonal über den Hofgarten kann ich entweder am Rand mit einer 90-Grad-Kurve gehen oder dem Router folgend quer durch mit 8x Abbiegen, 2 Viertelkreisen um die Brunnen und einem Halbkreis um den Pavillion in der Mitte. Der Weg durch die Mitte mag schöner sein, aber die Gefahr der Verwirrung ist auch hoch.

Zunächst wird man niemanden zentimetergenau leiten können; mit Galileo und DPGS wollen wir zunächst Metergenauigkeit erreichen. Dazu gehört es zum Mobilitätstraining, dass man selbst entscheiden kann, wo man entlang gehen kann. Aber natürlich sollte das Routing schon möglichst nah an der optimalen Linie sein. Hier sind es aber nicht gerade Linien oder Kurven, die zählen, sondern tastbare Abgrenzungen, wie Mauern und Hauswände, die ein Verfolgen mit dem Langstock oder Gehör erleichtern. Das berücksichtigen wir aber bisher nicht, es gibt aber schon Forschungsarbeiten, die "Orientierungslinien" aus Kartenmaterial herausarbeiten, und vielleicht können wir das bald auch einbauen.

Bisher werte ich aber die Richtungsänderung noch nicht aus, nicht nur deswegen (s.o.) können deswegen sehr harte Kurven dabei herauskommen, die auch die Richtungsbeschreibungen (rechts/links) leider manchmal ungenau machen.

maxbe wrote:

(ist schon klar, dass wir hier mühsam die wenigen fiesen Grenzfälle suchen und die eine falsche Strassenüberquerung anmeckern und die 1000 richtigen gar nicht erwähnen?)

Dafür ist das Testinterface doch da, und danke, dass ihr so viel ausprobiert! Natürlich freue ich mich auch über positive Rückmeldungen, aber verbessern können wir es nur an den Problemfällen. Aber klar ist auch, dass wir nicht alle Probleme aus der Welt räumen können: Selbst Experten können alleine aus dem Kartenmaterial nicht die besten Routen bestimmen.

Noch ein paar kleine Anmerkungen:

• tunnel=building_passage sollte vom Router angesagt werden, um Überraschungen zu vermeiden.
• Highway=service hat in der Regel keinen Bürgersteig. Dies sollte beim Zeichnen der Linie berücksichtigt werden.
• Indoor-Mapping wird bisher noch nicht in Ansagen umgesetzt ("Gebäude Sophienhof betreten"?). Ich bin mir auch nicht sicher, ob das Routing durch Gebäude hindurch (wenn das Ziel nicht in ihnen liegt) sinnvoll ist
• Sollten Nutzer evtl. darauf hingewiesen werden, wenn sich auf ihrem Fußweg ein Fahrradstreifen (segregated) befindet?
• Barriers sollten angesagt werden ("Durch Tor hindurch", "An Poller vorbei")

Nur, damit dir nicht die Ideen ausgehen ;-)

Hier im Beispiel sind keine sidewalks oder Fußgängerübergänge gemappt. Sollte der Router aber nicht annehmen, dass an den traffic lights Paffrather Straße/Dellbrücker Straße und Paffrather Straße/Flachsberg auch beampelte Fußgängerübergänge sind und dann darüber routen? Das Überqueren der Paffrather Staße an der Stelle in der Kurve ist extrem gefährlich (und in der Realität würde man auf der gegenüberliegenden Seite sogar von einer Kette am Verlassen der Fahrbahn gehindert werden).

Moin,

TZorn wrote:

Sollte der Router aber nicht annehmen, dass an den traffic lights Paffrather Straße/Dellbrücker Straße und Paffrather Straße/Flachsberg auch beampelte Fußgängerübergänge sind und dann darüber routen?

Es mag vielleicht die Regel sein - aber es gibt eben auch Ausnahmen, wo dann genau kein Fußgängerübergang dort ist.
Wenn der Router schon rät, dann doch bitte höchstens genauso unsicher - also nur einen einfachen ungesicherten Übergang und nicht einen gesicherten!

Grüße, Georg

TZorn wrote:

... und in der Realität würde man auf der gegenüberliegenden Seite sogar von einer Kette am Verlassen der Fahrbahn gehindert werden.

Und woher soll der Router das wissen? Dann sollte dort ein footway parallel laufen mit barrier. Auch an vielen Kreuzungen sind extra Geländer angebracht. Das kann ein Router aber nur nutzen, wenn es in den Daten ist.

TZorn wrote:

...Sollte der Router aber nicht annehmen, dass an den traffic lights Paffrather Straße/Dellbrücker Straße und Paffrather Straße/Flachsberg auch beampelte Fußgängerübergänge sind und dann darüber routen?...

Nein, warum sollte ein Router annehmen, dass bei einem Knoten, der nur mit "highway=traffic_signals" getagt ist, eine Fußgängerüberquerung ist?

Selbst im Wiki steht https://wiki.openstreetmap.org/wiki/Tag … ic_signals, dass erst ein crossing=traffic_signals dran müsste und dann wäre es in dem konkreten Fall (highway=traffic_signals + croossing=traffic_signals in der Mitte der T-Kreuzung) immer noch nicht eindeutig, ob der Fußgängerübergang von der linken zur rechten Seite der Nußbaumer Straße und/oder der Übergang von der linken auf die rechte Seite der Paffrather Straße möglich ist.

Von daher muss für ein sicheres Routing schon ein eindeutiger Knoten mit highway=crossing+crossing=traffic_signals an die Nußbaumer und/oder Paffrather Straße.

GeorgFausB wrote:

Es mag vielleicht die Regel sein - aber es gibt eben auch Ausnahmen, wo dann genau kein Fußgängerübergang dort ist.
Wenn der Router schon rät, dann doch bitte höchstens genauso unsicher - also nur einen einfachen ungesicherten Übergang und nicht einen gesicherten!

Andreas Binder wrote:

Nein, warum sollte ein Router annehmen, dass bei einem Knoten, der nur mit "highway=traffic_signals" getagt ist, eine Fußgängerüberquerung ist?

Selbst im Wiki steht https://wiki.openstreetmap.org/wiki/Tag … ic_signals, dass erst ein crossing=traffic_signals dran müsste und dann wäre es in dem konkreten Fall (highway=traffic_signals + croossing=traffic_signals in der Mitte der T-Kreuzung) immer noch nicht eindeutig, ob der Fußgängerübergang von der linken zur rechten Seite der Nußbaumer Straße und/oder der Übergang von der linken auf die rechte Seite der Paffrather Straße möglich ist.

Von daher muss für ein sicheres Routing schon ein eindeutiger Knoten mit highway=crossing+crossing=traffic_signals an die Nußbaumer und/oder Paffrather Straße.

Ich wage zu behaupten, dass in der überwiegenden Zahl der Fälle, wo keine Gehwege gemappt sind und ein einfaches hw=traffic_signals gesetzt ist, auch ein Fußgängerüberweg vorhanden ist. Die Wahrscheinlichkeit, dass ein sehbehinderter Fußgänger an einer solchen Kreuzung eine Straße sicher überqueren kann, erscheint mir jedenfalls allemal höher, als wenn er einfach quer über ein secondary geschickt wird, dazu noch grade mal 15m von einer Ampelanlage weg, wo viele Autofahrer nicht mit kreuzenden Fußgängern rechnen.

geri-oc wrote:

Und woher soll der Router das wissen?

Gar nicht, darum hab ich es auch in Klammern geschrieben. Aber es soll verdeutlichen, dass auch das Straßeüberqueren außerhalb von Überwegen mit ebensolchen Unsicherheiten verbunden ist, wie ob eine Kreuzung eine Fußgängerampel hat oder nicht.

kreuzschnabel wrote:

sritterbusch wrote:

Zunächst einmal sollte laut deutschem Wiki ein "nicht einmal Trampelpfad" eher kein "Footway" sein:

Ja, aber leider, leider ist das sehr uneinheitlich, weil ein gepflasterter Rad-und Fußweg im Wohngebiet für uns ebenso hw=path ist wie ein Trampelpfad im Gebirge.

Die Frage ist ja, woran man tatsächlich gut und sicher begehbare Wege dann erkennen kann. Eventuell müssen wir irgendwann anfangen, die Wegtypen je nach Ort unterschiedlich zu bewerten. Am besten wäre es natürlich, wenn die Darstellung auch ohne Kontext ausreichen würde.

kreuzschnabel wrote:

Das wird in England und Wales besonders schlimm, wo es Wegerechte gibt

Oh, manchmal ist es als Wanderer schon sehr schwer dieses Recht durchzusetzen. Ich bin schon gespannt, was alles herauskommt, wenn wir die Kartendaten über D-A-CH hinaus erweitern...

PT-53 wrote:

Das Update läuft anscheinend immer noch nicht.

Ja, kann ich leider bestätigen, dass der Update noch hängt 🙁 . Bin echt gespannt, was diesmal der Grund ist. Wir erfahren es, wenn der Kollege aus dem Urlaub zurück ist. Grüße zurück von Langeoog.

Discostu36 wrote:

Noch ein paar kleine Anmerkungen:

• tunnel=building_passage sollte vom Router angesagt werden, um Überraschungen zu vermeiden.
• Barriers sollten angesagt werden ("Durch Tor hindurch", "An Poller vorbei")
• Indoor-Mapping wird bisher noch nicht in Ansagen umgesetzt ("Gebäude Sophienhof betreten"?). Ich bin mir auch nicht sicher, ob das Routing durch Gebäude hindurch (wenn das Ziel nicht in ihnen liegt) sinnvoll ist

Sehr gute Vorschläge! Die Hinweise auf im Test-Interface sind aber nicht die Ansagen im eigentlichen System. Ich habe diese zur Demonstration dort umgesetzt. Die eigentlichen Hinweise sind deutlich knapper und werden mit Experten für Mobilitätstraining umgesetzt. Es gibt da tatsächlich zwei Ausrichtungen: Entweder man macht es sehr knapp, damit es während der Bewegung im Straßenverkehr nicht unnötig stört, oder man sagt für die z.B. nächsten 5 Minuten in einem längeren Text an, was jetzt alles passieren wird. Für die zweite Variante sind wir in Kontakt mit Forschenden aus Prag, die für die zweite Variante Textbausteine entwerfen.

Discostu36 wrote:

Highway=service hat in der Regel keinen Bürgersteig. Dies sollte beim Zeichnen der Linie berücksichtigt werden.

Ja, aber auch dann sollten meiner Meinung nach Fußgänger auf hw=service lieber an der Seite laufen. Die angenommenen Breiten stimmen aber definitiv nicht.

Discostu36 wrote:

Sollten Nutzer evtl. darauf hingewiesen werden, wenn sich auf ihrem Fußweg ein Fahrradstreifen (segregated) befindet?

Das ist ein interessanter Punkt; bisher kommt diese Ansage ja nur, wenn man sich auf einem Radweg mit Fußgänger-Erlaubnis befindet. Ich nehme die Idee mal auf, das ist sicher ein guter Punkt für weitere Sicherheitsinformationen.

Discostu36 wrote:

Nur, damit dir nicht die Ideen ausgehen ;-)

Hey, ich bin ja froh, dass es jetzt Rückmeldungen gibt. Hatte schon den Verdacht, dass niemand aus der OSM den Vortrag mitbekommen hatte.

TZorn wrote:

Hier im Beispiel sind keine sidewalks oder Fußgängerübergänge gemappt. Sollte der Router aber nicht annehmen, dass an den traffic lights Paffrather Straße/Dellbrücker Straße und Paffrather Straße/Flachsberg auch beampelte Fußgängerübergänge sind und dann darüber routen? Das Überqueren der Paffrather Staße an der Stelle in der Kurve ist extrem gefährlich (und in der Realität würde man auf der gegenüberliegenden Seite sogar von einer Kette am Verlassen der Fahrbahn gehindert werden).
https://abload.de/img/fugngerrouting_01bdet0.jpg

Karte. Diese Regel hatte ich bisher nur für fußgängerfreundliche Straßen aktiv, jetzt habe ich sie auch für größere Straßen mit deutlich mehr Penalty aktiviert. Jetzt läuft er wie erwartet über die Ampel.

sritterbusch wrote:

Jetzt läuft er wie erwartet über die Ampel.

OK. Aber woher kommt der Seitenwechsel auf der Nußbaumer Straße? Auf beiden Straßenseiten ist ein hw=service zu queren, ich sehe keine Unterschiede und nichts, was zwei Straßenquerungen rechtfertigen würde.

GeorgFausB wrote:

TZorn wrote:

Sollte der Router aber nicht annehmen, dass an den traffic lights Paffrather Straße/Dellbrücker Straße und Paffrather Straße/Flachsberg auch beampelte Fußgängerübergänge sind und dann darüber routen?

Es mag vielleicht die Regel sein - aber es gibt eben auch Ausnahmen, wo dann genau kein Fußgängerübergang dort ist.
Wenn der Router schon rät, dann doch bitte höchstens genauso unsicher - also nur einen einfachen ungesicherten Übergang und nicht einen gesicherten!

Den Vorschlag von TZorn gab es ja auch schon bei weniger befahrenen Straßen. Natürlich ist das nicht sicher, dass es dort einen Übergang gibt, aber ein verdammt guter Tipp, wenn es sonst im Umkreis von einem Kilometer nichts anderes gibt. Dazu entspricht es ja auch den Gewohnheiten von Mappern, eher dann mehr Informationen zu geben, wenn die bisherigen zu falschen Schlüssen führen können. Aber keine Frage, natürlich sollten hier die Daten vervollständigt werden, damit klar wird, wo man überkreuzen kann. Dann wird der Router diese Stellen auch benutzen und auch viel schneller Routen finden, weil nicht mehr so ein großer Umkreis nach anderen Alternativen durchsucht werden muss. Und wir erwägen auch die Information weiterzugeben, wie sicher diese Route erscheint- und in diesem Fall wird die Bewertung weit von der tatsächlichen Distanz abweichen, da hier (von der Datenlage) so unsicher überkreuzt werden muss.

Andreas Binder wrote:

Von daher muss für ein sicheres Routing schon ein eindeutiger Knoten mit highway=crossing+crossing=traffic_signals an die Nußbaumer und/oder Paffrather Straße.

Danke Andreas und geri-oc, Ihr habt natürlich völlig Recht: Sicher ist der Weg in diesem Beispiel wegen der schlechten Datenlage überhaupt nicht. Und natürlich sollten diese Situationen besser gemapped werden, nur ist es einerseits Arbeit und zum anderen sah man bisher den Nutzen nicht. Genau daher haben wir das Routing ja schon jetzt öffentlich, damit sich jeder ein Bild davon machen kann, und ein paar fangen ja auch an, deswegen schon Dinge nachzutragen. Um so mehr ärgert es mich, dass jetzt der tägliche Update nicht läuft. Aber das wird in Ordnung gebracht, und dann kann man direkt sehen, wie ein paar Ergänzungen an besonders kritischen Fällen gleich sehr viel helfen.

Auf der anderen Seite wird es immer Stellen geben, wo die Datenlage nicht gut ist. Hier sollte der Router das Ergebnis liefern, was eine erfahrene Person aufgrund der zumindest vorhandenen Datenlage empfehlen würde. Das ist natürlich ungenau, aber zumindest können wir einen Hinweis geben, welcher Weg wahrscheinlich sinnvoll ist, aber die Unsicherheit können wir ja auch gut bewerten. Und genau diese Warnung wollen wir auch auf eine sinnvolle Art weitergeben, dass man hier besonders vorsichtig sein sollte.

TZorn wrote:

OK. Aber woher kommt der Seitenwechsel auf der Nußbaumer Straße? Auf beiden Straßenseiten ist ein hw=service zu queren, ich sehe keine Unterschiede und nichts, was zwei Straßenquerungen rechtfertigen würde.

Ich weiß jetzt nicht, welche zwei Seitenwechsel du meinst, aber da gibt es einen vielleicht etwas überraschenden Seitenwechsel zwischen zwei Zufahrtsstraßen hw=service auf der Nußbaumer Straße:
Die Nußbaumer hat maxspeed=10. Eine Überquerung dieser ist sehr unproblematisch, der Algorithmus weicht hier so den Zufahrten aus und verkürzt dabei die Wegstrecke. Die Überkreuzung von Wegen mit explizitem maxspeed=10 wird als weniger gefährlich beurteilt als Überkreuzung von hw=service ohne weitere Information.

sritterbusch wrote:

Die Überkreuzung von Wegen mit explizitem maxspeed=10 wird als weniger gefährlich beurteilt als Überkreuzung von hw=service ohne weitere Information.

Sicher sehr richtig. Normalerweise haben diese service auch maxspeed=10 - ist 10 überhaupt richtig?

Allgemein kann aber eine service-Überquerung günstiger als eine residential bewertet werden. Würde ich bei "Querungen" als Merkmal nutzen. Auch eine Querung auf residential sollte besser als secondary bewertet werden.

geri-oc wrote:

Allgemein kann aber eine service-Überquerung günstiger als eine residential bewertet werden. Würde ich bei "Querungen" als Merkmal nutzen. Auch eine Querung auf residential sollte besser als secondary bewertet werden.

Naja, wenn ich mich nicht irre, haben nicht auch Tankstellen und Parkplätze oft hw=service? (Interessanterweise verlangen Betroffene, dass Einfahrten eher nicht angesagt werden brauchen, Tankstellen und Parkplätze aber auf jeden Fall. Das kann man natürlich erst mit erweiterter Analyse aus den Kartendaten herausbekommen, die wir aktuell noch nicht machen.)

Tatsächlich habe ich aber die Wertung für die Überkreuzung von service-Wegen schon mehrfach gesenkt, und tatsächlich sind die Zufahrten für Menschen mit Blindheit nicht so leicht: Die mit Langstock ertastbaren Leitkanten fallen weg, und man muss hoffen gesehen zu werden. Das ist aber hier eine reine Abwägungsfrage- ob etwas mehr oder weniger würde den Weg ändern, aber ich glaube das macht wirklich nicht viel aus, wie man genau läuft. Wichtiger wäre es zu wissen, wo die Fußgängerampel an der Hauptstraße sitzt.

Ich meine diese beiden Überquerungen (1+2):

Die einfachste Route wäre meiner Meinung nach bei 1 auf der rechten Seite der Nußbaumer Straße zu bleiben, dann den rechten rot umkringelten Service-Weg zu queren (der immerhin mit surface=Asphalt und smoothness=excellent angegeben ist) und einfach bis Stelle 2 auf der rechten Seite weiterzulaufen.

Stattdessen schlägt der Router vor bei 1 die Straßenseite zu wechseln, dann beim linken roten Kringel einen nicht weiter beschriebenen Service-Weg zu queren und dann bei 2 wieder zurück auf die ursprüngliche Seite zu wechseln.

Scheinbar bekommst du aber ein anderes Ergebnis, da du von einem Wechsel zwischen den beiden roteingekringelten Service-Wegen sprichst.

Ein Problem beim Fußgängerrouting könnte auch sein, dass an vielen Straßen keine Angabe zum sidewalk gemacht wurde. Beim Nachtragen bin ich nun unsicher, wie dies bei Geh- und Radwegen geschehen soll, die direkt neben der Fahrbahn optisch getrennt sind.
Das Wiki auf der Seite:
https://wiki.openstreetmap.org/wiki/DE: … _kartieren
sagt:
„Getrennter Fuß- und benutzungspflichtiger Radweg
Fußgänger und Radfahrer sind optisch voneinander getrennt (Linie, farbiges Pflaster, usw.).
Der Geh- und Radweg ist baulich nicht durch einen Grünstreifen, Graben, Büsche, usw. von der Fahrbahn abgesetzt. Der Fußweg wird durch weitere Tags am highway beschrieben.
highway=* [4]
cycleway:right=track
cycleway:right:bicycle=designated
cycleway:right:segregated=yes
cycleway:right:oneway=* [5]
cycleway:right:traffic_sign=DE:241“
Eine Angabe zum sidewalk (z.B. sidewalk=right/left/both) ist hier nicht aufgeführt. Soll diese Angabe trotzdem ergänzt werden (dann sollte man auch das Wiki ändern) oder soll der Router aus dem „segregated“ schließen, dass es auch einen Gehweg gibt (bzw. bei „segregated=no“ Fußgängerverkehr erlaubt/geboten ist)?

ghostrider44 wrote:

Das Wiki auf der Seite:
https://wiki.openstreetmap.org/wiki/DE: … _kartieren sagt:

Diese Seite ist für's Rad-Tagging gedacht....

Klar macht es Sinn sidewalk=* zu erfassen. Gerade bei (innerstädtischen) Hauptstraßen ist es für's Fußrouting sehr wichtig zu wissen ob's nen Bürgersteig gibt.

TZorn wrote:

Ich meine diese beiden Überquerungen (...) Scheinbar bekommst du aber ein anderes Ergebnis, da du von einem Wechsel zwischen den beiden roteingekringelten Service-Wegen sprichst.

Ja, das war es: Tausche mal Start und Ende aus und schon kommt die Route, die wir eigentlich erwarten. Das ist ein Edge-Case, den wir auf längeren Strecken schon mal gesehen hatten, und jetzt hast du uns ein ausgezeichnet kleines Beispiel gefunden, wo Hin- und Rückweg unterschiedliche Wege ergeben, was aktuell noch nicht so sein darf. Damit werden wir den Grund endlich finden können, danke!

Leider ist die Seite im Moment nicht zu erreichen. Hoffentlich nur ein temporäres Problem?

Discostu36 wrote:

Leider ist die Seite im Moment nicht zu erreichen. Hoffentlich nur ein temporäres Problem?

Davon gehe ich aus.

Der Service ist wieder online.

sritterbusch wrote:

Der Service ist wieder online.

Aber das tägl. Update läuft noch nicht ?

Grüße

PT-53 wrote:

Aber das tägl. Update läuft noch nicht ?

Ne, leider nicht. Mitte nächste Woche weiß ich mehr, und dann sollte auch das wieder gehen.

Hei...

man sollte ja Routing auch immer in Bereichen testen, die man täglich benutzt...

Frage...

Welche Gründe hat es, daß in Potsdam bei GraphHopper eine kürzere und logischere Route gewählt wird? Diese ist aus eigener Erfahrung die zu favorisierende Route (auch wenn diese wegen der fußgängerhassenden Busfahrer und allseits "beliebten" Kampf-Radfahrer immernoch eine gefährliche Route ist).

Anmerkung: ich benutze zwar täglich diese Route, spreche aber aus mehrjähriger Erfahrung und Potsdam gehört aber nicht zu meinem normalen Mapping-Bereich.

Sven

[Erdit] es fehlt ein Direktlink zur gewählten Route [/Edit]

streckenkundler wrote:

Welche Gründe hat es, daß in Potsdam bei GraphHopper eine kürzere und logischere Route gewählt wird? Diese ist aus eigener Erfahrung die zu favorisierende Route (auch wenn diese wegen der fußgängerhassenden Busfahrer und allseits "beliebten" Kampf-Radfahrer immernoch eine gefährliche Route ist).

Ich kenne die lokalen Verhältnisse nicht, aber der Algorithmus natürlich auch nicht- er kann nicht besser als bestenfalls ein Experte auf Basis der Kartendaten entscheiden.

Der Grashopper schlägt vor, dass man quer über den Busbahnhof geht, das sind fünf Straßenüberquerungen ohne Hilfsmittel (für Blinde schwierig) und dann scheint auch die Friedrich-Engels-Straße am ersten Teil für Fußgänger laut Karte schlechter ausgebaut zu sein (da die Karte eher Auto-orientiert ist mag da aber mehr in den Daten sein). Danach stimmt die Strecke überein, abgesehen davon, dass Grasshopper auf statt auf der Seite der Heinrich-Mann-Allee geht.

Das Fußgängerrouting übergeht den Busbahnhof komplett und überkreuzt die Friedrich-Engels-Straße an besser ausgebauter Stelle, dann über die Insel hinüber zur gemeinsamen zweiten Überquerung, und verwendet später dann die Heinrich-Mann-Allee lieber den Bürgersteig.

Es sind aber ganz sicher die fünf Überquerungen am Anfang, die ihn einen anderen Weg nehmen lassen. Für die aktuelle Zielgruppe von Menschen mit Blindheit erscheint das vom Stand der Karte ein guter Vorschlag. Für ein Profil typischer sehender Fußgänger kann man diskutieren, ob man sie lieber quer über den Busbahnhof gehen lässt, oder die 60m Umweg bei hier 600m gesamt über den Fußweg drum herum vorschlägt.

Ja gut... Fairerweise muß man sagen, daß dieser ganze Verkehrsknoten schon für Ottonormalbenutzer eine absolute Katastrophe ist. Der Busbahnhof ist völlig an den Bedürfnissen der Fußgänger vorbei geplant worden und mittlerweile an der Kapazitätsgrenze... Ich sehe täglich einige sehbehinderte Menschen, die tun mir jedes mal Leid... Das nur am Rande...

Deine Aussage ist soweit durchaus nachvollziehbar (z.B. fünf Querungen)... was ich aber nicht verstehe, warum auf der Friedrich-Engels-Straße zwischen beiden Fahrspuren von der einen zur anderen Ampel geroutet wird und nicht erst mal gerade rüber über beide Fahrspuren und dann erst nach Westen... Mir geht es nur um die Querung der Friedrich-Engels-Straße... dahinter passt alles...

Sven

streckenkundler wrote:

was ich aber nicht verstehe, warum auf der Friedrich-Engels-Straße zwischen beiden Fahrspuren von der einen zur anderen Ampel geroutet wird und nicht erst mal gerade rüber über beide Fahrspuren und dann erst nach Westen...

Wie ich es schon vermutet hatte, fehlen da Angaben in der OSM zur Kreuzung: Nur die beiden vom Fußgänger-Routing verwendeten Übergänge Nord und Süd der Friedrich-Engels-Straße haben die Angabe, dass es dort eine echte Überquerungsmöglichkeit (crossing) mit Ampel gibt. Der Weg in der Mitte zur anderen Ampel erscheint (laut Karte!) nicht so problematisch, da dort nur eine Zufahrt (service) zu überschreiten ist.

Ich habe mir das jetzt mal im Satellitenbild angesehen, und ja, da sieht man, dass genau nur dort Crossings eingetragen sind, wo Ampeln für Autos hängen- egal, was da sonst noch leuchtet, überkreuzt oder hängt. Dementsprechend ist man da als Fußgänger ziemlich verloren.

Natürlich gibt das Routing einen Bonus, wenn man auf einem dedizierten Fußweg die Straße kreuzt, aber ohne jegliche Angabe zur Kreuzung, wenn es gleich darauf Angaben gibt, erscheint das im Vergleich deutlich schwieriger.

Ach in Potzeldamm ist noch mehr im Argen...

Blick südlich der F-E-Straße nach Osten... Überweg Straßenbahn mit Rad/Fußweg... mit Ampel(!!)... Rad- und Fußweg separat erfasst,
obwohl Zeichen 241... (genauer Fotopunkt: https://www.openstreetmap.org/?mlat=52. … 5&layers=N )

Frage allgemein in die Runde... Wie ist das denn nun bei Kreuzungspunkten von highway (allgemein) mit Straßenbahn... Ist da stets railway=crossing|level_crossing nötig? Ich hab schon in anderen Städten geschaut, es war aber immer uneinheitlich....

Hier magels Erfahrung und vor allem mangels Straßenbahn in Lübben und im Spreewald weiß ich das wirklich nicht... Ich würde ja hier generell bei allen Kreuzungspunken, die nicht bei eins auf den Bäumen sind, diese railway=crossing|level_crossing-Tags setzen... (zuzüglich weiterer nötiger Tags...)

Sven

Hier ein Beispiel, wo die Route einigermaßen stimmig ist, die Linienführung und die Routenbeschreibung sich aber wohl von den beginnenden zwei Fahrbahnen irritieren lässt.

https://www.openstreetmap.org/#map=19/51.03624/7.04870

TZorn wrote:

Hier ein Beispiel, wo die Route einigermaßen stimmig ist, die Linienführung und die Routenbeschreibung sich aber wohl von den beginnenden zwei Fahrbahnen irritieren lässt.

Ich glaube die Irritation kommt daher, dass die östliche Oulustraße ein eigentlich überflüssiges foot=yes hat, und daher in Darstellung und sprachlicher Beschreibung unpassend interpretiert wird. Der Bug wird wohl die kommende Woche behoben. Interessanterweise hat die westliche Oulustraße den Tag nicht.

Gute Nachrichten: Mein Kollege hat die Behandlung von foot=yes auch im geometrischen Teil angepasst, jetzt kommen in den Fällen von maxbe in Aschheim und in Schlebusch von TZorn auch visuell sinnvollere Ergebnisse heraus. Und u.a. an PT-53: Der Update läuft wieder, in etwa 10h sollte der Server up-to-date sein. Am 21.8. hatte es einen kleinen Netzwerkschluckauf gegeben, darauf hat der Updater bis zur manuellen Überprüfung der Situation pausiert.

Eine kleine Anmerkung noch von mir an ghostrider44: Natürlich ist es sinnvoll und extrem hilfreich, wenn möglichst viele Sidewalks als Tag korrekt eingetragen sind. Wenn es innenliegende separate Pfade einer Straße gibt (zB Straßenbahn oder Radweg können dieses Linienbündelproblem der OSM auslösen) oder der Weg vom Straßenrand abweicht, sollte der Fußweg aber extern geführt werden. Gibt es aber keine Angaben, so ist es weiterhin absolut sinnvoll Fußgänger an dem Rand der Straße gehen zu lassen (also ... Nicht mitten auf der Straße)- egal, ob es nun wirklich einen Bürgersteig gibt oder nicht. Die Bewertung und damit die Präferenz dieser Wege ist aber natürlich eine vollkommen andere Geschichte. Hier unterscheiden wir uns ebenfalls von den früheren Ansätzen.

@sritterbusch:
Wie steht Ihr zum Thema Höhengleiche straßenbegleitende Gehwege wie taggen ?
Ist aus Eurer Sicht Bedarf für entspr. Tagging vorhanden und welche Lösung würdet Ihr vorschlagen ?

Grüße aus Oberschwaben

PT-53 wrote:

@sritterbusch: Wie steht Ihr zum Thema Höhengleiche straßenbegleitende Gehwege wie taggen ?

Zunächst ist es großartig, dass mit dem Routing die Fragen zum Tagging bzw. Mapping von Bürgersteigen und Gehwegen offensichtlicher werden, und es auch dazu motiviert das Mapping von Sidewalks zu verbessern. Mehr kann ich mir und für das Projekt und die Nutzergruppe echt nicht wünschen.

Mit Vorschlägen zum Tagging von besonderen Situationen von meiner Seite wird es aber schwer: Selbst wenn es damit möglich wird, eine spezielle Situation abzubilden, so bleibt ein spezielles Tagging für ein globales Routing i.A. irrelevant, solange es nicht von einer breiten Masse aufgenommen wird. Jetzt kann man natürlich die vielen Projekte auf beiden Seiten des Atlantiks heranziehen, wo mit viel Aufwand (personell und finanziell) neue Schemata in begrenzten Innenstadtbereichen umgesetzt werden. Schaut man auf die AccessMap so braucht man nur etwas heraus zu zoomen, um zu sehen, in welchen Stadtteilen man besser nicht blind oder mit Rollstuhl unterwegs sein sollte. Und selbst bei diesem Aufwand müssen wir uns beim Router fragen, wann wir uns für die im Verhältnis geringe Nutzung mit Sonderregeln dafür beschäftigen.

Aus Sicht des Routings ist es also immer besser, je mehr sich die OSM auf Standards einigt. Bei den speziellen Fragen für besondere Personengruppen muss man eigentlich mit den Personen selbst und/oder Mobilitätsexperten zum Thema sprechen. Und da kommen dann oft im Gegenteil Anforderungen zu sehr speziellen Annotationen heraus. Und die dritte Gruppe der eigentlichen Mapper hat dann auch noch eine eigene Meinung dazu.

Ich hoffe ich kann dir aber mit der Situation für die ersten beiden Sichtweisen helfen.

Hi,
in dieser Gegend führt Separat-Mapping zu fürchterlichem Fußgänger-Routing.
Vielleicht hat jemand Lust zu reparieren.

https://www.openstreetmap.org/direction … 9/12.10596

chris66 wrote:

Hi,
in dieser Gegend führt Separat-Mapping zu fürchterlichem Fußgänger-Routing.
...

Ja, die Stelle ist übel für Router (Kein Fehler vom Terrain-Projekt, sondern vom Mapper)

Andreas Binder wrote:

chris66 wrote:

Hi,
in dieser Gegend führt Separat-Mapping zu fürchterlichem Fußgänger-Routing.
...

Ja, die Stelle ist übel für Router (Kein Fehler vom Terrain-Projekt, sondern vom Mapper)
http://up.picr.de/33773755zu.jpg

Naja, wenn Fehler kommen, ärgert mich das schon. Nun gut, es gibt halt keine Verbindung.

Aber wenn man näher zur Straße klickt, so ignoriert der Router sogar das völlig unverbundene "Fußwegenetz" und liefert das richtige Ergebnis auf Basis der angenommenen Bürgersteige.

Heute bind ich einem Fußgängerstreifen begegnet. War aufgemalt wie ein Fahrradstreifen, aber eben mit Fußgänger-Symbol. Hab ich mit sidewalk=no und footway:right=lane getaggt, aber ich befürchte, dass das wohl kaum richtig ausgewertet werden wird (mal davon abgesehen, dass das mangels Bordstein wohl für Blinde sowieso nicht so toll sein dürfte).

Hallo!

Ich bin der Kollege von sritterbusch und für die Programmierung und den Betrieb des Servers zuständig. Vor ein paar Jahren war ich aktiverer Mapper und die anfängliche Version von "Form rechtwinklig machen" in JOSM stammte von mir.

Zum aktuell diskutierten Fall:

Die Ausgabe "Routingfehler" ist natürlich nicht gut. Der Router merkt schon, dass er keine Route finden kann. Ich muss da mal an der Ergebnisausgabe etwas drehen.

Das Mapping der hier besprochenen Gegend verbindet nur Fußwege über Straßen wo offizielle Übergänge vorhanden sind, hat aber keine gemeinsamen Punkte mit den Straßen. Das führt a) zu topologisch unverbundenen Graphen, weshalb dann der Router keinen Weg findet und b) kann man über Straßen geleitet werden, ohne dass dies vom Router bemerkt und in der Route angesagt wird.
Hier gibt es also einiges im Mapping zu verbessern, damit hier vernünftige Routen gefunden werden können

Straßenüberquerung ohne Straßenüberquerung...

Wenn ich den Startpunkt auf die Straße und nicht auf den Gehweg setze, bekommen wir die gleiche Route wie GraphHopper. Vermutlich versucht GraphHopper, wenn der nächstgelegen Startpunkt (auf Gehweg) zu keiner Route führt, den zweitnächsten Startpunkt (auf Straße). Das funktioniert auch nur, weil bei der Schule ein kombinierter Geh-/Radweg ist, der, weil Radweg, auch mit der Straße verbunden wurde. Auch werden dann kaum die explizit gemappten Gehwege verwendet, sondern die selbst generierten, da die Straßen auch kein Attribut haben, dass die Gehwege separat gemappt wurden.

So, ich habe gestern wo sich Wege/Schienen überkreuzen gemeinsame Knoten eingefügt.

https://www.openstreetmap.org/changeset/62531721

Jetzt sehen die Routen/Erläuterungen schon besser aus:

Entlang der Neundorfer Straße wird ein angenommener Gehweg verwendet, da die Straße kein sidewalk=none oder sidewalk=right oder sidewalk=separate Tagging hat, welches dies verhindern würde.

Hier bemerkt jetzt der Benutzer, dass er Straßen und Schienenwege überqueren muss. Eine kleine semantische Verwirrung könnte die Anweisung "Rosa-Luxemburg-Platz überqueren" auslösen, wo kein Platz überquert werden muss, sondern eine Straße mit diesem Namen. Falls notwendig läßt sich da mit der Textgenerierung aus den Routendaten sicher etwas machen.

hkucharek wrote:

Entlang der Neundorfer Straße wird ein angenommener Gehweg verwendet, da die Straße kein sidewalk=none oder sidewalk=right oder sidewalk=separate Tagging hat, welches dies verhindern würde.

Eher, weil die separaten Fußwege unter anderem an der Scharnhorststraße keine Verbindung haben. Sonst würde er nicht erst am Ziel vorbei und dann wieder 18 m zurück lotsen.

Ich finde, der Router hat noch ein bisschen zu viel Angst davor, Straßen zu überqueren. Einen kleinen Umweg würde ich in Kauf nehmen, um hier nicht über die E.-Schenk-Str. laufen zu müssen. Aber diese Alternative fände ich zu weit:

(Wenn ich Start- und Ziel weiter zusammenrücke nimmt er die direkte Verbindung, so grundsätzlich findet er den Weg also)

Vielleicht liegt es daran, dass an dieser Stelle kein Crossing eingetragen ist und der Routingplaner deshalb nicht weiß, ob und wie sicher man hier die Straße überqueren kann.

Discostu36 wrote:

Vielleicht liegt es daran, dass an dieser Stelle kein Crossing eingetragen ist und der Routingplaner deshalb nicht weiß, ob und wie sicher man hier die Straße überqueren kann.

Jo, darum gehts mir. Der default-Wert für "Weg kreuzt highway=residential mit maxspeed=30" scheint mir zu hoch.

Dass man die Straße irgendwie überqueren kann, erkennt man am gemeinsamen Knoten. Wie genau das geht, weiss man nicht, aber das dürfte der übliche Fall sein. Mehr als ein crossing=uncontrolled könnte man nicht mappen und das sagt dann auch nicht viel mehr aus (und evtl kerb=*, aber das wird hier ja nicht verwendet).

Vielleicht auch einfach den cycleway als path? Wer läuft schon als Fußgänger auf einem Fahrradweg? Wie ist den die Ausschilderung?

geri-oc wrote:

Vielleicht auch einfach den cycleway als path? Wer läuft schon als Fußgänger auf einem Fahrradweg? Wie ist den die Ausschilderung?

Google Stret View ist noch aktuell (westlich gemeinsamer Rad- und Fußweg, östlich getrennte Wege. Räder in beide Richtungen. Der Weg wird auch fleissig von allen in alle Richtungen genutzt).

Aber die Wirklichkeit kennt der Router ja nicht, der muss (bicycle=designated, foot=yes, highway=path) und (bicycle=designated, cycleway=sidepath, foot=yes, footway=sidewalk, highway=cycleway) interpretieren.

Woran es auch liegen könnte: Da haben wir ein barrier=cycle_barrier ohne access=* im Weg liegen. Der verhindert nicht grundsätzlich das Routen, könnte den Weg aber unattraktiv machen, falls der Router den berücksichtigt.

Grüße
Max

Wie mappt man denn einen "unsichtbaren" Fußweg?

https://www.openstreetmap.org/note/1539 … 3&layers=N

😛

chris66 wrote:

Wie mappt man denn einen "unsichtbaren" Fußweg?

Das alte Querungsproblem. Ich hab mal was druntergeschrieben.

--ks

chris66 wrote:

Wie mappt man denn einen "unsichtbaren" Fußweg?

Das ist aus meiner Sicht überhaupt keine blöde Frage, sondern eine der unangenehmen Auswirkungen separater Fußwege: Es ist nicht klar, dass die seitlichen Wege zur Straße gehören, und (sehende Fußgänger oder Läufer) ohne bauliche Separation die Straße hier kreuzen könnten.

Ich plädiere dafür, dass man hier "virtuelle" Zusatzwege für die explizite Überquerung hinzufügt, auch wenn es keine "extra" Kennzeichnungen auf der Straße gibt. Aktuell scheint die OSM-Kartierung bauliche Trennungen (z.B. Graben oder Büsche) nahe zu legen, was es de-facto nicht stimmt und von vielen Läufern und Wanderern anders gehandhabt wird. Grundsätzlich erfordern separate Fußwege immer eine Menge zusätzlicher Verbindungswege wie hier diese.

Das würde allen Routern helfen, die Situation sinnvoller zu darzustellen, nicht nur bei unserem Verfahren- und ich glaube ich die Kartendarstellung würde auch der tatsächlichen Situation eher entsprechen.

sritterbusch wrote:

Ich plädiere dafür, dass man hier "virtuelle" Zusatzwege für die explizite Überquerung hinzufügt, auch wenn es keine "extra" Kennzeichnungen auf der Straße gibt.

Siehe meine Anmerkung in der Note. Ich habe die Einmündungen bis zur Straße gezogen, für das Anlegen einer kompletten Querung fehlt mir die bauliche Besonderheit gerade an der nämlichen Stelle, die so etwas rechtfertigen würde. Nachteil: Routing erfolgt jetzt natürlich ausdrücklich über die Straße.

Generell wäre es natürlich viel einfacher, die straßenbegleitenden Wege wären getaggt statt gemappt.

--ks

kreuzschnabel wrote:

Siehe meine Anmerkung in der Note. Ich habe die Einmündungen bis zur Straße gezogen, für das Anlegen einer kompletten Querung fehlt mir die bauliche Besonderheit gerade an der nämlichen Stelle, die so etwas rechtfertigen würde. Nachteil: Routing erfolgt jetzt natürlich ausdrücklich über die Straße.

Wir sind da (Note) einer Meinung: Wege separat zu führen, bedeutet, dass man deutlich mehr Aufwand betreiben muss. Die Frage, wo man Straßen abseits von Knoten überqueren kann, ist ein Thema für sich. Speziell für das Routing für Blinde ist es besser, dass wir uns an explizit definierte Überquerungen halten, aber allgemein gibt es verschiedene Ansätze: Bezogen auf Distanz regelmäßige Querungen vorsehen, optimierte Querungen ansetzen oder es halt ganz außerhalb von Knoten zu lassen.

Die Variante direkt senkrecht auf die Straße zu verbinden, ist für unsere Router absolut in Ordnung. Mal sehen, eventuell wird unser Router aktuell die Umwege um echte Überkreuzungen für Blinde morgen vorziehen, aber bei anderem Profil würde er direkt überqueren können.

Die Änderung von kreuzschnabel war wohl zu spät für das D-A-CH .osc-File der Geofabrik und ist in dem von letzter Nacht nicht enthalten. Morgen kann dann ausprobiert werden 🙂

Hallo Sritterbusch. Habe hier noch was merkwürdiges gefunden. hw=service muss ja mit sagenhaften Kosten verbunden sein, dass für dessen Vermeidung sogar eine Überquerung und einen Riesenumweg in Kauf genommen wird (Stelle):

Das Problem aus #68 besteht auch noch (nur als Anmerkung, falls ihr es zwischenzeitlich übersehen habt).

hkucharek wrote:

Die Änderung von kreuzschnabel war wohl zu spät für das D-A-CH .osc-File der Geofabrik und ist in dem von letzter Nacht nicht enthalten. Morgen kann dann ausprobiert werden 🙂

Die Änderung von kreuzschnabel ist jetzt mit drin, aber die Querungsmöglichkeit wird vom Router natürlich so gedisst, dass immer noch brav über den Übergang mit Insel bei der Bushaltestelle geroutet wird.

TZorn wrote:

Das Problem aus #68 besteht auch noch (nur als Anmerkung, falls ihr es zwischenzeitlich übersehen habt).

Das ist momentan mein Testgelände. Ein Problem schon gefunden und gelöst, es gibt aber noch mindestens ein weiteres. Erst danach werde ich den Router der Testseite auf den neuesten Stand bringen.

PS: Der Friedhof schien ein Opfer des ersten Problems gewesen zu sein... 🙂

hkucharek wrote:

die Querungsmöglichkeit wird vom Router natürlich so gedisst, dass immer noch brav über den Übergang mit Insel bei der Bushaltestelle geroutet wird.

Das würde sich dann vermutlich auch nach Einbau einer (kaum begründbaren, weil da baulich ja nichts anderes ist als zehn Meter links oder rechts davon) vollständigen Querung bis zum gegenüberliegenden Fußweg nicht ändern, da es ein Router-Gewichtungsproblem ist. Und für erwünschtes Routing da einen Fußgängerüberweg reinpinseln wäre wirklich Mappen für den Router 🙂

--ks

sritterbusch wrote:

Ich plädiere dafür, dass man hier "virtuelle" Zusatzwege für die explizite Überquerung hinzufügt, auch wenn es keine "extra" Kennzeichnungen auf der Straße gibt. Aktuell scheint die OSM-Kartierung bauliche Trennungen (z.B. Graben oder Büsche) nahe zu legen, was es de-facto nicht stimmt und von vielen Läufern und Wanderern anders gehandhabt wird. Grundsätzlich erfordern separate Fußwege immer eine Menge zusätzlicher Verbindungswege wie hier diese.
Das würde allen Routern helfen, die Situation sinnvoller zu darzustellen, nicht nur bei unserem Verfahren- und ich glaube ich die Kartendarstellung würde auch der tatsächlichen Situation eher entsprechen.

Ich finde "virtuelle" Wege für Router falsch - auch in der Kartendarstellung. Wir tragen Daten ein die vorhanden sind.

- wenn man detailliert mappt, gibt es Zufahrten die für Querungen genutzt werden können (Bordstein abgesenkt) etwas weiter westlich
- der Weg zum Pier des Segelclub sieht auch wie Zufahrt aus und ist bis zur Straße richtig.
- der jetzt virtuelle Weg von kreuzschnabel kann eingezeichnet werden, falls es da eine Bordsteinabsenkung gibt. Sonst sollte er entfallen, da sicheres Routing für Fuß und Rad über Absenkungen erfolgen sollten.

Die Überquerung der bauliche Trennung (Bordstein, Grünstreifen) kann von jedem genutzt werden, der sich nicht an die "sicheren" Anweisungen des Routers halten will. Er kann ja vor Ort entscheiden, ob er die Umwege nutzen möchte oder nicht.

Wenn ein Sportler über die Leitplanke springt oder ein Absperrgeländer als "Hürde" missbraucht - sollte das nicht in die Routenanweisungen, genau so wenig wie für ein "Rasenlatscher".

Einfach einmal vor Ort schauen, wo Bordsteinabsenkungen sind und diese nutzen - ergibt auch ein vernünftiges Routing. Der nördlich cycleway sollte auch als path eingetragen sein Es steht sicher kein Schild "Fahrradweg" und "Fußgänger erlaubt/frei"- und ab dem Segelclub westlich sollte er auch geteilt werden, da er dann getrennt von dem Radweg verläuft. Wenn oneway=yes an den path dann oneway:bicycle=yes.

Für ein sportliches Routing kann auch über eine "Umkreissuche" die nächsten Routenpunkte (in 20 oder 50 m abgesucht werden und dieser Punkt als nächstes gewählt werden mit Löschung der Zwischenpunkte. Ob das dann aber richtig ist, über eine vierspurige Straße zu routen?

geri-oc wrote:

Die Überquerung der bauliche Trennung (Bordstein, Grünstreifen) kann von jedem genutzt werden, der sich nicht an die "sicheren" Anweisungen des Routers halten will. Er kann ja vor Ort entscheiden, ob er die Umwege nutzen möchte oder nicht.

Von diesem konkreten Fall abgesehen halte ich das im Allgemeinen für unsinnig. Ich überquere täglich etliche Straßen an Stellen, an denen der Bordstein nicht abgesenkt ist. Bei vielen normalen Bürgersteigen gibt es in Nebenstraßen älteren Baujahres keine Absenkungen an den Kreuzungen, trotzdem ist das ja kein unsicherer Übergang.

OSM sollte die Welt so kartieren, wie sie ist. An Stellen, an denen Straßen häufig überquert werden (z.B. weil dort eben von gegenüberliegenden Seiten Fußwege enden), sollte deshalb auch ein highway=crossing mit crossing=unmarked eingetragen werden, unabhängig von Bordsteinen. Wenn man nur an sicheren Stellen die Straße überqueren will, dann muss der Router eben so eingestellt sein, dass er nur crossings mit bestimmten Werten benutzt.

Discostu36 wrote:

Ich überquere täglich etliche Straßen an Stellen, an denen der Bordstein nicht abgesenkt ist.

Dann sicher nicht im Rollstuhl oder mit Rollator.

Wenn du sie "kartierst" wie sie ist, geht dort m.E. kein Fußweg auf die Straße, sondern ein Grünstreifen entlang zwischen Straße und Fußweg.

geri-oc wrote:

Discostu36 wrote:

Ich überquere täglich etliche Straßen an Stellen, an denen der Bordstein nicht abgesenkt ist.

Dann sicher nicht im Rollstuhl oder mit Rollator.

Für die gibt es deshalb ja auch wheelchair=*, barrier=kerb und kerb=*. Als Beispiel: An dieser Stelle habe ich die Bordsteine gemappt, um deutlich zu machen, dass der Überweg für Rollstuhl- und Radfahrer nicht geeignet ist. So kann man als "normaler" Fußgänger trotzdem dort über die Straße geroutet werden, während die anderen (mit hoffentlich dementsprechend konfigurierten Navi) über die nahe gelegene Ampel geführt werden. Mit dem aktuellen Fall allerdings nicht ganz vergleichbar, weil es hier keine separat gemappten Bürgersteige gibt.

Wenn du sie "kartierst" wie sie ist, geht dort m.E. kein Fußweg auf die Straße, sondern ein Grünstreifen entlang zwischen Straße und Fußweg.

Wie gesagt, ich bezog mich nicht auf diese konkrete Situation, die ich mangels Ortskenntnis nicht beurteilen kann, sondern auf deine allgemein gehaltene Aussage.

Hallo. Gibt es was neues in dem Projekt? Hier ist es ruhig geworden und die Webseite hat auch lange kein Update mehr erfahren, wie es scheint. Wäre schade drum.

Hallo, oh ja, es ist sehr viel passiert, und genau deswegen war hier etwas wenig zu hören. Die Posts mit den Updates kommen in den folgenden Tagen.

So, die Zeit ist jetzt doch etwas schneller vergangen und vor lauter Arbeiten am Unterbau ist die Betreuung hier etwas zu kurz gekommen. Es gab Änderungen an der Weggenerierung und Wegbewertung. Bei letzterem eher kleinere, hier sind aber für die nächste Zeit größere Änderungen an den Bewertungen geplant. Wichtigste Änderung für Diskussionen hier ist, dass die Browser-URL jetzt komplett alle Parameter eines Routings beschreibt, d.h., man kann via copy & paste ein Routing hier eintragen.

Dortmund:

450 m Route für 10 Meter Luftlinie. 🙁

https://www.openstreetmap.org/direction … 39/7.44738

chris66 wrote:

450 m Route für 10 Meter Luftlinie.

Immer dasselbe Thema: Straßenbegleitende Fußwege als separate Ways zu mappen ist bescheuert. Mit sidewalk-Tagging wären das 10 m Route.

--ks

kreuzschnabel wrote:

chris66 wrote:

450 m Route für 10 Meter Luftlinie.

Immer dasselbe Thema: Straßenbegleitende Fußwege als separate Ways zu mappen ist bescheuert. Mit sidewalk-Tagging wären das 10 m Route.

--ks

Da bin ich ganz bei euch... 🙁 Das ist nur die Datenbasis mit unvollständiger und redundanter Geometrie zumüllen...

https://routago.de/pedestrian-routing/? … ,7.4475946

Das Schlimme ist, die Wege sind schon seit 5 Jahren dort drin, eingetragen von einem Mapper, der für ziemlich genau einen Tag solchen Mist produziert hat (immerhin 110 Changesets), und dann nie mehr gesehen wurde. Von mir aus weg damit.

Wenn die Datenbasis stimmt funktioniert auch ein (sicheres) Fußgängerrouting:
https://www.openstreetmap.org/direction … 9&layers=N

https://maps.openrouteservice.org/direc … n-US&k2=km

geri-oc wrote:

Wenn die Datenbasis stimmt

Wenn: https://www.openstreetmap.org/direction … 2C13.63643
Laut gängigen Luftbildern kann man da einfach über die Glück-Auf-Straße rüber.

--ks

Wenn ein Router für sportlich oder junge Leute die kürzere Verbindung nutzen möchte ist das sicher möglich. Da hatte auch schon jemand mal einen Vorschlag gemacht. Mit Rollstuhl und Rollator aber schwer. Der Weg verläuft auf anderen Koordinaten als die Straßenmitte.
Und man muss ja nicht die vorgeschlagen (sichere) Route nutzen.

kreuzschnabel wrote:

geri-oc wrote:

Wenn die Datenbasis stimmt

Wenn: https://www.openstreetmap.org/direction … 2C13.63643
Laut gängigen Luftbildern kann man da einfach über die Glück-Auf-Straße rüber.

--ks

Würde er vermutlich auch machen, wenn man den Fußweg einfach an die Straße als sidewalk=both getaggt hatte, statt einen eigenenständigen Weg zu erstellen...
So müsste man vermutlich den Fußweg einmal die Straße kreuzen lassen...

Deswegen mappe ich einen getrennten Fußweg nur, wenn dazwischen z.B. ein Grünstreifen ist...

JokerGermany wrote:

Würde er vermutlich auch machen, wenn man den Fußweg einfach an die Straße als sidewalk=both getaggt hatte, statt einen eigenenständigen Weg zu erstellen...

Wieso sollte er? Mit sidewalk-Tagging träfen sich ja beide Querwege auf dem Straßen-Way.

--ks

kreuzschnabel wrote:

JokerGermany wrote:

Würde er vermutlich auch machen, wenn man den Fußweg einfach an die Straße als sidewalk=both getaggt hatte, statt einen eigenenständigen Weg zu erstellen...

Wieso sollte er? Mit sidewalk-Tagging träfen sich ja beide Querwege auf dem Straßen-Way.

--ks

Isso
https://www.openstreetmap.org/direction … 1/10.60835

Hallo sritterbusch, liest du hier noch mit? Auf der Tagging-Mailingliste findet zur Zeit eine Diskussion statt, ob Gehwege ohne Bordstein als sidewalk getaggt werden sollten, als lane oder wie auch immer. Ein Argument gegen das Taggen als sidewalk ist, dass Blinde damit Schwierigkeiten hätten. Vielleicht kannst du ja deine Erfahrung als Fußgängerrouting-Experte dort mal einfließen lassen.

Ich dachte schon dies Projekt sei tot. Jetzt bin ich aber grad zufällig drauf gestoßen, dass da hinter den Kulissen scheinbar mächtig weitergewerkelt wurde (zumindest am Unternehmen und Marketing). Sogar eine Crowdfundinginitiative läuft gerade, noch 13 Tage Laufzeit.

Vielleicht mag ja einer der Beteiligten hier mal ein Update geben? Schade das dieser Kommunikationskanal nach den ganzen Tipps, die von hier gekommen sind, so vernachlässigt wurde.