Frage zur verwendung von Fußwegen

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)

Ja, aber das hat noch einen anderen Grund: Das fehlende Wissen, dass der POI im Gebäude liegt, stört Anwendungen normalerweise nicht. POI suchen, zum POI routen, POI auf Karte anzeigen - für all das ist es weniger wichtig, dass eine Beziehung zwischen Gebäude und POI besteht. Daher wirst du auch kaum eine Anwendung finden, die diese Beziehung überhaupt herstellt.

Das Problem bei unserem Beispiel hier ist eben, dass anspruchsvolle Auswertungen nicht für exotische, fortgeschrittene Anwendungen, sondern für die alltäglichen Anwendungen nötig wären.

Der einzige eindeutige und immer verfügbare Schlüssel für eine Straße ist aber die Way-ID, nicht der Straßenname. Oft genug gibt es ja durchaus T-Kreuzungen oder noch komplexere Gebilde, in denen alle Straßen denselben Namen haben. Also wäre man doch wieder auf die komplexeren Algorithmen angewiesen, um die Beziehung herzustellen.

Dein “Fazit” ist wiederlegbar durch Gegenbeispiel: Fußweg mündet fast direkt in die Straße ein und wäre bisher einfach direkt mit der Straße verbunden. In der Realität liegen zwischen der Verknüpfung mit dem straßenbegleitenden Gehweg und der nächsten Querungsstelle aber zwei Meter Abstand. Der detailverliebte Mapper wird logischerweise keine direkte Verbindung mehr zwischen Fußweg und Straße schaffen. Filtert man nun den straßenbegleitenden Gehweg aus, hängt das Ende vom einmündenden Fußweg in der Luft.

Mein Fazit daher: Wenn Wege separat gemappt sind, dann ist der Auswerter gezwungen, sie auch entsprechend zu berücksichtigen. Das mit dem Ausfiltern funktioniert nicht. Diese Option sollte daher nur bei deutlicher (= nicht nur Bordstein) baulicher Trennung überhaupt in Erwägung gezogen werden. Wenn sie genutzt wird, dann muss darauf geachtet werden, auch alle Verbindungen zur Fahrbahn und alle Querungsmöglichkeiten einzutragen.

Konzeptionell sollte man außerdem über eine robuste und unmissverständliche Zuordnung zur Straße nachdenken.

Hier wurde die Straße mit foot=no gemappt. Resultat: Fussgänger können nicht mehr die Straße überqueren.
http://up.picr.de/12708866og.jpg (Rastede)

Mein Problem ist, dass ich nicht sehe, wo der Zusammenhang zwischen Straße und Rad-/Fußweg bei “alltäglichen” Auswertungen benötigt wird. Insoweit ist das für mich zur Zeit eine eher theoretische Diskussion.

Auch die Way-ID fuktioniert nicht ohne Probleme. Denn eine Straße kann entlang eines Rad-/Fußweges mehrfach gesplittet sein (Relationen oder Beschränkungen). Das erfordert dann mehrere Way-Ids im Wert. Auch können die Unterteilungen von Rad-/Fußweg und paralleler Straße völlig voneinander abweichen.

RFRFRFRxRFRFRFRFRFRFRFRFRFRFRFRFRFxRFRFRFRF
SSSxSSSSSSSSxSSSSSSSSSSSxSSSSSSSSSSSSSSxSSS 

‘x’ sind dabei die Wegtrenungen in Rad-/Fußweg (RF) und Straße (SS).

Edbert (EvanE)

Naja, es wird ja eher ein Konzept im Sinne einer Relation gemeint sein, da könnten dann ja alle zusammengehörigen Stücke eingetragen sein, der Rest wäre dann wohl nicht mehr so kompliziert.

Nun ja, Relationen werden zu diesem ZWeck als zu fehleranfällig (bei allfälligen Änderungen) angesehen.

Und nocheinmal die Frage, wofür wird die Zuordnung von Straße zu Rad-/Fußweg bei alltäglichen Auswertungen eigentlich gebraucht? Beim Rendern von Karten und beim Erstellen von RoutingGraphen sehe ich da nach der bisherigen Diskussion keine Notwendigkeit.

Edbert (EvanE)

Hast du dir das Beispiel einmal näher angesehen?
Ich zähle für dafür 7 Relationen und 6 zusätzliche Wege.

Rendern von Karten: jegliches Rendering auf dem üblichen Abstraktionsniveau (d.h. ohne separate Darstellung der Gehsteige).

Erstellen von Routinggraphen: immer dann, wenn man Attribute der Straße an den Gehsteig-Kanten im Graphen braucht. Beispielsweise Fußgängerrouting mit Straßennamen in der Routenbeschreibung.

OK, ich verstehe deine Gründe.

Ob man das als alltäglich oder speziell einschätzt, ist eine andere Frage, in der unsere Einschätzungen wahrscheinlich auseinander gehen werden.

Straßennamen beim Fußgänger-Routing macht natürlich Sinn. Das kann man jedoch durch eine Erweiterung von _name erreichen. Z.B. street_name= oder ähnliches am Rad-/Fußweg. Gegebenenfalls muss man dann bei einem Namenswechsel auch den Rad-/Fußweg passend teilen.

Edbert (EvanE)

Na was bedeutet denn foot=no? Ja, das ist, nach momentaner Definition, ein rechtlich begründetes Betretungsverbot für Fußgänger. Um über die Straße zu gehen, ohne diese zu betreten (ist ja schließlich verboten!), mußt du schon drüber fliegen oder springen, das ist aber nicht der Normalfall der Fortbewegung beim Fußgängerrouting.

Ja, aber man kann ja vorher die Richtung der Kanten nach beliebigen Kriterien festlegen…

Schon mal Linien und Punkte irgendwo in der Realität gesehen?

Welchen unüberwindbaren Raum zwischen Fußweg und Straße meinst du denn? Außerdem kommt es ja wohl auf den Fall an, ob der Raum überwindbar ist oder nicht. Vielleicht solltest du schon mal mit dem Nachdenken anfangen…

Ja, das stimmt natürlich, deshalb ist es da auch meine Empfehlung, den Weg entgegen der Realität, in diesem Fall trotzdem weiter durch zur Straße zu mappen. Ich befürworte ja auch, lieber mit geeigneten Mitteln die echte Realität abzubilden, weil sowohl meine als auch deine Lösung mit dem Tag am Weg sind ja nur Kompromißlösungen, die die Realität nicht korrekt wiedergeben, wobei aber bei mir die Realitätswiedergabe, im betrachten Fall der kleinen verzweigten Seitenwege, noch besser ist, als bei deiner “Tag am Weg der Straße”-Lösung. Außer ihr stellt jetzt fest, das diese kleinen Querwege bei euch doch ausreichend baulich getrennt sind, um sie extra zu erfassen, dann stellt sich ja das Problem mit dem Rauslöschen nicht mehr.

Das funktioniert ja prinzipbedingt nicht, bei der Tag-Lösung gibt es gar keine konkreten Angaben zu Querungsmöglichkeiten und bei der “Weg zur Straße durchverbinden”-Lösung von mir, gibt es die Infos wenigstens stellenweise, der Realität entsptricht aber beides nicht.

Die sollte aber auch erweiterbar, also universell/allgemein und, da großflächig verwendet, leicht maschinell umzusetzen sein. Natürlich sollte das Ergebnis der Umsetzung dann aber auch nicht nur vom Rechner überprüfbar sein.

Du magst es nicht verstehen? Wenn ich einen Fußweg parallel zu einer Straße zweichne, dann kann der Router den Zusammenhang zwischen Straße und Fußweg nicht herstellen und behandelt das als zwei unterschiedliche Wege. Damit aber der Router nicht auf die Idee kommt jemanden statt über den Fußweg zu routen, weil der Weg über die Straße kürzer ist (einseitiger Fußweg vielleicht) muss die Straße mit foot=no versehen werden.
StVO: "§25 Fußgänger

(1) Fußgänger müssen die Gehwege benutzen. Auf der Fahrbahn dürfen sie nur gehen, wenn die Straße weder einen Gehweg noch einen Seitenstreifen hat. Benutzen sie die Fahrbahn, so müssen sie innerhalb geschlossener Ortschaften am rechten oder linken Fahrbahnrand gehen; außerhalb geschlossener Ortschaften müssen sie am linken Fahrbahnrand gehen, wenn das zumutbar ist. Bei Dunkelheit, bei schlechter Sicht oder wenn die Verkehrslage es erfordert, müssen sie einzeln hintereinander gehen."

Schauen wir uns doch ein praktisches Beispiel an: http://maps.google.de/?ll=52.55802,13.574257&spn=0.001349,0.00409&t=h&z=19
Wenn jemand auf die Idee käme Fußwege am Bulmenberger Damm und in der Sitzendorfstraße getrennt zu erfassen. Wie würde das im Datenmodell bei OSM aussehen? Richtig es gibt keinen Unterschied. während aber am Blumenberger Damm wirklich Wiese und Gesträuch das überqueren der Straße unmöglich macht, grenzt der Fußweg in der Sitzendorfstraße unmittelbar an die Straßenfläche, welche am Rand (nicht unüblich für Wohngebietsstraßen) noch Parkflächen hat.

Für den Router stellt sich dieser Raum aber als unüberwindbar dar.und er würde dich immer bis zur Kreuzung leiten um dort die Straßenseite zu wechseln. am Blumenberger Damm zu recht, bei der Sitzendorf straße zu unrecht!

Nö, muss er nicht. Ein vernünftig gewählter, für Straßen etwas größerer Faktor, sollte vollkommen ausreichen.