Goldstandard Fußweg/Radweg an Straße

Bin der gleichen Meinung. Die Datenmenge bleibt so geringer und das direkte Routing zum Ziel entspricht eher den Gegebenheiten (keine Umwege über Verbindungsstellen, die eigentlich gar nicht vorhanden sind bzw. überall vorhanden sein müssten). Navigationsanweisungen wie “links abbiegen auf Fußweg” sind ebenfalls irritierend, wenn keiner abseits der Straße verläuft. Wer als Fußgänger oder Radfahrer eine Straße entlang geroutet wird, nimmt automatisch den Bürgersteig bzw. die Fahrradspur, das braucht auf keiner Karte eingezeichnet zu sein. Die Information als Zusatztag an der Straße genügt, um diese als für Fußgänger- oder Fahrradrouting sicher einzustufen bzw. für’s Visuelle auszuwerten. Nicht so günstig sind allerdings die Stellen, an denen der separate Weg wieder an die Straße als normaler Bürgersteig herangeführt wird - diese Anbindung erscheint unlogisch und unnötige Routinganweisungen bleiben ebenfalls nicht aus (lassen sich aber leicht ignorieren, da der weitere Verlauf auf dem Screen klar sichbar ist (quasi eine Gabelung auf die man zufährt, kein Haken von wenigen Metern mit zwei Ansagen wie “rechts Abbiegen in 300m, dann links abbiegen”.

Wenn das klar definiert wäre, ließe sich Fahrradrouting mittels “bicycle=use_sidepath” wirklich gut realisieren. Aber das ist ein anderes Thema.

Hast du einmal den Mapper gefragt, warum er separate footways nutzt? Ich finde löschen sollte immer die letzte Möglichkeit bleiben. Die Arbeit andere zu entfernen, nur weil sie nicht den eigenen Vorstellungen entsprechen …

Vielleicht nutzt jemand diese gelöschten Fußwege für eine “Stadtführung” oder für “Sicherer Schulweg” …

Dann nutze bitte, wie immer gesagt wird, die englische Seite im Wiki, auf der deutschen sind Details gar nicht aufgeführt. Auch Beispiele sind auf der dieser Seite für das getrennte Eintragen von “Fußwegen”

PS: Den Titel "Goldstandard … " - es gibt keinen.

Darauf können wir uns einigen. :wink:

Ich muss mich auch wundern, dass das Löschen korrekter Daten, die nicht ins eigene Schema passen, vorgenommen wird. Ich habe keine Bedenken, falsche Daten zu löschen oder korrekte Daten weiter zu präzisieren. Ich kann aus eigener Erfahrung sagen, dass in fast jedem von mir angefassten Gebiet ein simples sidewalk=both zu wenig Informationen beinhalten würde. Gehwege sind in kleineren Städten selten durchgehend nur mit Bordstein abgetrennt, sondern haben immer wieder Grünstreifen dazwischen. Radwege gehen direkt vom Bürgersteig ab und sind gar nicht mehr mit der Straße verbunden, Zufahrtstraßen enden an Bürgersteigen, etc. Ich halte es nur für konsequent, wenn es immer mehr in Richtung separater Gehwege geht. Wer damit nicht glücklich ist, sollte lieber alle Seiten anhören und Lösungen finden, statt das dagegen anzukämpfen.
Ich behaupte ja nicht, dass separat erfasste Bürgersteige jetzt 100% aller Probleme von sidewalk=* lösen - mitnichten. Beide Ansätze haben vor und Nachteile und die ultimative Lösung ist noch nicht gefunden worden. So lange das so ist, sollte man beide Ansätze tolerieren. Meine Meinung :slight_smile:

Ich denke, es ist einfach ein Trend, dass viele Couchmapper Fußgängerwege von Bing abmalen. Sie machen es, weil man es eben sehen kann auf Bing.

Eventuell hat es später mal einen Nutzen, wenn smoothness, Wegbreite etc. später mal von Vor-Ort-Mappern hinzugefügt werden.

Viele Navis bieten ja auch Fußgängernavigation. Ich weiß nicht, ob es nicht wichtig ist/wäre, wenn z.B. ein Blinder oder Rollstuhlfahrer auf dem footway=yes an eine definierte Stelle geführt wird, wo er evtl. gefahrenärmer die Straße überqueren kann. Autofahrer denken an Kreuzungen und Einmündungen wenigstens manchmal an Fußgänger. Und dort Übergänge zu taggen, wo ein abgesenkter Bereich ist, finde ich gerade für Rollstuhlfahrer wichtig. Der Goldstandard ist ein buckliger Weg mit vielen Windungen! :smiley:

Bei uns gibt es an der Hauptstraße tatsächlich behindertengerechte Übergänge an Kreuzungen. Dafür aber die Fußwege extra zu zeichnen, obwohl das ganz normal zur Straße gehört, ist mir zu blöd.

Ich zeichne bei mir auch alle Fuß und Radwege seperat ein. Übergänge mache ich überall da wo der Kantstein abgesenkt ist, oder durch Markierungen/Beschilderung ersichtlich ist das es ein übergang sein soll.
Bezwecken möchte ich damit eine präzisere Fußgängernaviagtion. Besonders an großen Kreuzungen finde ich es wichtig vernünftig geführt zu werden. Bei mir gibt es auch Ampelkreuzungen die nur an 3 der 4 Einmüdungen überquert werden dürfen, obwohl an allen 4 einmündungen Fußwege sind. Da ist es sinnvoll wenn man bereits 500m zufur an der fußgängerampel auf die richtige Seite geführt wird, um dann anschließend auch über die Kreuzung zu kommen. Dazu kommen Brücken über die weder Fußgänger noch Radfahrer dürfen, und Fußwege die spontan baulich getrennt werden und erst später wieder zusammen geführt werden. zudem habe ich jetzt auch angefangen an Häusern die eingänge zu markieren und mit den Fußwegen zu verbinden. Und bei Luftbildern mit 5cm Auflösung kann ich auch Problemlos den verlauf um Parkbuchten oder andere Hindernisse einzeichnen.

Der Grund ist einfach: Es funktioniert nicht. Es ist nicht vernünftig auswertbar. Aus Sicht der Auswertung besteht keinerlei Zusammenhang zwischen dem getrennt gemappten Gehsteig und der Straße. Wenn man die Straße in ihrer realen Breite rendert, dann gibt es Überlappungen und Lücken zwischen Gehsteig und Straße. Etc.

Dafür braucht es keine separat gemalten Gehwege, genausowenig wie es für Fahrspuransage im Navi separat gemappte Fahrspuren braucht – das wäre sogar hinderlich.

Genau. Man stelle sich mal eine S-förmige Straße vor, beidseitig mit separatem Fussweg gemappt, und in kurzem Abstand Überquerungsmöglichkeiten.

Und dann lasse man das Navi mal den kürzesten Fussweg berechnen.

Also ich käme mir veräppelt vor wenn das Navi jede Minute sagt: “Und nun bitte auf die andere Straßenseite wechseln”.

Außerdem was nützen hochpräzis gemappte Wege, wenn das GPS Gerät aufgrund der beschränkten Genauigkeit die falsche Spur trifft.

Dass man mit “präzisem Mapping” besseres Routing erreicht ist ein Trugschluss.

Ein vernünftiges Routing würde berücksichtigen das ein Queren von anderen Wegen mehr zeit kostet als 3 Meter Umweg. So wie es bei mir jetzt gemappt ist schickt mich osmand zum beispiel auf der rechtne straßenseite entlang, lässt mich diese am ende überqueeren das ich auf die linke Seite komme (Links ist kein durchgäniger Fußweg). Lässt mich auf der neuen straße ein paar meter Links laufen und schickt mich dann über die Ampel auf die Rechte Seite. Genau so wie ich als ortskundiger Fußgänger auch gegangen wäre.

Sicher, aber ein vernünftiges Routing kann eben auch sidewalk- und crossing-Tags auswerten. Separate Ways, wie du sie befürwortest, haben doch gerade nur für “unvernünftiges” Routing einen Vorteil, also wenn man einen bestehenden Router ohne nennenswerte Anpassungen auf Fußwege ansetzt und zum Fußgängerrouter umdeklariert. Das Beispiel mit den Straßenquerungen ist eines von vielen, warum wir nicht auf diesen Ansatz hinarbeiten sollten, sondern es besser gleich richtig machen.

Ich habe auch Probleme damit, wenn man einfach so (richtige) Daten löscht, nur weil sie nicht ins (eigene) Schema passen oder (einige) Router damit nicht vernünftig umgehen.
Wozu wurde denn mal “footway=sidewalk/crossing” eigeführt, wenn nicht für solche Fälle? Und wenn man einen Blick in die nahe Zukunft wirft, bzw. die Entwicklung der Datengenauigkeit etwas in die Zukunft extrapoliert, wird das extra mappen von Bürgersteigen weiter zunehmen. Besonders falls sich Ideen wie “area:highway” o.ä. durchsetzten.
Das Problem, das ich hier sehe, ist sich gegenseitig wiedersprechende Interessen oder auch Abstraktionsgrade. Anstatt also die Wege zu löschen möchte ich mal eine Art von Doppelrepresentation vorschlagen.
Dies könnte z.B. so aussehen, dass an Bürgersteige (wie jetzt schon empfohlen) mit “highway=footway + footway=sidewalk” getaggt werden und zudem auf der Straße z.B. alt: “footway=right/left/both + footway:right/left/both=sidewalk/sidepath +/oder foot=use_sidewalk/use_sidepath” oder neu: “sidewalk=right/left/both + sidewalk:right/left/both=sidepath +/oder foot=use_sidewalk/use_sidepath” getaggt werden. Dann kann sich jeder aussuchen, was er verwenden möchte. Über die genaue Ausgestalltung der Tags muss man dann sprechen. Aber von Grundgedanken her ist das eine mögliche Lösung.
Natürlich hat man dann entsprechend mehr zu tun, keine Frage, und die Probleme, welche Redundanzen verursachen können, sieht man bei den Steet-Relationen.

Bei der Frage nach dem S-Weg-Routing sehe ich hier ähnliche Argumentationen, wie beim Thema “turn:lanes”/“eigene Spuren”. Ich denke, die Daten sollten in sich logisch bzw. konsequent eingetragen werden und nicht danach, wie (ein) Router damit umgeht. Zumal hier schon Lösungen aufgezeigt wurden, wie man Router durch bestimmet Tags bei der Datenauswertung unterstützen kann. Es ist also möglich, zum mindest theoretisch, einen Router vernünftig zu programmieren.

Wenn wir alle Bürgersteige, die lediglich durch einen Randstein von der Straße getrennt sind als separate Wege erfassen, wie unterscheiden wir die denn von den anderen Wegen, die von der Straße stärker getrennt sind? Dass dazwischen keine Barriere, Grünstreifen, Büsche eingetragen sind dürfte nicht reichen, weil das trifft auf fast alle Straßen zu. Ein highway-area um alles rum? Eine Relation, die “da ist nur eine kleine Stufe” ausdrückt?

Irgendeine Möglichkeit müssen wir dem Router ja geben, das zu erkennen, falls der auch “einfach so mal” über die Straße routen soll und sich nicht auf vordefinierte Übergangsstellen beschränken soll. Die Beschränkung ist sicher sinnvoll für manche Zielgruppen, aber viele kommen auch gut mit beliebigen Stellen zum Überqueren klar und erwarten das auch von ihrem Navi.

Selbst wenn der Router das erkennen könnte, stelle ich mir die Auswertung noch ziemlich schwierig vor. Aber die Ideen scheinen ja da zu sein, jemand müsste sie nur mal in Code umsetzen…

Grüße, Max

Wir sollten doch an den Grundsatz denken:

Daten erfassen, wie sie vorhanden sind.

Ohne Abstraktion oder Denken, wie kann mein Router damit umgehen. Manche möchten auch einen “Fußwegplan” für sichere Wege als Plan oder Karte - andere ein “Fußgängerrouting” - andere einen “Guide zu historische Objekte” - …

Und dann dieses löschen, weil man andere Meinung ist?

Wenn man einen Fußweg als eigenständigen Weg einträgt, weil man glaubt, dass das so die Realität besser wiedergibt, kann man ruhig weiter abstrahieren und denken. Dass ich diesen Weg überall Richtung Straße verlassen kann, ist ebenfalls Teil der Realität. Dann könnten nicht nur manche Leute etwas damit anfangen…

Nein…

Moin,

so, wie Du sie auch hier gerade sprachlich unterscheidest: Nämlich als Bürgersteig und nicht als (Fuß-)Weg.
(Da muss dann auch nicht unbedingt ein Randstein existieren - Linien und Pflasterungen gelten ja ebenfalls als “eindeutige” Abgrenzungen.)

Und nichts Anderes macht doch sidewalk (siehe Hubert87) in den unterschiedlichen Ausprägungen.

Gruß
Georg

+highway=footway (defines the way) - Router: zwischen diesem und dem benachbarten highway kann nicht ohneweiteres gewechselt werden.
+footway=sidewalk (specific for sidewalk) - Router: von hier kann jederzeit zum “benachbarten” highway gewechselt werden
(+foot=)
(+bicycle=
)
+surface=* (defines paving).
(+smoothness=)
(+name=
- only if present, optional).
(+wheelchair=* - f in the presence of pavement or stretch difficult for the disabled, put “no”).
(+barrier=)
(+tactile_paving=
)
(+kerb=*)

ok, das wäre eine Lösung, falls “footway=sidewalk” nur an Wegen verwendet wird, wo man vom Weg runterkommt. Dann hätte der Router nur noch die Arbeit, rauszubekommen, was die Nachbarstraße ist. Das sollte lösbar sein, jedenfalls so gut wie in der Realität.

Wird das generell so verwendet?

Nachtrag:

Ich hatte Hubert so verstanden, dass er das sidewalk auf der Straße lassen will und zusätzlich den Fußweg eigenständig eintragen will. Da hätte ich Probleme gesehen, aber mich auch gern durch eine Umsetzung der Ideen überzeugen lassen…

Sollte es

ich war jetzt ein paar Tage hier - ums Krankenhaus Dresden-Neustadt

oder in Wegendorf (angefangen)