Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am Montag, 22. Dezember 2014, 13:28:16 schrieb huey212: Hallo, folgende Gedanken: ich mappe sehr viel Radverkehrspezifisches. Da stellt sich mir die Frage, was haben Radwege und (Auto-)Fahrbahnen gemeinsam? -ggf. einen Bordstein, -grob den gleichen Verlauf, -den gleichen Straßennamen, -die gleiche Beleuchtung Was ist unterschiedlich? -Der Verlauf im Detail -Fahrbahnbelag, -Nutzungsvorgaben (access) -Einbahnstraßenregelungen (Fast alle straßenbegleitenden innerstädtischen Radwege in Deutschland sind Einbahnstraßen! Fußwege hingegen nicht.) -Spuraufteilung -Abbiegebeschränkungen Ich halte das Anbringen von Fuß- und Radweginformation an der Hauptfahrbahn nur bei relativ grobem Mapping für sinnvoll. Sobald es in die Details geht sollte die Wege als einzelne Linienzüge erfasst werden. Alles andere wird unübersichtlich und ist nicht mehr editierbar (weil zu kompliziert). Von einer sinnvollen Auswertung reden wir mal noch gar nicht. Die sinnvolle Auswertung besteht meistens aus einer Karte oder einem Router. Die Karte hat, wenn gedruckt oder sonstwie als Übersicht genutzt, einen Maßstab, in dem die Symbole von Fahrbahn und Radweg sich gegenseitig verdecken. Man kann zwar im Web weiter hineinzoomen, einen Nutzen hätte das aber nur für eine Art Straßenkataster, das wir ohnehin nicht leisten können. Der Router braucht verbundene Wege, um alle Abbiegemöglichkeiten nutzen zu können. Das wird häufig ausgelassen, wenn nur auf der Gegenseite ein Weg abzweigt. Die Zuordnung des Radweges zu einer bestimmten Straße ergibt sich im innerstätischen Bereich aus der reinen Lage nicht immer. Daher meine ich, dass der Radweg, wenn er keine erheblich andere Streckenführung als die Straße selbst hat, an sie getaggt werden sollte. Das eigenständige Einzeichnen hat in hohen Zoomstufen einen optisch schönen Effekt, besonders im Zusammenwirken mit dem Luftbild, ist aber für die meisten Auswertungen eher hinderlich. Als Ausweg bliebe noch, den straßenbegleitenden Radweg, wenn man es denn unbedingt möchte (und solange es überhaupt noch so etwas gibt), sowohl als tag als auch als eigenständigen Weg einzuzeichnen und dem Auswerter über eine Relation (street) oder über ein Tag (?) mitzuteilen, dass er sich hier die für ihn günstigere Variante aussuchen kann. Übrigens gilt für den straßenbegleitenden Fußweg sinngemäß das Gleiche. Wenn der Radweg unbedingt ein eigenständiger Weg sein soll, müsste der Fußweg analog ebenfalls eigenständig eingezeichnet werden. Die Argumente sind letztlich die Gleichen, mit allen Vor- und Nachteilen. Ob aber 5 Linienzüge im Verlauf einer Straße übersichtlicher als ein einzelner sind, muss wohl jeder Mapper für sich selbst entscheiden. Einen guten Editor (mit gutem css-Stil) vorausgesetzt, dürfte das Modell mit den Tags übersichtlicher darstellbar sein als das Modell mit den separaten Wegen. Dann erscheinen die Rad- und Fußwege optisch am Außenrand der Straße. Was bleibt, sind die längeren tags, dafür aber alle an einem Way zusammengefasst und nicht an 5 Ways verteilt. Auch hier kann ein guter Editor viel Übersicht schaffen. Wenn wirklich die Straße genau abgemalt werden soll, halte ich eine zusätzliche Flächenerfassung für sinnvoller. Letztlich ist das die einzige Möglichkeit, in hohen Zoomstufen (und nur dort) die Straße mit allen Einzelheiten abzubilden. Auch dann bleibt aber die Frage, wer das eigentlich braucht, außer als schöne Ansicht. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Moin, Am 30.12.2014 um 14:12 schrieb Wolfgang Hinsch: Die sinnvolle Auswertung besteht meistens aus einer Karte oder einem Router. Die Karte hat, wenn gedruckt oder sonstwie als Übersicht genutzt, einen Maßstab, in dem die Symbole von Fahrbahn und Radweg sich gegenseitig verdecken. Man kann zwar im Web weiter hineinzoomen, einen Nutzen hätte das aber nur für eine Art Straßenkataster, das wir ohnehin nicht leisten können. Der Router braucht verbundene Wege, um alle Abbiegemöglichkeiten nutzen zu können. Das wird häufig ausgelassen, wenn nur auf der Gegenseite ein Weg abzweigt. Die Zuordnung des Radweges zu einer bestimmten Straße ergibt sich im innerstätischen Bereich aus der reinen Lage nicht immer. Daher meine ich, dass der Radweg, wenn er keine erheblich andere Streckenführung als die Straße selbst hat, an sie getaggt werden sollte. Das eigenständige Einzeichnen hat in hohen Zoomstufen einen optisch schönen Effekt, besonders im Zusammenwirken mit dem Luftbild, ist aber für die meisten Auswertungen eher hinderlich. Als Ausweg bliebe noch, den straßenbegleitenden Radweg, wenn man es denn unbedingt möchte (und solange es überhaupt noch so etwas gibt), sowohl als tag als auch als eigenständigen Weg einzuzeichnen und dem Auswerter über eine Relation (street) oder über ein Tag (?) mitzuteilen, dass er sich hier die für ihn günstigere Variante aussuchen kann. Übrigens gilt für den straßenbegleitenden Fußweg sinngemäß das Gleiche. Wenn der Radweg unbedingt ein eigenständiger Weg sein soll, müsste der Fußweg analog ebenfalls eigenständig eingezeichnet werden. Die Argumente sind letztlich die Gleichen, mit allen Vor- und Nachteilen. Ob aber 5 Linienzüge im Verlauf einer Straße übersichtlicher als ein einzelner sind, muss wohl jeder Mapper für sich selbst entscheiden. Einen guten Editor (mit gutem css-Stil) vorausgesetzt, dürfte das Modell mit den Tags übersichtlicher darstellbar sein als das Modell mit den separaten Wegen. Dann erscheinen die Rad- und Fußwege optisch am Außenrand der Straße. Was bleibt, sind die längeren tags, dafür aber alle an einem Way zusammengefasst und nicht an 5 Ways verteilt. Auch hier kann ein guter Editor viel Übersicht schaffen. Wenn wirklich die Straße genau abgemalt werden soll, halte ich eine zusätzliche Flächenerfassung für sinnvoller. Letztlich ist das die einzige Möglichkeit, in hohen Zoomstufen (und nur dort) die Straße mit allen Einzelheiten abzubilden. Auch dann bleibt aber die Frage, wer das eigentlich braucht, außer als schöne Ansicht. +1000 LG Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am 23. Dezember 2014 02:24 schrieb 715371 osmu715...@gmx.de: Für einen Renderer kann es zu Beispiel auch interressant sein, wenn er denn benutzungspflichtige und nicht benutzungspflichtige Radwege unterscheiden möchte. Aber einen eigenen Tag dafür kenne ich auch nicht, nur die Versuche indierekt über bicycle=use_sidepath oder durch die Unterscheidung von bicycle=official/designated und bicycle=yes. Ein eigener Wert (z.B. bicycle=mandatory/obligatorry o.ä.) schein wohl überfällig, aber das ist ein anderes Thema. +1 Die Info ruft dann zwar nicht mehr Fehler hervor, wenn sie fehlt, aber ist natürlich immer noch interessant. bicycle=mandatory/obligatorry wäre in dem Kontext zumindest ein Tagging über das ich noch nicht nachgedacht habe. Problem ist vielleicht, dass es alleine am Radweg keine access- Bedeutung hat/haben könnte. Stimmt. Ich habe da die Vorstellung das mandatory (official) designated und yes implizieren würde Das hängt davon ab, was man als Problem identifiziert. Für mich ist es das beide Modelle (an die Straße taggen, eigener Weg) sinnvoll sind. Daher wird wohl schon deit 2011 () darüber gestritten ws denn nun besser ist. Ende offen wie man sieht. Und dazwischen sind auch alle Meinungen möglich. Wie so oft. *zwinker* Hast du die Hauptprobleme, die seitdem diskutiert wurden irgendwo dokumentiert? Oder weißt du, ob es so etwas gibt? Wenn sich diese Diskussion immer wieder wiederholt, ist das auch nicht sehr produktiv. Eure/Unsere Meinungen und Vorschläge würde ich sonst gerne einmal zusammenfassen. Ich hab noch eine Email mit zwei Links hinterhergeschickt, die ist wohl irgentwo falsch abgebogen. Eine direkte Zusammenfassung habe ich noch nicht, aber ersteinmal die beiden Links: wiki.osm.org/wiki/DE_talk:Bicycle/Radverkehrsanlagen_kartieren - Behauptungen, die diese Seite aufstellt -Punkt 4 http://wiki.openstreetmap.org/wiki/Talk:Sidewalks - Separated from the road by some form of barrier? Falls ich noch mehr finde lasse ich sie Dir zukommen. Hast du da mal ein Beispiel, wie das gehen soll, mit OsmAnd, Maperitive und Tilemill sehe ich da keine Chance das hinzubekommen. Und das Problem des separaten/doppelten mappens entsteht bei Radwegen ja maximl bei cycleway=track/opposite_track. =lane wird ja unbestritten (glaub ich) an die Straße gemappt. Ich musste jetzt auch lange nachdenken, was ich damit sagen wollte, entschuldige! Ich habe in diesem Zusammenhang beim Rendern irgendein weiteres Problem vermutet. Passiert mir auch oft, oder ich vertue mich mit den Absätzen und Frage und Antworte auf passen nicht mehr zusammen. Weil es dabei auch noch auf die Seite ankommen könnte, wäre vielleicht ein ganz anderer Tag als bisher vorgeschlagen besser. Z.B. separate_cycletrack=left/right/both und analog das für footway separate_sidewalk=left/right/both Das ist zwar auch möglich, allerdings sehe ich da das Problem, dass man sich wieder zwischen Straße und Gehweg entscheiden muss. Ich werde es aber trotzdem mal mit zu den Variationen aufnehmen. Stimmt. Wenn es zusammen an einem Weg erfasst ist, wären die Tags nicht mehr so schön. Man müsste dann beides taggen. Da findet sich hoffentlich ein vernünfiter Kompromiss. Gruß Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Hallo, folgende Gedanken: ich mappe sehr viel Radverkehrspezifisches. Da stellt sich mir die Frage, was haben Radwege und (Auto-)Fahrbahnen gemeinsam? -ggf. einen Bordstein, -grob den gleichen Verlauf, -den gleichen Straßennamen, -die gleiche Beleuchtung Was ist unterschiedlich? -Der Verlauf im Detail -Fahrbahnbelag, -Nutzungsvorgaben (access) -Einbahnstraßenregelungen (Fast alle straßenbegleitenden innerstädtischen Radwege in Deutschland sind Einbahnstraßen! Fußwege hingegen nicht.) -Spuraufteilung -Abbiegebeschränkungen Ich halte das Anbringen von Fuß- und Radweginformation an der Hauptfahrbahn nur bei relativ grobem Mapping für sinnvoll. Sobald es in die Details geht sollte die Wege als einzelne Linienzüge erfasst werden. Alles andere wird unübersichtlich und ist nicht mehr editierbar (weil zu kompliziert). Von einer sinnvollen Auswertung reden wir mal noch gar nicht. Viele Grüße Hadhuey Am 20.12.2014 um 03:03 schrieb 715371: Am 09.12.2014 um 13:17 schrieb Hubert: 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. Mir fehlt hier noch die Diskussion weshalb man nun etwas separat erfassen sollte bzw. nicht. Ein Bordstein ist zwar eine bauliche Trennung, aber man kann sie erwarten und stellt für Radfahrer kein Hindernis dar, wenn an den zu erwartenden Stellen (z.B. Mündungen von anderen Straßen) die Bordsteine abgesenkt sind. Oder das zumindest so vorkommt, so dass man die straßenbegleitenden Wege ohne Komplikationen befahren kann. Bei Rollstuhlfahrern mag das anders aussehen. Ich finde aber, dass man (in D-Land) eher als default annehmen sollte, dass alles Rollstuhlfahrergerecht ist und Rollstuhlfahrer an z.B. einer Kreuzung oder Einmündung alles machen können. Wenn das nicht der Fall sein sollte, sollte man sich nach einem Tagging umschauen oder ggf. eine Relation einführen, die der restriction-Relation ähnelt. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am 21.12.2014 um 15:20 schrieb Hubert: Hallo, Am Samstag, 20. Dezember 2014 02:44 schrieb 715371 osmu715...@gmx.de: Das muss der Mapper Vor Ort entscheiden. Mir hilft immer die Frage, ob es von der Rennleitung Ärger geben würde, wenn man dort auf der Straße fährt/geht, Benutzungspflicht vorrausgesetzt. Die Benutzungspflicht ist ja nur bei separatem highway relevant. Wenn man cycleway=* benutzt hat Benutzungspflicht eine deutlich geringere Bedeutung (es gibt noch nicht einmal einen Tag dafür - soweit mir bekannt). Für einen Renderer kann es zu Beispiel auch interressant sein, wenn er denn benutzungspflichtige und nicht benutzungspflichtige Radwege unterscheiden möchte. Aber einen eigenen Tag dafür kenne ich auch nicht, nur die Versuche indierekt über bicycle=use_sidepath oder durch die Unterscheidung von bicycle=official/designated und bicycle=yes. Ein eigener Wert (z.B. bicycle=mandatory/obligatorry o.ä.) schein wohl überfällig, aber das ist ein anderes Thema. +1 Die Info ruft dann zwar nicht mehr Fehler hervor, wenn sie fehlt, aber ist natürlich immer noch interessant. bicycle=mandatory/obligatorry wäre in dem Kontext zumindest ein Tagging über das ich noch nicht nachgedacht habe. Problem ist vielleicht, dass es alleine am Radweg keine access-Bedeutung hat/haben könnte. Daher ist es aus meiner Sicht schwer die beiden Modelle miteinander zu vereinen, auch wenn ich gerade das an Huberts Ansatz gut finde. Ich finde genau in solchen Fällen hätte das doppelte Erfassen seine Stärke. Na ja. Das problem, das hier gelöst wird entsteht doch nur durch das doppelte Erfassen. Das hängt davon ab, was man als Problem identifiziert. Für mich ist es das beide Modelle (an die Straße taggen, eigener Weg) sinnvoll sind. Daher wird wohl schon deit 2011 () darüber gestritten ws denn nun besser ist. Ende offen wie man sieht. Und dazwischen sind auch alle Meinungen möglich. Hast du die Hauptprobleme, die seitdem diskutiert wurden irgendwo dokumentiert? Oder weißt du, ob es so etwas gibt? Wenn sich diese Diskussion immer wieder wiederholt, ist das auch nicht sehr produktiv. Eure/Unsere Meinungen und Vorschläge würde ich sonst gerne einmal zusammenfassen. Im Moment sieht es ja (auf der Hauptkarte) so aus, als würde auch der Gehweg dort aufhören und an der Straße ist ein sidewalk=* auch noch nicht gemappt. Es ging mir um das Problem. Wenn ich es heute noch einmal machen würde, dann würde ich den anschließenden Radweg nicht separat erfassen, weil es dafür keinen Grund gibt, und dann den Radweg an der Straße enden lassen. Dann stellt sich aber die Frage aber wann ein cycleway=track oder sidewalk=* nicht mehr an die Straßé getagged wird. Bordstein? Rasenfläche? Graben? Geländer? Graben, Rasenfläche - Trennung Bordstein, Geländer ist diskutabel, weil es eher auf die Situation ankommt. Am Donnerstag, 18. Dezember 2014 18:52 schrieb Martin Koppenhoefer dieterdre...@gmail.com: da finde ich cycleway/sidewalk=separate_way oder ähnliches besser. jein, ich wäre eher für eine Relation, dann ist die Zusammengehörigkeit eindeutig. separate_way hat das Problem, dass man erstens auch nicht genau weiss, welcher way, und zweitens bezieht man sich mit einem tag auf einen anderen way, den es zu einem späteren Zeitpunkt vielleicht schon gar nicht mehr gibt. Zwar könnte man fordern, wer den Gehweg verändert muss halt auch noch die Straße anschauen (und auch wenn das im Prinzip schon genau das Problem ist, so kann man es für Straßen vielleicht noch tolerieren), aber wenn man sowas erstmal eingeführt hat (tags die sich auf andere in der Nähe liegende, nicht genau spezifizierte/verlinkte Objekte beziehen), dann verbreitet sich das Prinzip vermutlich noch weiter auf andere Arten von Objekten. Das ist ein bisschen so ähnlich wie forward-Angaben auf einem Node. Ein Problem mit Relationen sehe ich auch darin, das Straßen mit z.B sidewalk=* und Zugehörigkeit zu einer (street-)Realtion nicht unbedingt auch einen seperat eingezeichneten Gehweg haben müssen. D.h. ein Datenauswerter müsste erst nachsehen ob die (street-) Relation zu der die Straße gehört und dann ob in der Relation auch noch ein Mitglied ist, welches ein Gehweg ist. Das klingt für mich kompliziert bis unmöglich. Und wenn er dann nachgeschaut hat, entscheidet er ob z.B. cycleway=lane oder sidewalk=right an dieser Stelle nun gerendert wird. Hast du da mal ein Beispiel, wie das gehen soll, mit OsmAnd, Maperitive und Tilemill sehe ich da keine Chance das hinzubekommen. Und das Problem des separaten/doppelten mappens entsteht bei Radwegen ja maximl bei cycleway=track/opposite_track. =lane wird ja unbestritten (glaub ich) an die Straße gemappt. Ich musste jetzt auch lange nachdenken, was ich damit sagen wollte, entschuldige! Ich habe in diesem Zusammenhang beim Rendern irgendein weiteres Problem vermutet. Weil es dabei auch noch auf die Seite ankommen könnte, wäre vielleicht ein
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Hallo, Am Samstag, 20. Dezember 2014 02:44 schrieb 715371 osmu715...@gmx.de: Das muss der Mapper Vor Ort entscheiden. Mir hilft immer die Frage, ob es von der Rennleitung Ärger geben würde, wenn man dort auf der Straße fährt/geht, Benutzungspflicht vorrausgesetzt. Die Benutzungspflicht ist ja nur bei separatem highway relevant. Wenn man cycleway=* benutzt hat Benutzungspflicht eine deutlich geringere Bedeutung (es gibt noch nicht einmal einen Tag dafür - soweit mir bekannt). Für einen Renderer kann es zu Beispiel auch interressant sein, wenn er denn benutzungspflichtige und nicht benutzungspflichtige Radwege unterscheiden möchte. Aber einen eigenen Tag dafür kenne ich auch nicht, nur die Versuche indierekt über bicycle=use_sidepath oder durch die Unterscheidung von bicycle=official/designated und bicycle=yes. Ein eigener Wert (z.B. bicycle=mandatory/obligatorry o.ä.) schein wohl überfällig, aber das ist ein anderes Thema. Daher ist es aus meiner Sicht schwer die beiden Modelle miteinander zu vereinen, auch wenn ich gerade das an Huberts Ansatz gut finde. Ich finde genau in solchen Fällen hätte das doppelte Erfassen seine Stärke. Na ja. Das problem, das hier gelöst wird entsteht doch nur durch das doppelte Erfassen. Das hängt davon ab, was man als Problem identifiziert. Für mich ist es das beide Modelle (an die Straße taggen, eigener Weg) sinnvoll sind. Daher wird wohl schon deit 2011 () darüber gestritten ws denn nun besser ist. Ende offen wie man sieht. Im Moment sieht es ja (auf der Hauptkarte) so aus, als würde auch der Gehweg dort aufhören und an der Straße ist ein sidewalk=* auch noch nicht gemappt. Es ging mir um das Problem. Wenn ich es heute noch einmal machen würde, dann würde ich den anschließenden Radweg nicht separat erfassen, weil es dafür keinen Grund gibt, und dann den Radweg an der Straße enden lassen. Dann stellt sich aber die Frage aber wann ein cycleway=track oder sidewalk=* nicht mehr an die Straßé getagged wird. Bordstein? Rasenfläche? Graben? Geländer? Am Donnerstag, 18. Dezember 2014 18:42 schrieb fly lowfligh...@googlemail.com: da finde ich cycleway/sidewalk=separate_way oder ähnliches besser. Ich glaube, so arbeitet das Lübecker Schema bei seperat gemappten Radwegen. Dort wird aus dem cycleway=track dann ein cycleway=sidepath. Das ist zwar ein gangbarer Weg, hat für mich aber dann einen Nachgeschmack, wenn das gemacht wird, um das Einzeichnen von doppelten Linien (auf opencyclemap.org) zu verhindern. Wenn es allerding gemacht wird, da es sich aus einem höherem Schema so ergibt, dann ist es (auf einmal) Ok. Ich halte beides für nicht so gelungen. cycleway=* ist für mich ein Key mit dem man die Fahrradinfrastruktur an der Straße erfasst und würde es so verstehen, dass es zwei Radwege dort gibt, wenn es an der Straße einen cycleway=* gibt und daneben noch einen highway=path/cycleway/(footway). Daher sollte man IMHO für so etwas etwas anderes verwenden. Was in dem Kontext halt auch ungünstig ist: Die Bedeutung von footway=* ist nicht analog zu cycleway=*. cycleway eine weitere Bedeutung zu geben, macht es nicht einfacher. Ja, dass stimmt. Aber vieleicht kann man das auch wieder vereinheitlichen. Am Donnerstag, 18. Dezember 2014 18:52 schrieb Martin Koppenhoefer dieterdre...@gmail.com: da finde ich cycleway/sidewalk=separate_way oder ähnliches besser. jein, ich wäre eher für eine Relation, dann ist die Zusammengehörigkeit eindeutig. separate_way hat das Problem, dass man erstens auch nicht genau weiss, welcher way, und zweitens bezieht man sich mit einem tag auf einen anderen way, den es zu einem späteren Zeitpunkt vielleicht schon gar nicht mehr gibt. Zwar könnte man fordern, wer den Gehweg verändert muss halt auch noch die Straße anschauen (und auch wenn das im Prinzip schon genau das Problem ist, so kann man es für Straßen vielleicht noch tolerieren), aber wenn man sowas erstmal eingeführt hat (tags die sich auf andere in der Nähe liegende, nicht genau spezifizierte/verlinkte Objekte beziehen), dann verbreitet sich das Prinzip vermutlich noch weiter auf andere Arten von Objekten. Das ist ein bisschen so ähnlich wie forward-Angaben auf einem Node. Ein Problem mit Relationen sehe ich auch darin, das Straßen mit z.B sidewalk=* und Zugehörigkeit zu einer (street-)Realtion nicht unbedingt auch einen seperat eingezeichneten Gehweg haben müssen. D.h. ein Datenauswerter müsste erst nachsehen ob die (street-) Relation zu der die Straße gehört und dann ob in der Relation auch noch ein Mitglied ist, welches ein Gehweg ist. Das klingt für mich kompliziert bis unmöglich. Und wenn er dann nachgeschaut hat, entscheidet er ob z.B. cycleway=lane oder sidewalk=right an dieser Stelle nun gerendert wird. Hast du da mal ein Beispiel, wie das gehen soll, mit OsmAnd, Maperitive und Tilemill sehe ich da keine Chance das hinzubekommen. Und das Problem
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Hab doch glatt die Links vergessen, die ich noch einfügen wollte: Seit 2011: wiki.osm.org/wiki/DE_talk:Bicycle/Radverkehrsanlagen_kartieren - Behauptungen, die diese Seite aufstellt -Punkt 4 http://wiki.openstreetmap.org/wiki/Talk:Sidewalks - Separated from the road by some form of barrier? ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Hallo. Das ist etwas, dass ich eigentlich als zweitrangig erachtet. Beides hat Vor und Nachteile. Separates Erfassen hat den Vorteil, das man auf hohen Zoomstufen (z.b. Zoom 18+) eine genaueren Verlauf darstellen kann, der ein genaueres Routing möglich ist (z.b. komplizierte Kreuzungen) Das taggen an die Straße hat die Vorteile, das das erzeugt Kartenbild übersichtlicher erscheint und es macht das Routing einfacher. Darum geht es mir aber nicht. Ich habe für mich festgestellt, dass beide Versionen getagged werden und möchte eine Möglichkeit ausloten, welche die dadurch entstehenden Konflikte minimiert. Gruß Hubert Am 20. Dezember 2014 03:03:28 MEZ, schrieb 715371 osmu715...@gmx.de: Am 09.12.2014 um 13:17 schrieb Hubert: 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. Mir fehlt hier noch die Diskussion weshalb man nun etwas separat erfassen sollte bzw. nicht. Ein Bordstein ist zwar eine bauliche Trennung, aber man kann sie erwarten und stellt für Radfahrer kein Hindernis dar, wenn an den zu erwartenden Stellen (z.B. Mündungen von anderen Straßen) die Bordsteine abgesenkt sind. Oder das zumindest so vorkommt, so dass man die straßenbegleitenden Wege ohne Komplikationen befahren kann. Bei Rollstuhlfahrern mag das anders aussehen. Ich finde aber, dass man (in D-Land) eher als default annehmen sollte, dass alles Rollstuhlfahrergerecht ist und Rollstuhlfahrer an z.B. einer Kreuzung oder Einmündung alles machen können. Wenn das nicht der Fall sein sollte, sollte man sich nach einem Tagging umschauen oder ggf. eine Relation einführen, die der restriction-Relation ähnelt. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Hallo, ich habe einmal auf meiner Wiki Seite (https://wiki.openstreetmap.org/wiki/User:Hubert87/DoubleRepresentation) ein paar mögliche Kombinationen niedergeschrieben. Ich bitte um viel Feedback auf der entsprechenden Diskussionsseite. Außerdem: Am Donnerstag, 18. Dezember 2014 02:27 schrieb osmu715...@gmx.de: Was dann aber noch fies bleibt, sind solche Wege die erst straßenbegleitend sind und dann nicht mehr (weil deutlich zu weit weg). https://www.openstreetmap.org/way/202894636 Ja, solche Dinge sind wirklich schwierig zu entscheiden. Das muss der Mapper Vor Ort entscheiden. Mir hilft immer die Frage, ob es von der Rennleitung Ärger geben würde, wenn man dort auf der Straße fährt/geht, Benutzungspflicht vorrausgesetzt. Daher ist es aus meiner Sicht schwer die beiden Modelle miteinander zu vereinen, auch wenn ich gerade das an Huberts Ansatz gut finde. Ich finde genau in solchen Fällen hätte das doppelte Erfassen seine Stärke. Im Moment sieht es ja (auf der Hauptkarte) so aus, als würde auch der Gehweg dort aufhören und an der Straße ist ein sidewalk=* auch noch nicht gemappt. Am Donnerstag, 18. Dezember 2014 18:42 schrieb fly lowfligh...@googlemail.com: da finde ich cycleway/sidewalk=separate_way oder ähnliches besser. Ich glaube, so arbeitet das Lübecker Schema bei seperat gemappten Radwegen. Dort wird aus dem cycleway=track dann ein cycleway=sidepath. Das ist zwar ein gangbarer Weg, hat für mich aber dann einen Nachgeschmack, wenn das gemacht wird, um das Einzeichnen von doppelten Linien (auf opencyclemap.org) zu verhindern. Wenn es allerding gemacht wird, da es sich aus einem höherem Schema so ergibt, dann ist es (auf einmal) Ok. Am Donnerstag, 18. Dezember 2014 18:52 schrieb Martin Koppenhoefer dieterdre...@gmail.com: da finde ich cycleway/sidewalk=separate_way oder ähnliches besser. jein, ich wäre eher für eine Relation, dann ist die Zusammengehörigkeit eindeutig. separate_way hat das Problem, dass man erstens auch nicht genau weiss, welcher way, und zweitens bezieht man sich mit einem tag auf einen anderen way, den es zu einem späteren Zeitpunkt vielleicht schon gar nicht mehr gibt. Zwar könnte man fordern, wer den Gehweg verändert muss halt auch noch die Straße anschauen (und auch wenn das im Prinzip schon genau das Problem ist, so kann man es für Straßen vielleicht noch tolerieren), aber wenn man sowas erstmal eingeführt hat (tags die sich auf andere in der Nähe liegende, nicht genau spezifizierte/verlinkte Objekte beziehen), dann verbreitet sich das Prinzip vermutlich noch weiter auf andere Arten von Objekten. Das ist ein bisschen so ähnlich wie forward-Angaben auf einem Node. Ein Problem mit Relationen sehe ich auch darin, das Straßen mit z.B sidewalk=* und Zugehörigkeit zu einer (street-)Realtion nicht unbedingt auch einen seperat eingezeichneten Gehweg haben müssen. D.h. ein Datenauswerter müsste erst nachsehen ob die (street-)Relation zu der die Straße gehört und dann ob in der Relation auch noch ein Mitglied ist, welches ein Gehweg ist. Das klingt für mich kompliziert bis unmöglich. Gruß Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am 19.12.2014 um 23:58 schrieb Hubert: Hallo, ich habe einmal auf meiner Wiki Seite (https://wiki.openstreetmap.org/wiki/User:Hubert87/DoubleRepresentation) ein paar mögliche Kombinationen niedergeschrieben. Ich bitte um viel Feedback auf der entsprechenden Diskussionsseite. Außerdem: Am Donnerstag, 18. Dezember 2014 02:27 schrieb osmu715...@gmx.de: Was dann aber noch fies bleibt, sind solche Wege die erst straßenbegleitend sind und dann nicht mehr (weil deutlich zu weit weg). https://www.openstreetmap.org/way/202894636 Ja, solche Dinge sind wirklich schwierig zu entscheiden. Das muss der Mapper Vor Ort entscheiden. Mir hilft immer die Frage, ob es von der Rennleitung Ärger geben würde, wenn man dort auf der Straße fährt/geht, Benutzungspflicht vorrausgesetzt. Die Benutzungspflicht ist ja nur bei separatem highway relevant. Wenn man cycleway=* benutzt hat Benutzungspflicht eine deutlich geringere Bedeutung (es gibt noch nicht einmal einen Tag dafür - soweit mir bekannt). Daher ist es aus meiner Sicht schwer die beiden Modelle miteinander zu vereinen, auch wenn ich gerade das an Huberts Ansatz gut finde. Ich finde genau in solchen Fällen hätte das doppelte Erfassen seine Stärke. Na ja. Das problem, das hier gelöst wird entsteht doch nur durch das doppelte Erfassen. Im Moment sieht es ja (auf der Hauptkarte) so aus, als würde auch der Gehweg dort aufhören und an der Straße ist ein sidewalk=* auch noch nicht gemappt. Es ging mir um das Problem. Wenn ich es heute noch einmal machen würde, dann würde ich den anschließenden Radweg nicht separat erfassen, weil es dafür keinen Grund gibt, und dann den Radweg an der Straße enden lassen. Am Donnerstag, 18. Dezember 2014 18:42 schrieb fly lowfligh...@googlemail.com: da finde ich cycleway/sidewalk=separate_way oder ähnliches besser. Ich glaube, so arbeitet das Lübecker Schema bei seperat gemappten Radwegen. Dort wird aus dem cycleway=track dann ein cycleway=sidepath. Das ist zwar ein gangbarer Weg, hat für mich aber dann einen Nachgeschmack, wenn das gemacht wird, um das Einzeichnen von doppelten Linien (auf opencyclemap.org) zu verhindern. Wenn es allerding gemacht wird, da es sich aus einem höherem Schema so ergibt, dann ist es (auf einmal) Ok. Ich halte beides für nicht so gelungen. cycleway=* ist für mich ein Key mit dem man die Fahrradinfrastruktur an der Straße erfasst und würde es so verstehen, dass es zwei Radwege dort gibt, wenn es an der Straße einen cycleway=* gibt und daneben noch einen highway=path/cycleway/(footway). Daher sollte man IMHO für so etwas etwas anderes verwenden. Was in dem Kontext halt auch ungünstig ist: Die Bedeutung von footway=* ist nicht analog zu cycleway=*. cycleway eine weitere Bedeutung zu geben, macht es nicht einfacher. Am Donnerstag, 18. Dezember 2014 18:52 schrieb Martin Koppenhoefer dieterdre...@gmail.com: da finde ich cycleway/sidewalk=separate_way oder ähnliches besser. jein, ich wäre eher für eine Relation, dann ist die Zusammengehörigkeit eindeutig. separate_way hat das Problem, dass man erstens auch nicht genau weiss, welcher way, und zweitens bezieht man sich mit einem tag auf einen anderen way, den es zu einem späteren Zeitpunkt vielleicht schon gar nicht mehr gibt. Zwar könnte man fordern, wer den Gehweg verändert muss halt auch noch die Straße anschauen (und auch wenn das im Prinzip schon genau das Problem ist, so kann man es für Straßen vielleicht noch tolerieren), aber wenn man sowas erstmal eingeführt hat (tags die sich auf andere in der Nähe liegende, nicht genau spezifizierte/verlinkte Objekte beziehen), dann verbreitet sich das Prinzip vermutlich noch weiter auf andere Arten von Objekten. Das ist ein bisschen so ähnlich wie forward-Angaben auf einem Node. Ein Problem mit Relationen sehe ich auch darin, das Straßen mit z.B sidewalk=* und Zugehörigkeit zu einer (street-)Realtion nicht unbedingt auch einen seperat eingezeichneten Gehweg haben müssen. D.h. ein Datenauswerter müsste erst nachsehen ob die (street-)Relation zu der die Straße gehört und dann ob in der Relation auch noch ein Mitglied ist, welches ein Gehweg ist. Das klingt für mich kompliziert bis unmöglich. Und wenn er dann nachgeschaut hat, entscheidet er ob z.B. cycleway=lane oder sidewalk=right an dieser Stelle nun gerendert wird. Weil es dabei auch noch auf die Seite ankommen könnte, wäre vielleicht ein ganz anderer Tag als bisher vorgeschlagen besser. Z.B. separate_cycletrack=left/right/both und analog das für footway separate_sidewalk=left/right/both ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am 09.12.2014 um 13:17 schrieb Hubert: 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. Mir fehlt hier noch die Diskussion weshalb man nun etwas separat erfassen sollte bzw. nicht. Ein Bordstein ist zwar eine bauliche Trennung, aber man kann sie erwarten und stellt für Radfahrer kein Hindernis dar, wenn an den zu erwartenden Stellen (z.B. Mündungen von anderen Straßen) die Bordsteine abgesenkt sind. Oder das zumindest so vorkommt, so dass man die straßenbegleitenden Wege ohne Komplikationen befahren kann. Bei Rollstuhlfahrern mag das anders aussehen. Ich finde aber, dass man (in D-Land) eher als default annehmen sollte, dass alles Rollstuhlfahrergerecht ist und Rollstuhlfahrer an z.B. einer Kreuzung oder Einmündung alles machen können. Wenn das nicht der Fall sein sollte, sollte man sich nach einem Tagging umschauen oder ggf. eine Relation einführen, die der restriction-Relation ähnelt. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am 17. Dezember 2014 um 22:26 schrieb 715371 osmu715...@gmx.de: Aber ich denke, dass man es mit dem Taggen an die Straße auch probieren kann: Wenn man einen nicht abgesenkten Bürgersteig auf der rechten Seite hat und von der linken Seite eine Straße mündet. Könnte man entweder durch Tags ergänzend zum Bürgersteig sagen, dass der Bordstein auf dem Stück auf der rechten Seite nicht abgesenkt ist. Der Algorithmus nimmt dann die Kante und sagt, wenn der Wert bis zum Abbiegen da ist, kann man den Bürgersteig mit entsprechenden Verkehrmitteln (z.B. Rollstuhl) nicht benutzen. wenn man solche Details wie abgesenkte Bordsteine und sich verjüngende Gehwege mappt, dann wäre ich tendenziell für die getrennte Erfassung des Gehwegs, weil man sonst die Straße (den Haupt-highway-way) extrem oft aufsplitten muss, und das wenig nachhaltig ist für die weitere Bearbeitung durch folgende Mapper. Technisch gesehen würde würde beides gehen. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am 18. Dezember 2014 um 01:35 schrieb Hubert sg.fo...@gmx.de: Wenn es ums Flächenmappen (von Wegen/Straßen) geht, dann würde ich auf jeden Fall Gehweg und Straße getrennt erfassen. Interressanter Punkt, falls du dich dabei auf das area:highway=* beziehen solltest, meine ich mich zu erinnern, dass dort durch die Mitte des Weges immer auch ein highway=* gehen soll/muss. Oder irre ich mich da gerade? ja, ich bezog mich auf area:highway und ja, da sollte zusätzlich noch ein highway-way im Graphen-modell gemappt sein (letzterer wird allgemein als bedeutend wichtiger angesehen, s. routing etc.) Am Mittwoch, 17. Dezember 2014 15:12 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Nur weil die in der Nähe liegende Straße einen Fußweg auf der Seite hat, wo auch ein Fußweg separat gezeichnet ist, bekommt man noch keine eindeutige Zuordnung in allen Fällen Eine direkt Zuordnung ist m.M. nach auch garnicht nötig, damit zumindest Renderer und Router das „vernünftig“ hinbekommen. Bei echten eigenständigen Wegen würde ja das footway=sidewalk am Gehweg fehlen und an der Straße auch kein sidewalk=* gemappt werden. für derzeitige Renderer und Router ist es egal, solange die Fußwege auch alle Namen (und sonstigen relevanten Eigenschaften die der jeweilige Datenkonsument braucht) haben (sonst können z.B. keine guten Anweisungen fürs Routing produziert werden). Es ist dann mehr eine theoretische Frage (geht aus der Kartierung klar hervor, wie es in der echten Welt da aussieht). Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am 17.12.2014 um 15:11 schrieb Martin Koppenhoefer: Am 17. Dezember 2014 um 02:24 schrieb 715371 osmu715...@gmx.de: Das Problem mit der Zuordnung der Fußwege zur Straße, bzw. umgekehrt empfinde ich als nicht so extrem. Über sidewalk=right/left/both bekommt man das schon hin. das kann man so aber nur raten, eine direkte Zuordnung gibt es nicht. Nur weil die in der Nähe liegende Straße einen Fußweg auf der Seite hat, wo auch ein Fußweg separat gezeichnet ist, bekommt man noch keine eindeutige Zuordnung in allen Fällen (z.B. schmale Straßen die parallel führen dazwischen eine Stützwand, eine Straße oben, eine unten). Man weiss bei OSM ja nie, ob die Stelle überhaupt schon zu Ende gemappt ist, oder evtl. noch wesentliche Teile fehlen. Stützwand ist jawohl eine Trennung oder ? Ala :lanes wäre: highway:ways:forward=highway|cycleway|parking|sidewalk vielleicht auch highway:ways:forward=highway|cycleway|kerb|parking|fence|sidewalk möglich. Noch nicht ganz ausgereift, gebe ich zu. Aber das ist doch doppelte Erfassung. Wobei es natürlich stimmt, dass man einen Tag an beiden Wegen benötigt. das ist so viel doppelte Erfassung, wie z.B. amenity=bank, atm=yes auf einem Objekt und amenity=atm auf einem anderen darinliegenden doppelte Erfassung ist. Das eine Tag an der Straße sagt: die Straße hat einen Gehweg, das andere Tag auf dem Fußweg sagt: ich bin ein Fußweg. Nicht ganz, bei der Straße geht genau der Unterschied zwischen doppelt gemappt oder doch zusätzlichen Weg verloren. da finde ich cycleway/sidewalk=separate_way oder ähnliches besser. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am 18. Dezember 2014 um 18:41 schrieb fly lowfligh...@googlemail.com: Nicht ganz, bei der Straße geht genau der Unterschied zwischen doppelt gemappt oder doch zusätzlichen Weg verloren. da finde ich cycleway/sidewalk=separate_way oder ähnliches besser. jein, ich wäre eher für eine Relation, dann ist die Zusammengehörigkeit eindeutig. separate_way hat das Problem, dass man erstens auch nicht genau weiss, welcher way, und zweitens bezieht man sich mit einem tag auf einen anderen way, den es zu einem späteren Zeitpunkt vielleicht schon gar nicht mehr gibt. Zwar könnte man fordern, wer den Gehweg verändert muss halt auch noch die Straße anschauen (und auch wenn das im Prinzip schon genau das Problem ist, so kann man es für Straßen vielleicht noch tolerieren), aber wenn man sowas erstmal eingeführt hat (tags die sich auf andere in der Nähe liegende, nicht genau spezifizierte/verlinkte Objekte beziehen), dann verbreitet sich das Prinzip vermutlich noch weiter auf andere Arten von Objekten. Das ist ein bisschen so ähnlich wie forward-Angaben auf einem Node. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am 17. Dezember 2014 um 02:17 schrieb 715371 osmu715...@gmx.de: Wird der Gehweg an Stellen, wo keine im Detail keine Bordsteintrennung besteht, dann mit der Straße vereint? Wie meinst du das? ohne das erste keine ;-) Wenn nur noch eine Bordsteintrennung besteht werden die Wege an die Straße angeschlossen und mit sidewalk bzw. cycleway weiter getaggt. ach so, ich hatte den Thread bisher so gelesen, dass eine Bordsteintrennung schon als getrennt interpretiert wird, und mich dann auf Stellen bezogen, wo der Bordstein verschwindet bzw. bündig ist mit Straße und Gehweg. Das kommt gelegentlich mal vor, ist aber nicht besonders üblich (normalerweise reduziert sich nur die Bordsteinhöhe, Stichwort abgesenkt). IMHO: Bordsteintrennungen zu erfassen ist nicht besonders sinnvoll. Meist sind die Verkehrsanlagen so gebaut, dass man an den passenden Stellen die Straße überqueren kann. naja, gerade da, wo die Verkehrsanlagen aus irgendeinem Grund nicht optimal gebaut sind, würde man ja von solchen gemappten Details profitieren, z.B. beim Routing. Man sollte hier auch im Hinterkopf behalten, dass OSM ein weltweites Projekt ist. .. aber es gibt so oder so an manchen Stellen Brüche (in der Logik/Konsistenz). Genau. Diese Brüche in den Modellen gibt es bei (eigentlich) jedem Modell +1, genau so hatte ich das auch gemeint (so oder so). Wenn man Modelle mischt (was wir ja zwangsläufig tun und weiterhin tun werden, weil wir es fürs Routing etc. brauchen), dann gibt es mit jedem Modell / Konvention an bestimmten Stellen Probleme oder nicht ganz so schöne Lösungen. . Aus meiner Sicht ist es die Frage, ob für Radfahrer oder Fußgänger bereits Bordsteine Grund für separate Erfassung sind. ja genau. Ich halte es persönlich so, dass ich mich nicht darum kümmere, vor allem nicht im Graphen-Modell (highway-key), also die Fußwege als implizitiert durch die Straße sehe (weil man eben auch an jeder Stelle queren kann, zumindest physisch*, als Erwachsener ohne besondere körperliche Andersartigkeit). Da es aber einige Mapper gibt, die das anders sehen, muss man sich zwangsläufig damit auseinandersetzen ;-) Wenn es ums Flächenmappen (von Wegen/Straßen) geht, dann würde ich auf jeden Fall Gehweg und Straße getrennt erfassen. Gruß, Martin * Verkehrsrechtlich sieht es wohl so aus, dass man theoretisch innerhalb von x Metern von einem gekennzeichneten Fußgängerüberweg, diesen verwenden muss. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am 17. Dezember 2014 um 02:24 schrieb 715371 osmu715...@gmx.de: Das Problem mit der Zuordnung der Fußwege zur Straße, bzw. umgekehrt empfinde ich als nicht so extrem. Über sidewalk=right/left/both bekommt man das schon hin. das kann man so aber nur raten, eine direkte Zuordnung gibt es nicht. Nur weil die in der Nähe liegende Straße einen Fußweg auf der Seite hat, wo auch ein Fußweg separat gezeichnet ist, bekommt man noch keine eindeutige Zuordnung in allen Fällen (z.B. schmale Straßen die parallel führen dazwischen eine Stützwand, eine Straße oben, eine unten). Man weiss bei OSM ja nie, ob die Stelle überhaupt schon zu Ende gemappt ist, oder evtl. noch wesentliche Teile fehlen. Aber das ist doch doppelte Erfassung. Wobei es natürlich stimmt, dass man einen Tag an beiden Wegen benötigt. das ist so viel doppelte Erfassung, wie z.B. amenity=bank, atm=yes auf einem Objekt und amenity=atm auf einem anderen darinliegenden doppelte Erfassung ist. Das eine Tag an der Straße sagt: die Straße hat einen Gehweg, das andere Tag auf dem Fußweg sagt: ich bin ein Fußweg. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am 17.12.2014 um 15:05 schrieb Martin Koppenhoefer: Am 17. Dezember 2014 um 02:17 schrieb 715371 osmu715...@gmx.de: Wird der Gehweg an Stellen, wo keine im Detail keine Bordsteintrennung besteht, dann mit der Straße vereint? Wie meinst du das? ohne das erste keine ;-) Entschuldige, ich stand auf dem Schlauch. :) Wenn ich das richtig verstehe, dass aus einer geraden Straße dann ein Zick-Zack-Weg daraus wird, wäre ich eher für eine area-relation. ;) Ich hatte das bisher immer so gelöst, dass dann wirklich ein Weg zur Straße führt. Allerdings bei Radwegen und nur dort, wo es einen Unterschied gemacht hatte. Allgemein bei abgesenktem Bordstein, würde ich das dann auch so machen. Ich wüsste nicht was dagegen spricht. Wenn nur noch eine Bordsteintrennung besteht werden die Wege an die Straße angeschlossen und mit sidewalk bzw. cycleway weiter getaggt. ach so, ich hatte den Thread bisher so gelesen, dass eine Bordsteintrennung schon als getrennt interpretiert wird, und mich dann auf Stellen bezogen, wo der Bordstein verschwindet bzw. bündig ist mit Straße und Gehweg. Das kommt gelegentlich mal vor, ist aber nicht besonders üblich (normalerweise reduziert sich nur die Bordsteinhöhe, Stichwort abgesenkt). Ich würde oben die Modelle mischen, weil ich dort nicht am Bordstein trenne. Ich glaube aber, dass man Gehwege hinter abgesenkten Bordsteinen weiterhin als eigenen Weg erfassen würde und dann mit einem orthogonalen Weg zur Fahrbahn verbinden würde. IMHO: Bordsteintrennungen zu erfassen ist nicht besonders sinnvoll. Meist sind die Verkehrsanlagen so gebaut, dass man an den passenden Stellen die Straße überqueren kann. naja, gerade da, wo die Verkehrsanlagen aus irgendeinem Grund nicht optimal gebaut sind, würde man ja von solchen gemappten Details profitieren, z.B. beim Routing. Man sollte hier auch im Hinterkopf behalten, dass OSM ein weltweites Projekt ist. OK. Das Problem ist soweit noch unklar. Aber ich denke, dass man es mit dem Taggen an die Straße auch probieren kann: Wenn man einen nicht abgesenkten Bürgersteig auf der rechten Seite hat und von der linken Seite eine Straße mündet. Könnte man entweder durch Tags ergänzend zum Bürgersteig sagen, dass der Bordstein auf dem Stück auf der rechten Seite nicht abgesenkt ist. Der Algorithmus nimmt dann die Kante und sagt, wenn der Wert bis zum Abbiegen da ist, kann man den Bürgersteig mit entsprechenden Verkehrmitteln (z.B. Rollstuhl) nicht benutzen. Ansonsten würde ich zumindest in D-land davon ausgehen, dass Bürgersteige abgesenkt sind, wenn man in eine andere Straße abbiegen möchte. . Aus meiner Sicht ist es die Frage, ob für Radfahrer oder Fußgänger bereits Bordsteine Grund für separate Erfassung sind. ja genau. Ich halte es persönlich so, dass ich mich nicht darum kümmere, vor allem nicht im Graphen-Modell (highway-key), also die Fußwege als implizitiert durch die Straße sehe (weil man eben auch an jeder Stelle queren kann, zumindest physisch*, als Erwachsener ohne besondere körperliche Andersartigkeit). Da es aber einige Mapper gibt, die das anders sehen, muss man sich zwangsläufig damit auseinandersetzen ;-) +1 Wenn es ums Flächenmappen (von Wegen/Straßen) geht, dann würde ich auf jeden Fall Gehweg und Straße getrennt erfassen. Na ja. Fahrspuren erfasst man ja auch nicht getrennt, obwohl man kurz vor der Ampel nicht mehr wechseln kann. Getrennt erfassen hat aber gerade dann Probleme (was das Modell anbelangt), sobald es immer wieder Verbindungen zwischen zwei Spuren gibt. Siehe z.B. Verkehrsinseln und Mehrzweckspur in der Fahrbahnmitte. Das ist exotisch, aber bei Gehwegen ist es aus meiner Sicht einigermaßen analog. * Verkehrsrechtlich sieht es wohl so aus, dass man theoretisch innerhalb von x Metern von einem gekennzeichneten Fußgängerüberweg, diesen verwenden muss. Das wäre aus meiner Sicht aber in keinem Modell ein Problem, dass man nicht einfach umsetzen kann: Nähe nächstes crossing=* x. Und dann weiß man ob man an der Stelle so rüber darf. Es gibt sonst ja auch Wege, die einem quasi das überqueren nahelegen, wo allerdings nur zwei gegenüber liegende Straßen aufeinandertreffen. Genauso ist das dann auch, wenn es keinen Knoten gibt. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am 17.12.2014 um 15:11 schrieb Martin Koppenhoefer: das ist so viel doppelte Erfassung, wie z.B. amenity=bank, atm=yes auf einem Objekt und amenity=atm auf einem anderen darinliegenden doppelte Erfassung ist. Das eine Tag an der Straße sagt: die Straße hat einen Gehweg, das andere Tag auf dem Fußweg sagt: ich bin ein Fußweg. Zwei Geldautomaten. Zumindest in der Hälfte aller Möglichkeiten. Das Zuordnungsproblem könnte es bei zwei Banken nebeneinander zumindest auch theoretisch... Aber ehrlich gesagt, würde ich es daran nicht scheitern lassen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] cycleway=track bei Bordstein Trennung
Hallo, Am Mittwoch, 17. Dezember 2014 15:06 schrieb Martin Koppenhoefer dieterdre...@gmail.com: ach so, ich hatte den Thread bisher so gelesen, dass eine Bordsteintrennung schon als getrennt interpretiert wird, und mich dann auf Stellen bezogen, wo der Bordstein verschwindet bzw. bündig ist mit Straße und Gehweg. Das kommt gelegentlich mal vor, ist aber nicht besonders üblich (normalerweise reduziert sich nur die Bordsteinhöhe, Stichwort abgesenkt). Auch wenn ich das genau so sehe, muss ich fairer Weise sagen, dass darüber überhaupt keine Einigung herrscht. Falls das von mir so rübergekommen ist, tut mir die das leid. Ich würde, wenn Fußwege als highway=footway + footway=sidewalk eingetragen werden, die aber auch dann so eintragen, wenn der Bordstein abgesenkt, also eben mit der Straße ist. Allerding ist das zugegebener Maßen im gegensatz zu einem Hochbord, deutlich schwieriger als bauliche Trennung zu verteidigen. Wenn es ums Flächenmappen (von Wegen/Straßen) geht, dann würde ich auf jeden Fall Gehweg und Straße getrennt erfassen. Interressanter Punkt, falls du dich dabei auf das area:highway=* beziehen solltest, meine ich mich zu erinnern, dass dort durch die Mitte des Weges immer auch ein highway=* gehen soll/muss. Oder irre ich mich da gerade? Am Mittwoch, 17. Dezember 2014 15:12 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 17. Dezember 2014 um 02:24 schrieb 715371 osmu715...@gmx.de: Das Problem mit der Zuordnung der Fußwege zur Straße, bzw. umgekehrt empfinde ich als nicht so extrem. Über sidewalk=right/left/both bekommt man das schon hin. Das kam von mir, und nich von Tobias. (nur falls/damit nicht der Falsche am Pranger landet) Nur weil die in der Nähe liegende Straße einen Fußweg auf der Seite hat, wo auch ein Fußweg separat gezeichnet ist, bekommt man noch keine eindeutige Zuordnung in allen Fällen Eine direkt Zuordnung ist m.M. nach auch garnicht nötig, damit zumindest Renderer und Router das vernünftig hinbekommen. Bei echten eigenständigen Wegen würde ja das footway=sidewalk am Gehweg fehlen und an der Straße auch kein sidewalk=* gemappt werden. Am Mittwoch, 17. Dezember 2014 22:27 schrieb 715371 osmu715...@gmx.de: Ich hatte das bisher immer so gelöst, dass dann wirklich ein Weg zur Straße führt. Allerdings bei Radwegen und nur dort, wo es einen Unterschied gemacht hatte. Allgemein bei abgesenktem Bordstein, würde ich das dann auch so machen. Ich wüsste nicht was dagegen spricht. +1. Ich denke hier z.B. an T-Kreuzungen, wo ich das so machen. Bei absenkten Bordsteinen hat man in den meisten Fällen ja eine Ausfahrt, die man mappen könnte, oder es ist tatsächlich ein Überqeurungs an genau der Stelle vorgesehen. Ich wünsche noch eine Gute Nacht. Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Moin, Am 18.12.2014 um 01:35 schrieb Hubert: Nur weil die in der Nähe liegende Straße einen Fußweg auf der Seite hat, wo auch ein Fußweg separat gezeichnet ist, bekommt man noch keine eindeutige Zuordnung in allen Fällen Eine direkt Zuordnung ist m.M. nach auch garnicht nötig, damit zumindest Renderer und Router das vernünftig hinbekommen. Bei echten eigenständigen Wegen würde ja das footway=sidewalk am Gehweg fehlen und an der Straße auch kein sidewalk=* gemappt werden. Was dann aber noch fies bleibt, sind solche Wege die erst straßenbegleitend sind und dann nicht mehr (weil deutlich zu weit weg). https://www.openstreetmap.org/way/202894636 Daher ist es aus meiner Sicht schwer die beiden Modelle miteinander zu vereinen, auch wenn ich gerade das an Huberts Ansatz gut finde. Möglicherweise ist der Punkt aber auch nicht so wichtig, weil das beim Rendern vielleicht niemanden interessiert. Zum Routen bräuchte man dann aber wieder alle Typen, weil sonst Inseln entstehen können. Am Mittwoch, 17. Dezember 2014 22:27 schrieb 715371 osmu715...@gmx.de: Ich hatte das bisher immer so gelöst, dass dann wirklich ein Weg zur Straße führt. Allerdings bei Radwegen und nur dort, wo es einen Unterschied gemacht hatte. Allgemein bei abgesenktem Bordstein, würde ich das dann auch so machen. Ich wüsste nicht was dagegen spricht. +1. Ich denke hier z.B. an T-Kreuzungen, wo ich das so machen. Bei absenkten Bordsteinen hat man in den meisten Fällen ja eine Ausfahrt, die man mappen könnte, oder es ist tatsächlich ein Überqeurungs an genau der Stelle vorgesehen. Ausfahrten verdichten auf jeden Fall schon die Wechselmöglichkeiten sehr. Die könnte man auch mit geringerer Fehlerquote vom Luftbild erfassen. Wenn man eine Gegend zu kennen glaubt, könnte das dann schon ausreichen. Gute Nacht Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am Samstag, 13. Dezember 2014, 00:41:23 schrieb Hubert: Der Renderer, welcher den Bürgersteig an der Straße darstellen möchte, unterdrückt halt alle highway=footway + footway=sidewalk und stellt die highway=residential + footway:both=sidewalk entsprechend dar. Z.B. als roten Rand. Derjenige, der den Bürgersteig als eigenen Weg darstellen will, malt die highway=residential + footway:both=sidewalk als normale Straßen, ohne roten Rand, und stellt darfür die highway=footway + footway=sidewalk dar. So oder so ähnlich. Damit der Renderer erkennen kann, dass die extra-Fußwege an die Straße gehören und er sich somit die (für den Maßstab) passendere Variante aussuchen kann, sollten es eine street-Relation geben, in der alle Linien, die zur gleichen Straße gehören, erfasst sind. Das erleichtert auch die Zuordung von Straßennamen etc. zu separaten Wegen. Auf dem gleichen Weg kann auch die Diskussion um die separaten oder nicht separaten Radwege gelöst werden. Der Datenkonsument kann sich dann frei aussuchen, welche Lösung er für sich für geeigneter hält. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am 16. Dezember 2014 um 13:05 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: Damit der Renderer erkennen kann, dass die extra-Fußwege an die Straße gehören und er sich somit die (für den Maßstab) passendere Variante aussuchen kann, sollten es eine street-Relation geben, in der alle Linien, die zur gleichen Straße gehören, erfasst sind. Das erleichtert auch die Zuordung von Straßennamen etc. zu separaten Wegen. Auf dem gleichen Weg kann auch die Diskussion um die separaten oder nicht separaten Radwege gelöst werden. Der Datenkonsument kann sich dann frei aussuchen, welche Lösung er für sich für geeigneter hält. evtl interessiert auch die area relation in diesem Zusammenhang. Wie machen die Leute, die die Fußwege explizit mappen, das eigentlich mit den anderen Attributen der Straße? Name, ref, oneway, wikipedia, etc.? Ist width auf dem highway=straße die Breite mit Gehweg oder ohne? Wird der Gehweg an Stellen, wo keine im Detail keine Bordsteintrennung besteht, dann mit der Straße vereint? Ich verstehe zwar schon den Vorteil, wenn man einzelne Wege zeichnet (intuitiver, geometrische Details lassen sich anders gar nicht abbilden, abweichende Surface und maxspeed Angaben sind einfacher zu mappen, etc.), aber es gibt so oder so an manchen Stellen Brüche (in der Logik/Konsistenz). Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am 16.12.2014 13:05, schrieb Wolfgang Hinsch: Damit der Renderer erkennen kann, dass die extra-Fußwege an die Straße gehören und er sich somit die (für den Maßstab) passendere Variante aussuchen kann, sollten es eine street-Relation geben, in der alle Linien, die zur gleichen Straße gehören, erfasst sind. Das erleichtert auch die Zuordung von Straßennamen etc. zu separaten Wegen. Es erleichtert das Problem mit den Straßennamen. Aber das Kernproblem, das ein Renderer-Autor hat, ist doch die Zuordnung eines Fußweges zu einem ganz bestimmten Way, nicht einer Gruppe von Ways. Es kann ja sein, dass manche Teile einer Straße einen Fußweg haben, andere vielleicht zwei oder gar keinen. Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Hallo, danke für die Beiträge. Ich habe am Anfang auch die street-relationen entsprechend der Empfehlungen des Lübecker Schemas eingetragen. Allerdings habe ich das als seeehr müsilig empfunden. Man muss für jede Straße eine eigene Relation anlege, die Straße kennzeichnen, die Nebenwege kannzeichnen, usw. Ich habe dafür viel Zeit gebraucht und nach knapp 5 Straßenzügen aufgegeben. Das Problem mit der Zuordnung der Fußwege zur Straße, bzw. umgekehrt empfinde ich als nicht so extrem. Über sidewalk=right/left/both bekommt man das schon hin. Allerdings hat man spätestens dann doppelte (eigntlich dann vierfache) Arbeit, wenn man aus Rücksicht auf den Datenauswerter andere Tags verwenden möchte. (z.B. statt sidewalk=* footway:*=sidewalk, wo ich mir dabei noch nicht sicher bin.) Gruß Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Moin, Am 16.12.2014 um 13:13 schrieb Martin Koppenhoefer: evtl interessiert auch die area relation in diesem Zusammenhang. Solche Relation an jeden Radweg zu machen wäre auf jeden Fall sehr aufwändig. Wie machen die Leute, die die Fußwege explizit mappen, das eigentlich mit den anderen Attributen der Straße? Name, ref, oneway, wikipedia, etc.? Ist width auf dem highway=straße die Breite mit Gehweg oder ohne? Bei mir würde sich das analog zu lanes auf die Fahrbahn beziehen. Die Summe der Breiten ist aus meiner Sicht nicht wichtig, wenn man aus den Einzelwerten auch auf die Summe schließen kann. Auch wenn man das mit JOSM aus meiner Sicht hinreichend einfach erfassen kann, habe ich das noch nicht viel gemacht - und werde ich wohl auch erst einmal nicht. Die Auffassung darüber wird aber sehr unterschiedlich sein. Es gibt Mapper, die bei highway=cycleway für die Radwegbreite width benutzen, was OK wäre, wenn derselbe Weg nicht auch nocht den Gehweg identifizieren würde. Wird der Gehweg an Stellen, wo keine im Detail keine Bordsteintrennung besteht, dann mit der Straße vereint? Wie meinst du das? Wenn nur noch eine Bordsteintrennung besteht werden die Wege an die Straße angeschlossen und mit sidewalk bzw. cycleway weiter getaggt. IMHO: Bordsteintrennungen zu erfassen ist nicht besonders sinnvoll. Meist sind die Verkehrsanlagen so gebaut, dass man an den passenden Stellen die Straße überqueren kann. Ähm, ich meine natürlich das ist total sinnvoll und ich würde gerne einen Tag für Schlaglöcher vorschlagen: barrier=pothole ;) Ich verstehe zwar schon den Vorteil, wenn man einzelne Wege zeichnet (intuitiver, geometrische Details lassen sich anders gar nicht abbilden, abweichende Surface und maxspeed Angaben sind einfacher zu mappen, etc.), aber es gibt so oder so an manchen Stellen Brüche (in der Logik/Konsistenz). Genau. Diese Brüche in den Modellen gibt es bei (eigentlich) jedem Modell. Aus meiner Sicht ist es die Frage, ob für Radfahrer oder Fußgänger bereits Bordsteine Grund für separate Erfassung sind. LG ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am 16.12.2014 um 23:28 schrieb Hubert: Das Problem mit der Zuordnung der Fußwege zur Straße, bzw. umgekehrt empfinde ich als nicht so extrem. Über sidewalk=right/left/both bekommt man das schon hin. Aber das ist doch doppelte Erfassung. Wobei es natürlich stimmt, dass man einen Tag an beiden Wegen benötigt. Allerdings hat man spätestens dann doppelte (eigntlich dann vierfache) Arbeit, wenn man aus Rücksicht auf den Datenauswerter andere Tags verwenden möchte. (z.B. statt sidewalk=* footway:*=sidewalk, wo ich mir dabei noch nicht sicher bin.) Die Arbeit sollte man sich machen. Es wäre tatsächlich schöner, wenn die Relation besser unterstützt würde. wikipedia, name, old_name etc sind schon ein ganz guter Grund. Aber weil es so aufändig ist, sollte man sich beim separaten Erfassen IMHO auch auf die wirklich getrennten Rad- und Fußwege beschränken. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Hallo, bitte entschuldigt die verzögerte Antwort Am Donnerstag, 11. Dezember 2014 03:24 schrieb 715371 osmu715...@gmx.de: ... Es bleibt irgendwie schwer zu vergleichen. Ja, und wie war das noch gleich: Traue nie einer Statistik die du nicht selber gefälscht hast. ;) ... Eine Doppelrepräsentation würde das Problem mit dem Rendern lösen, das ich für wichtig halte. So richtig elegant finde ich das nicht. Und es gibt auch einige Mapper, die das komplett ablehnen. Zumindest habe ich das in den Diskussionen zu den Proposals von damals gelesen. Ich bin mir auch noch nicht wirklich sicher, dass die Vorteile überwiegen. Allerdings ist es im Moment die einziege Möglichkeit, die Ich sehe, beide Darstellungen zu haben. ... Wobei dann auch solche Dinge wie barrier=retaining_wall/fence etc berücksichtigt werden müssten. Wenn jemand z.B. keine turn-restriction gemappt hat, weil er es ja separat eingezeichnet hat und es deshalb nicht geht, würde das sonst zu Fehlern führen - so würde ich mir das ad-hoc vorstellen. Tut mir leid, aber da kann ich dir gerade nicht folgen. highway=footway + footway=sidewalk wird/soll ja nur gemappt werden, wenn ein Wechsel auf die Straße jeder Zeit möglich ist. Ansonsten wird doch nur highway=footway gemappt, oder? OK. Es kommt definitiv auf die Situation an. Wenn eine Straße nur einen Bürgersteig hat, dann genügt sidewalk=*. Wenn der Fußweg von der übrigen Anlage getrennt ist, kann es sich hingegen lohnen, die Wege separat einzuzeichnen. Deshalb wäre es wohl auch nicht im Sinne der OSM separates erfassen generell zu verbieten, sondern nur in bestimmten Situationen. Ich weis nicht so recht. :/ . Ich bin eher dafür, das auf irgend eine Art und Wiese einheitlich zu haben. Dass mit dem dubiosen approved bei sidewalk=* ist mir auch aufgefallen. Allerdings wäre eine Abstimmung inzwischen irgendwie sinnlos. Bei footway=sidewalk halte ich die für wesentlich wichtiger. Durch den Gebrauch ist das Tagging allerdings auch ziemlich fix. Wenn man sich das Proposal zu footway=sidewalk durchliest, könnte man bei der Abstimmung schon genau die Kritik/Befürchtung, die ich hier auch übe, vermuten. Sehe ich auch so. Vieleicht kann die Doppelrepresentation als Komptomiss dazu dienen, ohne selber alt zu fiel Ärger zu verursachen. Ich werde mal im Laufe der nächsten Woche ein paar Gedanken dazu formulieren. Mal sehen was mir dabei noch alles einfällt. Deine Anwendung ist die erste bei der ich bemerke, dass sie diese Daten benutzt. Und dann auch noch nicht einmal nur die - es sind noch mehr Tags nötig. Ob das Proposal damals mit doppeltagging eine Mehrheit bekommen hätte? Na ja... Wenn man das nur mit Gehwegen machen würde, bräuchte es nicht soviele tags. Viele der Tags sind einfach der sehr unübersichtlichen Lage (Rechtlich, OSM Tagging) beim Thema Fahrrad/Radwege geschuldet. 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). Schon möglich, aber das gibt es bei Routern auch jetzt schon. Ich setzt dann den Start/Endepunkt nicht auf ein Gebäude, sonder einfach auf die Straße davor. Mit Maus ist das kein großes Problem, aber unterwegs für den Router macht es das nur komplizierter und die Bedienung umständlicher. Es wäre halt schön zu wissen, dass das was da so viele machen auch funktioniert. Guter Einwand. Allerdings haben viele Fußgänger und Radfahrer Router (immer noch) große Probleme vernünftige Ergebnisse zu liefern. Beste Grüße Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am 11.12.2014 03:24, schrieb 715371: Eine Doppelrepräsentation würde das Problem mit dem Rendern lösen, das ich für wichtig halte. Verstehe ich nicht. Ein Renderer der beides auswertet malt dann 2 Linien neben der Straße, das soll schön aussehen? Chris ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Hallo, Am Freitag, 12. Dezember 2014 21:18 schrieb chris66 chris66...@gmx.de: Am 11.12.2014 03:24, schrieb 715371: Eine Doppelrepräsentation würde das Problem mit dem Rendern lösen, das ich für wichtig halte. Verstehe ich nicht. Ein Renderer der beides auswertet malt dann 2 Linien neben der Straße, das soll schön aussehen? Prizipiel hast Du erstmal Recht. Es verlangt von einem Renderer, der das Vernünftig darstellen will, eine etwas kompliziertere Abfrage. Das Tagging müsste außerdem gut durchdacht werden. Als einfaches Beispiel (bitte nicht daran verbeißen) sei aber mal folgendes Situation gegeben: Eine Wohnstraße mit Borstein-Gehwegen auf beiden Seiten. highway=residential + footway:both=sidewalk highway=footway + footway=sidewalk Der Renderer, welcher den Bürgersteig an der Straße darstellen möchte, unterdrückt halt alle highway=footway + footway=sidewalk und stellt die highway=residential + footway:both=sidewalk entsprechend dar. Z.B. als roten Rand. Derjenige, der den Bürgersteig als eigenen Weg darstellen will, malt die highway=residential + footway:both=sidewalk als normale Straßen, ohne roten Rand, und stellt darfür die highway=footway + footway=sidewalk dar. So oder so ähnlich. Gruß Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Hallo. Entschuldigung für die lange Antwort und ich hoffe die Formatierung passt dieses mal. Am Dienstag, 9. Dezember 2014 17:55 schrieb 715371 osmu715...@gmx.de: Mit Taginfo kann man folgende Zahlen ermitteln: Separat erfasst: footway=sidewalk 143 686 footway=crossing 86 541 An Straße erfassst: sidewalk=none222 954 sidewalk=both143 254 sidewalk=right63 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. Hmm. Ich hätte jetzt eine andere Schlussfolgerung gezogen, nämlich dass man die Zahlen bei sidewalk=* verringern müsste und zwar Aufgrund von Wegtrennungen durch turn:lanes, parking:lane, maxspeed, etc. Einen Faktor mag ich jedoch nicht abschätzen. 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. + 1. Da Stimme ich dir voll zu. Das korregiert man dann einfach. Ich sag nur highway=road 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. Ja stimmt, aber man hat auch weniger Informationen. Ich denke man sollte die Sache sequenziel aufbauen. Einer fängt einfach an, und nach und nach wird es mehr (und leider auch komplizierter). Im speziellen Fall schwebt mir als Kompromis eine Art Doppelrepresentation vor. Also sowohl sidewalk=* als auch highway=footway + footway=sidewalk. Wie genau das ausehen kann, muss noch diskutiert warden. Das seperate Eintragen einfach zu untersagen, ist natürlich die einfachere Lösung. 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. In der Forum Diskussion wurde eine Möglichkeit vorgestellt, wie ein Router bei highway=footway + footway=sidewalk durch schlagen von Orthogonalen alle x Meter eine ständige Querungsmöglichkeit schafft. Schiffe als Gebäude einzuzeichnen scheint ja laut Wiki OK zu sein - auch wenn ich das ein wenig zweifelhaft finde. ;) Hängt glaube ich davon ab ob es sich noch bewegt. Es gibt in Rostock ein paar Museumsschiffe die ständig vor Ankerleigen. OT: Und auch dort bleiben solltenm, da sie sonst sinken. (http://www.spiegel.de/panorama/fahrt-zur-verschrottung-georg-buechner-vor-polen-gesunken-a-902980.html) 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). Da bin ich anderer Meinung. Klar gibt es Probleme, aber die kann man zu lösen. Das Versuche ich hier. Ich halte es für besser eine Nachfrage (hier das seperate Mappen) zu befriedigen, als etwas zu verbieten. Das Eintragen von als sidewalk=* ist aus meiner Sicht nur eine unzureichende Möglichkeit. Die Karte finde ich gut. Allerdings ist das nicht was angestrebt ist und weitaus schlechter als würde man cycleway=* oder sidewalk=* benutzen. Die Karte ist nur als Konzept zu verstehn und noch lange nicht fertig. Sowohl hinsichtlich des Taggings als auch des Renderings. Außerdem felht z.B. die Ledende noch. Kritik und Anregungen nehme ich gerne entgegen. Ich bin aber gerade damit beschäftigt den Code von Maperitive in CartoCSS zu übersetzten, was etwas schwieriger ist, als erwartet. 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. Das mit den Straßennamen ist abschicht und der besseren Lesbarkeit geschuldet. Bei den Unterschied der Darstellungen gibt es ab Zoomlevel 17 die straßenbegleitenden highway=path/cycleway und sonst cycleway=* ohne cycleway=track/sidepath. Bei Zoomlevel 15/16 werden nur eigenständige highway=cycleway/path dargestellt, alles Anderen als cycleway=* seitenrichtig. Bei Zoomlevel 13/14 wird es nur noch auf der
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Moin, Am 10.12.2014 um 16:37 schrieb Hubert: Entschuldigung für die lange Antwort und ich hoffe die Formatierung passt dieses mal. Bei mir ebenso. ;) Am Dienstag, 9. Dezember 2014 17:55 schrieb 715371 osmu715...@gmx.de: Mit Taginfo kann man folgende Zahlen ermitteln: Separat erfasst: footway=sidewalk 143 686 footway=crossing86 541 An Straße erfassst: sidewalk=none 222 954 sidewalk=both 143 254 sidewalk=right 63 796 sidewalk=left 30 027 ... footway=both12 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. Hmm. Ich hätte jetzt eine andere Schlussfolgerung gezogen, nämlich dass man die Zahlen bei sidewalk=* verringern müsste und zwar Aufgrund von Wegtrennungen durch turn:lanes, parking:lane, maxspeed, etc. Einen Faktor mag ich jedoch nicht abschätzen. Vielleicht kann man die Segmentierung bei separaten Wegen ja durch footway=crossing abschätzen. Das könnte die Zahl der separat erfassten Wege noch einmal verringern. Aber ich kenne auch viele separat erfasste Wege die länger sind als die dazugehörigen Fahrbahnwege. Es bleibt irgendwie schwer zu vergleichen. 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. + 1. Da Stimme ich dir voll zu. Das korregiert man dann einfach. Ich sag nur highway=road Stimmt. So funktioniert OSM. Es ist nicht beim ersten Mal erfassen schon komplett etc 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. Ja stimmt, aber man hat auch weniger Informationen. Ich denke man sollte die Sache sequenziel aufbauen. Einer fängt einfach an, und nach und nach wird es mehr (und leider auch komplizierter). Im speziellen Fall schwebt mir als Kompromis eine Art Doppelrepresentation vor. Also sowohl sidewalk=* als auch highway=footway + footway=sidewalk. Wie genau das ausehen kann, muss noch diskutiert warden. Das seperate Eintragen einfach zu untersagen, ist natürlich die einfachere Lösung. Eine Doppelrepräsentation würde das Problem mit dem Rendern lösen, das ich für wichtig halte. So richtig elegant finde ich das nicht. Und es gibt auch einige Mapper, die das komplett ablehnen. Zumindest habe ich das in den Diskussionen zu den Proposals von damals gelesen. In der Forum Diskussion wurde eine Möglichkeit vorgestellt, wie ein Router bei highway=footway + footway=sidewalk durch schlagen von Orthogonalen alle x Meter eine ständige Querungsmöglichkeit schafft. Wobei dann auch solche Dinge wie barrier=retaining_wall/fence etc berücksichtigt werden müssten. Wenn jemand z.B. keine turn-restriction gemappt hat, weil er es ja separat eingezeichnet hat und es deshalb nicht geht, würde das sonst zu Fehlern führen - so würde ich mir das ad-hoc vorstellen. 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). Da bin ich anderer Meinung. Klar gibt es Probleme, aber die kann man zu lösen. Das Versuche ich hier. Ich halte es für besser eine Nachfrage (hier das seperate Mappen) zu befriedigen, als etwas zu verbieten. Das Eintragen von als sidewalk=* ist aus meiner Sicht nur eine unzureichende Möglichkeit. OK. Es kommt definitiv auf die Situation an. Wenn eine Straße nur einen Bürgersteig hat, dann genügt sidewalk=*. Wenn der Fußweg von der übrigen Anlage getrennt ist, kann es sich hingegen lohnen, die Wege separat einzuzeichnen. Deshalb wäre es wohl auch nicht im Sinne der OSM separates erfassen generell zu verbieten, sondern nur in bestimmten Situationen. 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. Das mit den Straßennamen ist abschicht und der besseren Lesbarkeit geschuldet. Bei den Unterschied der Darstellungen gibt es ab Zoomlevel 17 die straßenbegleitenden highway=path/cycleway und sonst cycleway=* ohne cycleway=track/sidepath. Bei Zoomlevel 15/16
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Hallo, danke für die Antworten. Am Montag, 8. Dezember 2014 19:34 schrieb fly lowfligh...@googlemail.com: 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. Ich habe meine Meinung zum Erfassen von Gehwegen nocht nicht zementiert, aber ich tendiere eher in Richtung seperatem erfassen. Am Dienstag, 9. Dezember 2014 01:55 schrieb 715371 osmu715...@gmx.de: Moin, Am 08.12.2014 um 16:50 schrieb Hubert: Hat dort jemand eine Idee. In der genannten Diskussion lief es darauf hinnaus, dass 3 Typen von Gehwegen unterschieden werden müssen. Eigenständige Gehwege, straßenbegleitende Gehwege mit abgesetzter Führung (Grünstreifen, Zaum, o.ä.) und straßenbegleitende Gehwege mit enger Führung, aka Bürgersteige (nur durch Bordstein getrennt, wechseln auf die Fahrbahn jederzeit möglich). Bei Radwegen sehe ich die Problemtik ähnlich gelagert. Meinungen? Gedanken? Danke Hubert, den Thread kannte ich noch nicht. Deine Analyse würde ich im groben auch teilen. Danke und *Puh* ;D Ich habe den Thread grob durchgelesen, aber auch vorher schon eine ziemlich statische Meinung gehabt - an der hat sich eigentlich nichts geändert. Eigenständige Gehwege - eigener Weg Straßenbegleitende Gehwege mit abgesetzter Führung - (*) Straßenbegleitende Wege mit enger Führung - sidewalk=* (*) Entscheidend ist: Was ist die Trennung? Bordstein - sidewalk=* Parkstreifen - sidewalk=* Grasstreifen mit Bäumen - sidewalk=* Grasstreifen mit mehr 5m Abstand von Fahrbahn - eigener Weg Grünstreifen aus Sträuchern - eigener Weg Zaun - eigener Weg Und was eine Hand voll Bordstein-Bürgersteigmappern schon selber erkannt hat: Es geht nicht ohne foot=use_sidepath. Da ich einen Bordstein als bauliche Trennung anerkenne, denke ich es ist OK diese auch seperat einzutragen. Und ja, foot=use_sidepath wäre dann erforderlich. Soweit ich das Konzept für Gehwege an die Straße Taggen überblicke, wäre es doch auch dort denkbar auf einzelne Personengruppen eingehen zu können. Ansonsten habe ich den Eindruck, dass die Mehrheit gegen das separate Erfassen ist, wenn es nur eine Bordsteintrennung gibt. Könnte man das nicht entsprechend deprecaten? 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 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. 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 Wenn da jetzt wer etwas implementiert, dass eine Pseudo-Verbindung zwischen Rad-/Gehweg und Straße interpoliert, würde ich gerne genauer wissen wie Fehleranfällig das ist. Mich auch. Außerdem dürfen Radfahrer in D per default auf der Straße fahren. Ja. IMHO ist es in Städten mit engen Straßen absurd Bürgersteige saparat zu
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am 09.12.2014 um 13:17 schrieb Hubert: Hallo, danke für die Antworten. Am Montag, 8. Dezember 2014 19:34 schrieb fly lowfligh...@googlemail.com: 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=sidewalk143 686 footway=crossing 86 541 An Straße erfassst: sidewalk=none 222 954 sidewalk=both 143 254 sidewalk=right 63 796 sidewalk=left30 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
[Talk-de] cycleway=track bei Bordstein Trennung
Hallo, Am 8. Dezember 2014 12:05 schrieb 715371 osmu715...@gmx.de: Was, wenn der cycleway=track nur durch Bordstein von der Fahrbahn getrennt wäre? Zum Thema Bordstein-Trennung gab es Ende Oktober eine kleine Diskussuion hinsichtlich des Eintragens von Bürgersteigen (http://forum.openstreetmap.org/viewtopic.php?id=27488. Es ging darum ob und wann ja wie Bürgersteige und Überwege eingetragen werden sollen. Zusammengefasst (Ich hoffe ich erinnere mich richtig): Keine Einigung, entweder als sidewalk=right/left/both oder als highway=footway dann aber mit footway=sidewalk. Das wird bei einem Bordsteinradweg allerdings etwas schwieriger, da es (noch) keinen äquivalenten tag zu footway=sidewalk für Radwege gibt. Hat dort jemand eine Idee. In der genannten Diskussion lief es darauf hinnaus, dass 3 Typen von Gehwegen unterschieden werden müssen. Eigenständige Gehwege, straßenbegleitende Gehwege mit abgesetzter Führung (Grünstreifen, Zaum, o.ä.) und straßenbegleitende Gehwege mit enger Führung, aka Bürgersteige (nur durch Bordstein getrennt, wechseln auf die Fahrbahn jederzeit möglich). Bei Radwegen sehe ich die Problemtik ähnlich gelagert. Meinungen? Gedanken? Gruß Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am 08.12.2014 um 16:50 schrieb Hubert: Hallo, Am 8. Dezember 2014 12:05 schrieb 715371 osmu715...@gmx.de: Was, wenn der cycleway=track nur durch Bordstein von der Fahrbahn getrennt wäre? Zum Thema Bordstein-Trennung gab es Ende Oktober eine kleine Diskussuion hinsichtlich des Eintragens von Bürgersteigen (http://forum.openstreetmap.org/viewtopic.php?id=27488. Es ging darum ob und wann ja wie Bürgersteige und Überwege eingetragen werden sollen. Zusammengefasst (Ich hoffe ich erinnere mich richtig): Keine Einigung, entweder als sidewalk=right/left/both oder als highway=footway dann aber mit footway=sidewalk. Das wird bei einem Bordsteinradweg allerdings etwas schwieriger, da es (noch) keinen äquivalenten tag zu footway=sidewalk für Radwege gibt. Ich habe zumindest path=sidewalk/crossing schon öfter verwendet. Reinen cycleways begegne ich äußerst selten. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Moin, Am 08.12.2014 um 16:50 schrieb Hubert: Hat dort jemand eine Idee. In der genannten Diskussion lief es darauf hinnaus, dass 3 Typen von Gehwegen unterschieden werden müssen. Eigenständige Gehwege, straßenbegleitende Gehwege mit abgesetzter Führung (Grünstreifen, Zaum, o.ä.) und straßenbegleitende Gehwege mit enger Führung, aka Bürgersteige (nur durch Bordstein getrennt, wechseln auf die Fahrbahn jederzeit möglich). Bei Radwegen sehe ich die Problemtik ähnlich gelagert. Meinungen? Gedanken? Danke Hubert, den Thread kannte ich noch nicht. Deine Analyse würde ich im groben auch teilen. Ich habe den Thread grob durchgelesen, aber auch vorher schon eine ziemlich statische Meinung gehabt - an der hat sich eigentlich nichts geändert. Eigenständige Gehwege - eigener Weg Straßenbegleitende Gehwege mit abgesetzter Führung - (*) Straßenbegleitende Wege mit enger Führung - sidewalk=* (*) Entscheidend ist: Was ist die Trennung? Bordstein - sidewalk=* Parkstreifen - sidewalk=* Grasstreifen mit Bäumen - sidewalk=* Grasstreifen mit mehr 5m Abstand von Fahrbahn - eigener Weg Grünstreifen aus Sträuchern - eigener Weg Zaun - eigener Weg Und was eine Hand voll Bordstein-Bürgersteigmappern schon selber erkannt hat: Es geht nicht ohne foot=use_sidepath. Soweit ich das Konzept für Gehwege an die Straße Taggen überblicke, wäre es doch auch dort denkbar auf einzelne Personengruppen eingehen zu können. Ansonsten habe ich den Eindruck, dass die Mehrheit gegen das separate Erfassen ist, wenn es nur eine Bordsteintrennung gibt. Könnte man das nicht entsprechend deprecaten? 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. 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. Wenn da jetzt wer etwas implementiert, dass eine Pseudo-Verbindung zwischen Rad-/Gehweg und Straße interpoliert, würde ich gerne genauer wissen wie Fehleranfällig das ist. Außerdem dürfen Radfahrer in D per default auf der Straße fahren. 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! 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.7965layers=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.78780layers=C 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. LG Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
