Frage zur verwendung von Fußwegen

Ich habe bei meiner Recherche 2 Wege gefunden Fußwege zu Mappen.

Ich kann wenn ich einen Highway mappe Sidwalks angeben (left/rigth/both/seperate ect) oder neben den Highway einen Footway mappen.

Sidewalks zum Highway geht sehr einfach, wird aber scheinbar gar nicht dargestellt und funktioniert nur so lang der Fußweg genau parallel läuft?

Wenn ich einen Footway nehme kann ich dem natürlichem lauf des Weges etwa um Blumenbeet folgen?

Was ist richtig…oder liegt die Wahrheit wie immer dazwischen?

LG

Sascha

Es gibt beide Varianten (siehe ältere Threads in diesem Forum).

Empfohlen wird, einen separaten Weg nur bei baulicher Trennung von der Fahrbahn zu mappen.

Chris

bauliche Trennung ist dann wenn er sich anders schlängelt als die Straße denke ich mal?

Verstehe ich es dann richtig dass die “baulich getrennten” gerendert/dargestellt werden, aber die an einen Highway getaggten nicht?

Warum wird da mit zweierlei Maß gearbeitet? Ist es nicht sinnvoll auf der Karte das vorhandensein von Bürgersteigen zu zeigen?

Erstens um sie zu benutzen und zweitens um “fehlende” zu sehen.

Oder mache ich das einen Anfängerdenkfehler?

Bitte um Erhellung!

Im Sinne der Fortschreitung “Detailmapping” sind getrennte (Fuß-, Rad-) Wege m.E. sinnvoll - wenn vorhanden. Auch wenn baulich nur ein Bordstein …

Das liegt daran wie Wege gerendert werden.

  • Ein eigener Weg ist relativ einfach
    Ggfs. wird er durch die daneben liegende Straße verdeckt.
  • Eine Eigenschaft zusätzlich darzustellen, ist nur dann einfach,
    wenn sie für beide Seiten gilt, jedoch schwierig, wenn sie nur
    auf einer Seite vorhanden ist.

Bezüglich Detail-Mapping muss du dein eigenes Maß finden.
Persönlich setze ich eigene Wege, wenn es eine klare Trennung wie einen Grün- oder Parkstreifen usw. gibt. Wichtig finde ich, Fuß- (und Rad-)wege an (größeren) Kreuzungen einzutragen. Da ist oft aus der Kartendarstellung nicht klar, wo und ob man die Fahrbahnen überqueren kann/darf.

Edbert (EvanE)

Stimme den beiden Vorpostern zu - bei mir hängt es zum einen daran, mit wieviel Details ich die Gegend gerade mappe und zum anderen auch an der Breite der Straße: Eine schmale Ortsstraße bekommt eher ein sidewalk=yes, eine breite Durchgangsstraße eher einen parallelen Fußweg.

Man sollte sich nur über die Konsequenzen dieses Mappings bewust sein! Es ist für ein Fußgängerrouter nicht mehr möglich die Straße zu überqueren. Auch müssen die Kreuzungsmöglichkeiten gepflegt werden und die eigentliche Straße braucht ein foot=no.

Weiterer Nachteil : Geo-Auswertungen wie ‘zeig mal alle Strassen mit Bürgersteig’ werden erschwert durch Separatmapping.

Meiner Meinung nach produziert jeder, der derzeit Gehsteige als separate Ways einzeichnet, nicht vernünftig auswertbare Daten. Die Resultate sind in der Praxis oft deutlich schlechter, als wenn man das Eintragen komplett gelassen hätte, denn es fehlt schlicht der maschinenlesbare Zusammenhang zur Straße und in vielen Fällen auch Querungsmöglichkeiten.

Bei Gehsteigen, die nur mit einer Bordsteinkante abgesetzt sind, ist Separatmapping in meinen Augen ohnehin klar fehl am Platz. Verständnis habe ich eher bei baulich deutlich abgetrennten Wegen, die deutlich nichtparallel zur Straße geführt sind und wo es nur wenige, klar erkennbare Kreuzungsmöglichkeiten gibt (die dann natürlich auch alle eingetragen werden müssen). Allerdings ist das ungelöste Problem mit dem Zusammenhang zur Straße durchaus auch dort relevant

Ich verwende derzeit deshalb ausschließlich sidewalk=left/right/both/no als Zusatztag am highway. Es ist sicher für die Zukunft wünschenswert, die Lage und Ausdehnung von Gehsteigen einzutragen (vergleichbare Diskussionen haben wir ja auch bei Fahrzeugspuren), aber das muss auf eine Weise geschehen, durch die der Zusammenhang zur Straße nicht verloren geht.

Es werden derzeit gar keine Gehsteige absichtlich gerendert. Dass separat gemappte Ways mit highway=footway + footway=sidewalk beim Default-Mapnik-Stil auftauchen, liegt ausschließlich daran, dass der Renderer footway=sidewalk nicht kennt und er die so gemappten Gehsteige daher für ganz normale, von einer Straße unabhängige Fußwege (highway=footway) hält und entsprechend behandelt.

Moin,

die Vor- und Nachteile der Fusswege als eigene ways wurden ja schon genannt. Für straßenbegleitende Radwege gilt das gleiche.

Man könnte die Nachteile weitgehend vermeiden, wenn man über ein Zusatztag aussagt, dass ein Weg straßenbegleitend ist, und umgekehrt ein Tag an der Straße aussagt, dass ein Fußweg bzw. Radweg existiert.
Ich hatte in einer anderen Diskussion einmal “associated=yes” am path/footway/cycleway und “associated_ways=cycleway;footway” an der Straße vorgeschlagen.
Statt “associated=yes” wäre natürlich auch “footway=sidewalk” als Kennzeichnung möglich.

Damit könnte man je nach Anwendung die straßenbegleitenden Wege als ways nutzen (Karten mit großem Zoomlevel, detaillierte Routinganweisungen) oder nur die Straße auswerten (Karten im mittlern Zoomlevel, schnelles Routing).

Viele Grüße
Stephan

Der Zusammenhang mit der Straße ist durch die räumliche Lage gegeben (Korridor um die Straßenmitte). Das ist zugegeben nicht so einfach auswertbar, wie ein footway/sidewalk=left/right/both/none. Unabhängig davon wäre es wünschenswert, Rad- und Fußwege per Tagging einer bestimmten Straße zuordnen zu können.

Rad- und Fußwege nicht seperat einzutragen kann aber auch Nachteile haben. Ist der Weg z.B. durch Grünstreifen abgesetzt, gehen Querwege zu einem Teil vom Rad-/Fußweg ab und haben keine Verbindung zur Straße. Wird der (abgesetzte!) Weg parallel zur Straße nicht eingetragen, scheinen solche Querwege eine direkte Verbindung zur Straße zu haben, obwohl das im Einzelfall real nicht der Fall ist.

Edbert (EvanE)

Seh ich auch so. Die Diskussion um die “straßenbegleitenden” Wege ist doch vom Prinzip her die Gleiche wie die ums gleisgenaue Mapping… Einfach weiter separat mappen und mit footway/cycleway=sidewalk, etc. versehen sowie an Kreuzungen die gedachten Wegverlängerungen an den highway=* mappen, um wenigstens die Haupt-Straßenübergange darzustellen. Das gibt dann meistens vier Schnittpunkte um den Kreuzungsknoten.

Klar, nicht einzeichnen ist immer wesentlich genauer als vorübergehend gezwungenermaßen nicht ganz korrekt einzeichnen, da ist der Informationsgehalt immer wesentlich höher! Außerdem lassen sich die Tags am Weg prima um Details und neue Eigenschaften erweitern und den korrekten Verlauf des Weges geben sie erst recht immer wieder! :wink: Bei nicht vorhandenen Daten kann man dann natürlich auch nicht groß was falsch auswerten! Problem gelöst. :wink:

und zu den Märchen von den nicht vernüftig auswerterbaren Daten, den angeblich nicht lösbaren Querungsproblemen, etc. sei mal wieder auf https://wiki.openstreetmap.org/wiki/File:Generisches_spurmodell.pdf verwiesen. Kurz: das läßt sich Alles lösen und bis es dann endlich allgemeiner Konsenz ist (je mehr separate Wege es gibt um so schneller gibt es da dann auch eine vernüftige Lösung…), mappt man eben die etwas schlechtere Kompromißlösung.

Bei dieser sollten die Wege, gerade eben als Übergangslösung und in Rücksichtnahme auf die Leute, die die Wege, obwohl nun mal in der Realität vorhanden, da am liebsten überhaupt nicht sehen wollen, mit footway/cycleway=sidewalk getaggt werden, so das sie über diese Tags leicht auszufiltern sind und die Leute die hier wegen angeblichem Datenmüll jammern weglose Daten erzeugen können.

Heute malen wir noch den Weg mangels, des schon seit 4 Jahren nicht vorhandenem Konsens über das Tagging von Straßen als Gesamtmodell, ohne korrekte Straßen-/Fahrbahnzuordnung ein und morgen, wenn es dann alle irgendwie erkannt, begriffen bzw. endlich die Notwendigkeit sehen, setzen wir dann Relationen für die korrekte Zuordnung zur Fahrbahn und Straße drauf. Die Wege verschwinden ja inzwischen nicht einfach grundlos! Die “bauliche Trennung” ist irrelevant, wichtig ist eher, ob die Wege als eigenes Objekt wahrgenommen werden. Und wer trotzdem nach dem Schema der “baulicher Trennung” (aus meiner Sicht ist das nur das gezwundene Zugeständnis der Weg-Nichtmapper, weil sie in dem Fall keine andere Lösung für die korrekte Wiedergabe der Realität gibt) taggen möchte, soll an den Bordstein und die ganzen Ritzen mit Erde/Sand/Bitumen dazwischen denken… :slight_smile:

Bei foot=no kann ich die Straße nach momentanem Schema ja auch nicht überqueren, weil die Richtung der Queerung nicht unterscheiden wird, und ohne abgetrennten Weg frag ich mich, wie du universell die diversen Zusatztags wie surface=* auwerten und den genauen Verlauf korrekt wiedergeben willst. Mein konstruktiver Vorschlag zu der Querungsdebatte ist ja oben schon verlinkt. Edit: Außerdem ist die Auswertbarkeit für den Fußgängerrouter bei footway=sidewalk auch noch gegeben, wenn auch etwas rechenaufwändiger, weshalb man da eben besser auf Relationen oder noch besser, wenn möglich, gleich auf das Mappen der Flächen und deren Übergänge ausweichen sollte.

Warum nicht einfach mal nur die Fuß-/Radwege als Weg einzeichnen und da die Fahrbahnen dann per Zusatztags definieren? :wink: :stuck_out_tongue:

Leute, ich bin nun ganz durcheinander, wie ich was mappen soll, oder doch nicht.

Sobald es etwas “offizielles” im Wiki gibt, halte ich mich gerne dran.

Aber ein Neuling hört gleich wieder auf, wenn er die ganzen Regeln beachten möchte (die er ja eigentlich sollte). Zehn mal wird er sich sicherlich nicht an den selben Weg setzen und ihn umtaggen, bis es passt. Und dann ändert sich ja doch wieder was.

:rage:

Ja, es gibt Ähnlichkeiten: Auch damals wurde vermutet, man würde entweder
a) Relationen oder sonstiges Tagging einführen oder
b) intelligente Programme entwickeln,
um Gleisbündel bei Bedarf zusammenfassen zu können (z.B. zum Rendern auf höheren Zoomstufen oder für “Streckenkarten”).

Bis heute habe ich außer einem Prototypen in einem FOSSGIS-Vortrag keine Programme mit der erhofften Funktionalität gesehen. Und das war obendrein ein Spezialprojekt genau für diesen Zweck - kein Allzweckrenderer, der sich auch noch um tausende andere Sachen kümmern muss.

Nun ist das Zusammenfassen von Gleisbündeln wohl kein besonders “wichtiges” Feature und OSM kann auch ganz gut ohne auskommen. Hier geht es aber um Dinge wie Rendering von Straßen oder Routing - falls es genauso läuft wie beim gleisgenauen Mapping, sehe ich also schwarz für die Praxistauglichkeit von OSM in den nächsten Jahren.

Das funktioniert nur leider nicht. Vergleiche dazu etwa Edberts Beispiel mit Querwegen, die keine Verbindung zur Straße haben: Filtert man in so einem Fall die separat gemappten sidewalks einfach weg, dann steht man ganz ohne Verbindung zwischen Querweg und Straße da.

Das ist tendenziell eher ein Ratespielchen als ein Zusammenhang. De facto wird sich das kaum ein Auswerter antun.

Wie beim Verweis von Fabi2 auf das prinzipiell durchaus machbare Spurflächenrouting: Dass es theoretisch möglich ist, ist nicht genug. Genauso wie OSM eine gewisse Benutzerfreundlichkeit beim Mappen bewahren muss, weil man mit “theoretisch eintragbaren” Konzepten Mapper verschreckt, muss es eine gewisse Benutzerfreundlichkeit beim Auswerten geben, weil Programmierer wenig von “theoretisch auswertbaren” Konzepten haben. Und diese Tauglichkeit misst sich an den heutigen Editoren und den heutigen Programmierbibliotheken - nicht denen in fünf Jahren.

Das bedeutet natürlich zwangsläufig, dass man Kompromisse machen und Umwege gehen muss: Eine Weile auf eine Übergangslösung setzen statt gleich zur potentiell optimalen Lösung zu greifen. Womöglich sogar über die Jahre hinweg mehrere, zunehmend genauere Übergangslösungen einsetzen, während das Projekt und seine Werkzeuge reifen.

Was ist also nach diesen philosophischen Ausführungen meine Empfehlung für das konkrete Problem?

  • Für Wege, die von der Fahrbahn nur durch eine Linie, Bordsteinkante o.ä. getrennt sind, ist zum jetzigen Zeitpunkt sidewalk=left/right/… der unzweifelhaft beste Weg.

  • Für Wege, die von der Straße getrennt verlaufen, ist separates Mapping ein Schritt seitwärts: Man gewinnt manche Informationen und verliert andere. Da es hier irgendwann wohl sowieso auf separate Ways hinausläuft, sehe ich es als vertretbar, diesen Schritt schon jetzt zu gehen (auch wenn ich es selber noch nicht tue).

Alle Jahre wieder, kommt die “straßenbegleitende” Wege Diskussion…

Die Diskussion hatte ich damals noch nicht mitverfolgt, aber das Problem an sich ist eben fast identisch.
Zum einen passiert natürlich Nichts, wenn dazu keine Notwendigkeit besteht. Bisher hatte offenbar von den Bedenkenträgern ja auch noch niemand so großen Leidensdruck, um eben z.B. da zusätzlich Relationen einzuführen. Sicher würde beim Thema Straßen da aus meiner Sicht eher was pasiereen, einfach weil auch was passieren muß.

Ja, aber was soll man denn machen? Weil wahlweise halten die allgemeineren/universellen Lösungen alle für zu kompliziert (versteht keiner → keine Mapper mehr) bzw. nur mit (nicht vorhandenen) Tools mappbar, da wäre man aber, wenn man das Schema mal so gut wie möglich aufräumt, für eine lange Weile, wenn nicht immer, die Probleme los. Andererseits wird ja auch zu Recht, in Bezug auf die Anwendungen, nach Komaptibilität geschrieen und dann frickelt man eben an die eh schon nicht gerade gute Darstellung, wie z.B. bei den Verkehrschildern, noch ein paar schlechte Erweiterungen an, um das Problem temporär zu lösen, aber die Ausmaße des Tagging-Datensalats langfristig nur noch größer zu machen, bis man dann zig verschiedenen Darstellungen für erweiterte Zugangsbeschrängungen parallel verwendet, weil es ja immer noch alte Daten nach Schema x-1 gibt, das die neuen Sonderegelungen von Land y noch nicht berücksichtigt bzw. man ja sogar eben meint, jede mogliche Kombination von Verkehrszeichen in Kurzform und noch dazu am Weg erfassen zu müssen, anstatt das man auch da mal die Realität mappt. Irgendwann ist das ganze dann nicht mehr handhabbar, dazu kommen dann noch die technischen Beschränkungen des key=value-Schemas, wie daß man, ohne Relationen, bei der Notwendigkeit mehrere verschiedenen Eigenschaften an einem Objekt man gezwungen ist, neue Keys für die Beschreibung der gleichen Tatsache (Straße mit surface=asphalt, Radweg nicht extra gemappt, aber Oberfläche soll auch erfasst werden, der etablierte universelle Key für die Oberfläche eines Objekts wäre surface=*… Das gibts dann je nach Objekttyp zig neue Schlüssel für die gleiche Eigenschaft! Gedankenexperiment zur Verdeutlichung: Straßentyp- und Straßenoberfläche getaggt am danebenliegenden Fußweg, viel Spaß bei der Auswertung! ;)) zu erfinden und so die universelle Auswertung zu erschweren.

Ohne Leidensdruck wird da aus meiner Sicht auch nichts passieren. Da setzt sich auch niemand hin und entwickelt Software, lieber wird mit der nächsten Erweiterund die langfristige Katastrophe nur noch schlimmer gemacht. Schwarz sehe ich da auch nicht, aber man sollte mal möglichst langfristig anfangen manche Probelme anzugehen, damit nicht dann alles schnell übers Knie gebrochen wird, wenn die Katastrophe dann erst mal da ist.

Doch, das funktioniert.
Mündet ein Fußweg auf die Straße ein und kreuzt dabei den Sidewalk, dann tut er es auch, wenn der Bürgersteig nicht vorhanden/gemappt wäre, da ist das rauslöschen des Bürgersteigs kein Verlust in Bezug auf die Verbindungen zur Fahrbahn.
Wenn es kleine Querverbindungswege zwischen Straße und Sidewalk gibt, die anschließend nicht als Fußweg, über den Sidewalk hinaus, weitergeführt werden, so hättet ihr diese Details beim Mappen des Bügersteigs als Tag an der Straße ja ebensowenig, da diese zusätzlichen Details bei euch zu gunten des Zusatztags komplett unter den Tisch fallen würden. Haltet ihr sie für wichtig, dann ist das aber auch definitiv “bauiliche Trennung” nach eurer Definition, wenn man da sogar noch den Aufwand für einen extra Verbindungsweg vom Sidewalk in Richtung Straße treibt, auch wenn da vielleicht nur ein kanpper Meter Rasen dazwischen ist.

*Fazit: Man kann problemlos die “straßenbegleitenden” Wege mappen, wenn man diese als Kompromiß passend mit =sidewalk taggt, ist es auch kein Problem diese auszufiltern!

Was ist denn für dich Benutzerfreundlichkeit? Ein künstlich beschränktes Schema, wo regelmäßig dann doch noch ein Fuchsschwanz angehangen werden muß, auf Grund noch unzureichender Editoren bzw. der hohen Komplexität bei der Mappbarkei, oder Werkzeuge, die es ermöglichen, das Jeder ein kompliziertes Schema eintragen kann?

Die Potenziell optimale Lösung ist sicher auch nicht unbedingt die Opimalste, weil da kann es immer noch Faktoren geben, die man nicht wußte kennt und wo dann später eben deswegen eine neue Lösung finden muß, weil man ist ja auch nur ein Mensch, aber man sollte zum gegeneben Zeitpunkt beste Lösung umsetzen bzw. wenigsten die bekannten Probleme lösen oder zumindest die Lösung angehen. Da nützt es nichts, wenn man vorsichtig noch eine weitere Etage auf das Kartenhaus baut, in der Hoffnung, das schon nichts passieren wird, weil irgendwann stürzt es dann nämlich doch ein!

Grundsätzlich sind sich in den vier Jahren, die diese Diskussion schon ja mindestens geführt wird, die Werkzeuge in Hinblick auf das hier beschriebene Problem nicht nenneswert gereift (mal abgesehen von allgemeiner API-Relationsunterstützung und allgemeine Verbesserungen bei der Relationshandhabung in JOSM) und wenn man weiter darauf wartet wird das min. die nächsten vier Jahre auch noch so sein, außer man kekommt ordentlich Probleme bei der Auswertung, etc. und beginnt dann vielleicht irgendwie das Problem doch zu lösen.

Naja, die Übergangslösung ist ja eher noch das, was ich vorgeschlagen habe, eben der schon etablierte footway/cycleway=sidewalk-Zusatztag (ja hatte doch jemand soweit ich hier gelesen hatte, vor 'ner Weile 'nen mechanischen Edit zu Gunsten von sidewalk=* gemacht, obwohl *=sidewalk schon etablierter war) an den entsprechenden Wegen.

Wie kommst du zu dieser Erkenntnis?
Sollte eine Straße beidseitig mit seperrat gemappten Fußwegen ausgestattet sein, so gehört an die Straße automatisch foot=no, damit mich kein Router entlang der Straße schickt. Ein Router kann ohnehin einen Graphen nur in Längsrichtung folgen. Bei deinem Ansatz machst du fürs Routing aus der Linie zunächst eine Fläche und betrachtest die als unüberwindbar, das macht aber kein Auswerter. Denn unüberwindbar für diese Programme ist der Raum zwischen Fußweg und Straße. Wenn du das gelöst hast, ohne die von dir vorgeschlagenen Wege, denn mit denen spielt auch das fott=no keine Rolle, können wir darüber nochmal nachdenken.

Ist es zusammenfassend korrekt, wenn man

entweder
an einem way highway=residental + sidewalk=right verwendet (die Kombination highway=residental + footway=right sollte nicht mehr verwendet werden z.B. aus dem JOSM-Objektvorlage Bürgersteige?)

oder
zwei ways verwendet mit

  1. highway=residental + foot=no
  2. highway=footway + footway=sidewalk

benutzt?

Stefan

foot=no natürlich nur bei Verbot für Fußgänger, also bei Schild 259:
http://osmtools.de/traffic_signs/?signs=259

Das wäre IMHO schon fast Sabotage.

Sind die Fusswege korrekt mit highway=footways, footway=sidewalk kann man es getrost dem Router überlassen ob er die getrennt gemappten Wege verwendet oder einfach der Strasse nach routet.

Simon

Nun ja, es gibt so etwas wie ST_buffer bei Postgis.
Für diejenigen, die ohne Datenbank arbeiten, ist das natürlich erheblich mehr Aufwand.

Zum Thema Ratespiel: Bei einem POI (Knoten) in einem Gebäude (Fläche) akzeptieren die meisten durchaus die Aussage, “das ist durch die Lage in der Fläche eindeutig”.

Um es noch einmal klar zu sagen: Ich habe nichts dagegen eine Beziehung vom Rad-/Fußweg zur parallelen Straße herzustellen. Jedoch sollte das meiner Meinung nach durch Tagging wie associated=<Straßenname> oder ein ähnliches Schlüsselwort hergestellt werden.

Edbert (EvanE)