Frage zur verwendung von Fußwegen

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 ...

saschahaberkorn wrote:

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?

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.

geri-oc wrote:

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

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.

saschahaberkorn wrote:

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?

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

Tordanik wrote:

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

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)

geri-oc wrote:

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

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.

Tordanik wrote:

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.

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! 😉 Bei nicht vorhandenen Daten kann man dann natürlich auch nicht groß was falsch auswerten! Problem gelöst. 😉

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/Fil … modell.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... 🙂

viw wrote:

geri-oc wrote:

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

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.

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? 😉 😛

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.

😠

Fabi2 wrote:

Seh ich auch so. Die Diskussion um die "straßenbegleitenden" Wege ist doch vom Prinzip her die Gleiche wie die ums gleisgenaue Mapping...

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.

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.

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.

EvanE wrote:

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.

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...

Tordanik wrote:

Fabi2 wrote:

Seh ich auch so. Die Diskussion um die "straßenbegleitenden" Wege ist doch vom Prinzip her die Gleiche wie die ums gleisgenaue Mapping...

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").

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.

Tordanik wrote:

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.

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.

Tordanik wrote:

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.

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.

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!

Tordanik wrote:

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.

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?

Tordanik wrote:

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.

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.

Fabi2 wrote:

viw wrote:

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.

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? 😉 😛

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

viw wrote:

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.
..

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

Tordanik wrote:

EvanE wrote:

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.

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

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)

EvanE wrote:

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".

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.

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.

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.

Fabi2 wrote:

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!

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)

Tordanik wrote:

EvanE wrote:

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".

Ja, aber das hat noch einen anderen Grund: Das fehlende Wissen, dass der POI im Gebäude liegt, stört Anwendungen normalerweise nicht. ...

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.

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.

Tordanik wrote:

EvanE wrote:

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.

Der einzige eindeutige und immer verfügbare Schlüssel für eine Straße ist aber die Way-ID, nicht der Straßenname. ...

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)

EvanE wrote:

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.

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.

errt wrote:

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)

errt wrote:

EvanE wrote:

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.

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.

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

EvanE wrote:

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.

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.

Tordanik wrote:

EvanE wrote:

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.

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)

viw wrote:

Wie kommst du zu dieser Erkenntnis?

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.

viw wrote:

Ein Router kann ohnehin einen Graphen nur in Längsrichtung folgen.

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

viw wrote:

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.

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

viw wrote:

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.

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...

Tordanik wrote:

Fabi2 wrote:

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!

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.

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.

Tordanik wrote:

Wenn sie genutzt wird, dann muss darauf geachtet werden, auch alle Verbindungen zur Fahrbahn und alle Querungsmöglichkeiten einzutragen.

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.

Tordanik wrote:

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

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.

Fabi2 wrote:

viw wrote:

Wie kommst du zu dieser Erkenntnis?

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.

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."

Fabi2 wrote:

viw wrote:

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.

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...

Schauen wir uns doch ein praktisches Beispiel an: http://maps.google.de/?ll=52.55802,13.5 … 9&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!

viw wrote:

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.

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

viw wrote:

Wie würde das im Datenmodell bei OSM aussehen? Richtig es gibt keinen Unterschied.

Doch: Wenn wir schon Detailmapping Straße-Gehweg betrachten, müssen wir natürlich alle anderen Gegebenheiten mit beachten.
Einmal befindet sich ein Grünstreifen zwischen den beiden Wegen - ist der als landuse=grass getagged, kann ihn ein Fußgänger überwinden, barrier=hedge oder landuse=scrub aber nicht. Ich sage nicht, dass das in Software einfach wird, aber möglich ist es allemal.

viw wrote:

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.

Also die üblichen Parkflächen in Städten sind so dicht zugestellt, dass da nur ein normalgebauter Mensch durchkommt und das auch nur wenn er nichts mit sich trägt. Kinderwagen, Rollstuhl: völlig unmöglich.

mueschel wrote:

...
Einmal befindet sich ein Grünstreifen zwischen den beiden Wegen - ist der als landuse=grass getagged, kann ihn ein Fußgänger überwinden, barrier=hedge oder landuse=scrub aber nicht. Ich sage nicht, dass das in Software einfach wird, aber möglich ist es allemal.
...

Woher willst die Auswertung wissen, wie dicht hedge oder scrub ist? (oder ob ich für den Bedarfsfall meine Machete dabei habe 😄 )

hurdygurdyman wrote:

Woher willst die Auswertung wissen, wie dicht hedge oder scrub ist? (oder ob ich für den Bedarfsfall meine Machete dabei habe 😄 )

Die Machete darf man allerdings nur außerhalb der Brut und Aufzuchtzeit (falls überhaupt) benutzen. 😉

Edbert (EvanE)

Festzuhalten bleibt doch: So lange wie ein am Highway als zusätzlicher Tag gepflegter Fußweg nirgendwo gerendert wird, wird diese Art des mappens nicht zum erfolg führen, auch wenn dieser für Baulich nicht getrennte Wege (abgesehen vom Bordsteig) wesentlich eindeutiger und meineserachtens für routing sinnvoller sein sollte. Ein jeder Mapper möchte unterm Strich von seiner Tat etwas auf der Karte sehen. Mir ist jedoch keine Karte bekannt in der eine entsprechende Darstellung erfolgt.
Ein separat gezeichneter Fußweg hat zumindest schon mal genau den Vorteil, auch wenn ich dies persönlich als sehr unschön empfinde (warum, wurde bereits erörtert).

Im Hinblick auf http://wiki.openstreetmap.org/wiki/DE:Street_area wird man diese Thematik eh anders lösen müssen.

Für Baulich getrennte Verkehrswege ist fast immer ein eigener Way sinnvoll.

PS: Die Auswirkungen des nicht darstellens der zusätzlichen Highwayattribute, wie Fußwege, Radwege, Breite, etc sind doch schon länger vorallem in Städten zu beobachten: Rad- & Fußwege die durch Häuser verlaufen, die komische Zickzacklinien zu jeder Kreuzung machen, die extra mit Bushaltestellen, Hauseingängen, usw. verbunden werden, über die kein sinnvolles Routing möglich ist, usw... Eine endlose Katastrophe. Auch hier sieht man wieder: Ein großteil der Menschheit zieht das Auto den zwei Beinen oder dem Zweirad vor, anders kann ich mir die fehlende sinnvolle Umsetzung für alle anderen Verkehrsteilnehmer nicht erklären.

reneman wrote:

PS: Die Auswirkungen des nicht darstellens der zusätzlichen Highwayattribute, wie Fußwege, Radwege, Breite, etc sind doch schon länger vorallem in Städten zu beobachten:

cycleway=track wird immerhin auf dem Cycling-Layer dargestellt und im verflossenden Osmarender wurde es auch gerendert.
Chris

reneman wrote:

Festzuhalten bleibt doch: So lange wie ein am Highway als zusätzlicher Tag gepflegter Fußweg nirgendwo gerendert wird, wird diese Art des mappens nicht zum erfolg führen, auch wenn dieser für Baulich nicht getrennte Wege (abgesehen vom Bordsteig) wesentlich eindeutiger und meineserachtens für routing sinnvoller sein sollte. Ein jeder Mapper möchte unterm Strich von seiner Tat etwas auf der Karte sehen. Mir ist jedoch keine Karte bekannt in der eine entsprechende Darstellung erfolgt.

Ich stimme zu, dass das ein Problem ist. Es gibt zwar ein paar Möglichkeiten, seine sidewalk-Tags zu sehen, unter anderem ...

• den Sidewalk-Stil, mit dem man sich zumindest im JOSM die both/left/right/no als gestrichelte Linien neben der Straße hervorheben lassen kann.
• eine von ITO gerenderte Darstellung "Sidewalks and footways" mit zahlreichen Taggingvarianten, die allerdings nur das Vorliegen eines sidewalk-Tags visualisiert, nicht die konkrete Platzierung
• OSM2World, dem ich vor einiger Zeit Gehsteige beigebracht habe - allerdings ist die Unterstützung auch hier noch sehr primitiv (keinerlei Attribute außer der Existenz, d.h. sie sehen alle gleich aus). Und in der OSM2World-Slippymap fallen sie auf den verfügbaren Zoomstufen praktisch nicht auf.

Eine "richtige" Karte ist wohl nicht dabei. 🤔

Und genau in dem Punkt, wäre es etwa gut, mal Druck zu machen, oder zu helfen, dass Mapnik2 Wege außermittig zeichnen kann. Dann könnte man Mapnik2 auch für sidewalks oder cyclways benutzen. Derzeit gibt es die Möglichkeit nicht (obwohl schon lange geplant). (und genauso wäre Hilfe für AndyAllans CartoCSS Styl und übernahme super, weil das derzeitige Mapnik Stilmodell ist, naja, renovationsbedürftig oder abbrissfähig).

extremecarver wrote:

Und genau in dem Punkt, wäre es etwa gut, mal Druck zu machen, oder zu helfen, dass Mapnik2 Wege außermittig zeichnen kann. Dann könnte man Mapnik2 auch für sidewalks oder cyclways benutzen. Derzeit gibt es die Möglichkeit nicht (obwohl schon lange geplant). (und genauso wäre Hilfe für AndyAllans CartoCSS Styl und übernahme super, weil das derzeitige Mapnik Stilmodell ist, naja, renovationsbedürftig oder abbrissfähig).

Dann hast du bestimmt schon ganz tolle Vorarbeiten geleistet.

extremecarver wrote:

Und genau in dem Punkt, wäre es etwa gut, mal Druck zu machen, oder zu helfen, dass Mapnik2 Wege außermittig zeichnen kann. Dann könnte man Mapnik2 auch für sidewalks oder cyclways benutzen. Derzeit gibt es die Möglichkeit nicht (obwohl schon lange geplant).

Wirklich nicht? Zumindest bei Tilemill kann ich mit CartoCSS line-offset benutzen. Und Tilemill benutzt Mapnik2 als Rendering-Engine.

Christian

extremecarver wrote:

Und genau in dem Punkt, wäre es etwa gut, mal Druck zu machen, oder zu helfen, dass Mapnik2 Wege außermittig zeichnen kann. Dann könnte man Mapnik2 auch für sidewalks oder cyclways benutzen. Derzeit gibt es die Möglichkeit nicht (obwohl schon lange geplant).

Das sollte inzwischen funktionieren, gearbeitet wurde daran jedenfalls:
https://github.com/mapnik/mapnik/pull/1269

Ich weiß allerdings nicht, wie gut das funktioniert und wie gut man das anpassen kann.

Hier kann man das übrigens direkt live ausprobieren:
http://dev.pistes-nordiques.org/offsete … T&offsets=
Dort werden live transparente Mapnik-Kacheln erzeugt und über die Karte gelegt, mit den Offsets, welche man dort eingestellt hat (Klick auf "--" zählt eins runter, "++" eins hoch).

Gruß,
Mondschein