Am 09.12.2014 um 13:17 schrieb Hubert: > Hallo, > > danke für die Antworten. > > Am Montag, 8. Dezember 2014 19:34 schrieb fly <[email protected]>: > > Ich habe zumindest path=sidewalk/crossing schon öfter verwendet. > > Reinen cycleways begegne ich äußerst selten. > > > > cu fly > > Ich kenne ein paar (eche/reine) Radwege, welche mit highway=cycleway getaggt > sind. Allerdings habe ich Bauchschmerzen, enge Bordsteinradwege mit > highway=cycleway + cycleway=sidewalk/crossing zu taggen. Das sieht dann doch > sehr seltsam aus, auch wenn es unter einem systematischen Gesichtspunkt > logisch wäre.
+1 highway=cycleway habe ich auch vor einiger Zeit schon bei straßenbegleitenden Radwegen benutzt, aber wie schon beschrieben: Es hat kaum Vorteile und ist kaum fehlerfrei möglich. > Die Einschätzung würde ich noch teilen. Allerdings kann sich das noch > änderen, oder es ändert sich gerade. Ich sehe sehr viele Gegenden, wo es kein > sidewalk=* an der Straße gibt, aber der Bürgersteig schon als highway=footway > eingetragen ist, allerdings ohne footway=sidewalk Mit Taginfo kann man folgende Zahlen ermitteln: Separat erfasst: footway=sidewalk 143 686 footway=crossing 86 541 An Straße erfassst: sidewalk=none 222 954 sidewalk=both 143 254 sidewalk=right 63 796 sidewalk=left 30 027 ... footway=both 12 357 ... Wenn man sich vor Augen führt, wie stark segmentiert das separate Erfassen ist, kann man footway=crossing auch weglassen und footway=sidewalk wenigstens halbieren, weil auf ein sidewalk=both etwa zwei highway=footway gerechnet werden müssen. Alle übrigen Wege, die nicht diese Tags haben, haben keine weitere Berücksichtigung verdient - weil sie falsch getaggt sind. Allerdings ist die Qualität der Beiträge, die ich gesehen habe, nicht ausreichend. Meistens fehlen Verbindungen zwischen Fahrbahn und straßenbegleitenden Wegen. Ich habe das an sehr vielen Stellen festgestellt. Es ist eben nicht einfach mal eben damit getan einen Weg einzuzeichnen und ihn richtig zu taggen. > > > In D ist es halt so, dass man als Fußgänger am Straßenrand (außerorts > > dann auch nur auf einem bestimmten), auf dem Bürgersteig oder auf > > einem straßenbegleitenden Gehweg gehen muss (bis auf Ausnahmen wie für > > die Mitführung von Sperrgut etc). Zum anderen müssen Kinder bis 8 > > Jahre auf dem Gehweg Radfahren. Rollstuhlfahrer haben nur mit > > Bordsteinkanten ein Problem und von Blinden scheint weder bekannt zu > > sein wie sie sich fortbewegen, noch was beim Routing wichtig für sie > > ist. > > > > Rollstuhlfahrer: Sollten kein Problem mit sidewalk=* haben, weil bei > > solch einem Tagging zu erwarten ist, dass man bei Kreuzungen, > > Hauseinfahrten etc einen entsprechend abgesenkten Bordstein vorfindet. > > Ansonsten wäre ein Beispiel schön. > > > > Blinde: Werden schon irgendwie den Bürgersteig finden, schließlich > > gibt es da ja auch noch andere Probleme wie Passanten, Pfeiler für > > Verkehrsschilder, Fahrradwege. > > Soweit ich das mal gehört habe, sind für Blinde POIs wie Parkbänke > > wichtig. > > > > Normale Fußgänger: Sind die Mehrheit und können mit entsprechendem > > Abstand zur Ampel nahezu überall Straßen überqueren. > > Soweit teile ich die Einschätzung. Allerdings ist mir das etwas zu sehr > Renderer/Router orientiert. Klar, das sind die beiden wichtigsten Nutzer der > Daten, aber die Erfassung sollte dann doch auf "höheren" Grundlagen > stattfinden. Aus meiner Sicht müsste ein Schema einen einfachen Zugang anbieten. Das tut es nicht. Es macht nur alles komplizierter und aufwändiger. Wenn man es an die Straße taggt ist das nicht so. > > Fahrradfahrer: Wenn man das weiter Spinnt, kommt man bei Radfahrern zu > > dem Problem, dass sie überwiegend auf beiden Seiten Einbahnstraßen > > vorfinden und beim Routing dann große Umwege genommen werden, bis man > > an eine Kreuzung zum Wenden kommt. > > Das hängt ganz vom Router ab. Oder vom Radfahren. Bei einem Borstein kann Ich > zwar vom Radweg auf die Straße wechseln, nicht aber von der Straße auf den > Radweg Ohne abzusteigen... Der gesamte Bereich müsste für Fußgänger zugänglich gemacht werden. So ein paar Einfahrten und Kreuzungen genügen da nicht. Man müsste den Straßenraum als Einheit, als gesamtes erfassen. Fußgänger dürften überall hin und würden nur noch von Barrieren aufgehalten - die dann zusätzlich erfasst werden müssen. Nicht, dass ich mir so etwas wünschen würde. > > IMHO ist es in Städten mit engen Straßen absurd Bürgersteige saparat > > zu erfassen. Dauernd parkt jemand wo er nicht darf den Radweg zu > > (Autos Fahrräder etc), Bürgersteige sind für Kinderwagen zu eng, weil > > Autos dort illegal parken (oder zwei Passanten passen nicht > > nebeneinander), Bordsteinkanten sind weder als abgesenkt noch als > > Normales Hindernis erkennbar usw. Also macht es bitte nicht zu > > kompliziert! > > Gab es nicht mal fälle wo Schiffe usw. eingezeichnet wurden? So ganz kann ich > der Argumentation nämlich nicht folgen. Soll man denn an den Stellen gar > keinen Gehweg eintragen? Auch nicht als sidewalk? > Auch lassen Bordsteinkanten sich allgemein (noch) nicht vom Sat Bild ablesen, > aber trotzdem wird das schon erfasst. Schiffe als Gebäude einzuzeichnen scheint ja laut Wiki OK zu sein - auch wenn ich das ein wenig zweifelhaft finde. ;) Vom Ansatz her ist es aus meiner Sicht zu detailliert, wenn man die Bordsteinkante als Anlass für einen eigenen Weg nimmt. Es wäre eleganter zu sagen, dass dort ein Bürgersteig ist (mit sidewalk=both). In der Praxis gibt es unvorhersehbare Probleme, die das Problem einer Bordsteinkante übertreffen (siehe oben). > > Renderer: Vielleicht ist ja schon einmal bei der opencyclemap.org > > aufgefallen, dass die Renderer prinzipiell ein Problem mit separaten > > Wegen haben. Bei niedrigen Zoomstufen wandern die separat > > eingezeichneten Radwege zur Mitte der Straße und sehen nicht > > professionell aus: > > https://osm.org/#map=14/53.0912/8.7965&layers=C > > Bei niedrigen Zoomstufen kann man dann ohne Luftbild oder Ortskenntnis > > einfach nicht mehr erkennen, ob zwischen Straße und Gehweg eine Hecke > > steht oder nicht - kann ich da gerade jemanden Absetzen? (Das ist auch > > das Niveau auf dem andere hier argumentieren). > > https://osm.org/#map=18/53.08995/8.78780&layers=C > > Das istein Renderer "Problem". Falls genügend Daten (Lübecker Schema + > *=sidewalk, o.ä) vorhanden sind, kann man das auch Zoomstufenabhängig machen. > http://radwegekarte.bplaced.net/?zoom=17&lat=54.09151&lon=12.15037&layers=B > (etwas langsam da freehost; experimentel) Die Karte finde ich gut. Allerdings ist das nicht was angestrebt ist und weitaus schlechter als würde man cycleway=* oder sidewalk=* benutzen. Auf höheren Zoomstufen erkennt man nur noch Radwege - keine Straßennamen oder überhaupt den Unterschied zwischen eigenständigen Wegen und Straßenbegleitenden. Als Radfahrer ist meist mehr als nur die Radfahranlage interessant. Was halt von den Mappern nicht erreicht wurde ist aus meiner Sicht, dass es zuverlässig ist. Wenn ich mir die OSM-Daten dazu in Rostock anschaue, sehe ich da direkt das Problem, dass eben nicht klar ist, ob ein Gehweg nun durch Bordstein oder tatsächlich von der Straße getrennt ist. Das kann man auch nicht durch irgendwelches Rendering wegbekommen. Da fehlen dann Tags - owbwohl es schon so viele sind - und Wege. Und dann wird man beim Routen mit simplen Algorithmen nicht mehr weit kommen. Man _muss_ sehr komplexe Algorithmen benutzen. U. a. weil Mapper Wege auch nicht mehr mit der Fahrbahn verbinden werden (weil sie es nicht wissen oder vergessen). BTW: Gibt es inzwischen Router, die über Flächen Routen? > > > Analog zu den turn:lanes, lanes usw. Sollte es auch bei Bürgersteigen > > und Radwegen gemacht werden. Bei motorisierten Fahrzeugen scheint das > > mit baulicher Trennung ja wohl auch relativ verständlich zu sein. > > Meinst du, dass man Rad/Fußwege mit in das :lanes Schema integriert? Damit meine ich sidewalk=* und cycleway=*. Bordsteine sind dann übliche, zu erwartende Hindernisse. _______________________________________________ Talk-de mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-de
