cycleway vs. path

Radeln · 2011-01-26T16:33:07.000Z

fkv:

Radeln:

Es gibt getrennt geführte Wege mit mehreren Metern Abstand, wovon der eine als Radweg und der andere als Fußweg. Bei sind mit den entsprechenden blauen Schildern gekennzeichnet. Da ist ‘official’ sicher angebracht.

Der eine highway=footway + foot=designated, der andere highway=cycleway. Fertig.

Dann kann man sich das foot=designated ebenfalls sparen. Basta.

SunCobalt · 2011-01-26T16:36:45.000Z

Radeln:

fkv:

Radeln:

Es gibt getrennt geführte Wege mit mehreren Metern Abstand, wovon der eine als Radweg und der andere als Fußweg. Bei sind mit den entsprechenden blauen Schildern gekennzeichnet. Da ist ‘official’ sicher angebracht.

Der eine highway=footway + foot=designated, der andere highway=cycleway. Fertig.

Dann kann man sich das foot=designated ebenfalls sparen. Basta.

nee, weil footway nur foot=yes impliziert, nicht die Beschilderung

godofglow · 2011-01-26T16:44:42.000Z

delete footway und cycleway, alle.
Die Typen sind absolut ungenerisch.

alv · 2011-01-26T16:46:22.000Z

fkv:

Der Alv zielte mit seinem Proposal für highway=path darauf ab, diesen Wirrwarr zu vereinheitlichen, indem alle durch highway=path ersetzt werden. Leider wurde dieser Teil des Proposals wegen ein paar Stimmen nicht angenommen, sodass genau das Gegenteil erreicht wurde, nämlich ein völliges Durcheinander. Die Beispiele bauen noch darauf auf, dass es außer highway=path nichts anderes mehr gibt.

War doch nicht mein Proposal. Ich war nur aktiv auf die Talk-Seite dazu.

Radeln · 2011-01-26T16:55:12.000Z

SunCobalt:

Radeln:

fkv:

Der eine highway=footway + foot=designated, der andere highway=cycleway. Fertig.

Dann kann man sich das foot=designated ebenfalls sparen. Basta.

nee, weil footway nur foot=yes impliziert, nicht die Beschilderung

Und bei cycleway ist das anders? Oder hat Dich das ‘Bei’ was ‘Beide’ lauten sollte irritiert?

alv · 2011-01-26T16:55:55.000Z

fkv:

Defaultwerte annehmen:
highway=path => surface=unpaved, [double tracked vehicles]=no

Beinahe. Wenn etwas zu schmal für ein zweispurig Fahrzeug ist, kann es nicht ein highway=track sein - aber wenn etwas ein path ist, kann es auch breit sein. Z.B. die meisten Fahrradwege mit blauen Schild.

Weil highway=path beinahe keine Defaultwerte impliziert, macht es, meiner Meinung nach, mehr Sinn meistens die =footway und =cycleway zu benutzen. Das habe ich bei die Diskussion Seite auf die path Proposal überzeugen versucht.

aighes · 2011-01-26T17:11:01.000Z

Fürs Auswerten ist es besser, man beschreibt die Realität vor Ort und schmeißt das ganze nicht in eine Kategorie.
bsp.
path → keine Straße
surface → “Oberflächenart”
smoothness → “Ebenheit”
access → Benutzungseinschränkung
width → Breite
usw.

Dann kann jeder Mapper genau das ausdrücken, wie es vor Ort aussieht und es kommt am Ende etwas global mehr oder weniger einheitliches raus und der Auswerter kann das auswerten, was ihn interessiert und wie er es benötigt.
Anders bei einem Tag, das in Region A dies impliziert und in Region B jenes oder Mapper A impliziert dies und Mapper B das. Übrig bleibt dann für den Auswerter der kleinste gemeinsame Nenner.
Bei cycleway wäre es keine Straße und Radfahren erlaubt.

Fabi2 · 2011-01-26T17:11:30.000Z

Eigentlich war/ist das ja alles ganz einfach:

highway=path → z.B. Wanderweg, Berg- oder Wiesenpfad
highway=footway → durch Menschenhand ausgebauter Weg für Fußgänger
highway=cycleway → durch Menschenhand ausgebauter Weg für Radfahrer

mit blauem Schild → foot=desigated oder bicycle=designated
kombiierter Fuß-/Radweg mit blauem Schild → highway=footway oder highway=cycleway; mit Zusatztags: foot=designated, bicycle=designated, segregated=no
getrennter " " → highway=footway oder highway=cycleway; mit Zusatztags: foot=designated, bicycle=designated, segregated=yes

Fußweg mit weißen “Radfaher frei”-Schild → bicycle=yes

errt · 2011-01-26T17:18:31.000Z

Die Proposal Seite ist ein schönes Beispiel dafür, warum Proposals alte Tags unbedingt für ‘deprecated’ erklären sollten. Schade, dass das damals zwar den Erstellern, aber nicht den Abstimmern klar war, sonst hätten wir heute viel weniger Diskussion über dieses Thema.

Fabi2 · 2011-01-26T17:28:27.000Z

errt:

Die Proposal Seite ist ein schönes Beispiel dafür, warum Proposals alte Tags unbedingt für ‘deprecated’ erklären sollten. Schade, dass das damals zwar den Erstellern, aber nicht den Abstimmern klar war, sonst hätten wir heute viel weniger Diskussion über dieses Thema.

Nee, die Schnapsidee war die unzulässige Ausweitung der bedeutung von path, ein Pfad bleibt ein Pfad, nur irgendwer meite das für ausgebaute Fuß- und Radwege proposen zu müssen. Man sollte also Tags nicht absichtlich entgegen ihrer sprachlichen Bedeutung definieren.

Das Proplem von “deprecated”-Erklärungenist, das ja immer nur ein Bruchteil abstimmt und das ganze Proposal-Prozess-Theater so nicht alle mitbekommen, sofern sie da überhaupt noch willig, sind mitzumachen.
Diese Leute sind dann wohl evtl. aneder Meinung ob man das als veraltet betrachten soll.

Radeln · 2011-01-26T19:33:41.000Z

Fabi2:

Nee, die Schnapsidee war die unzulässige Ausweitung der bedeutung von path, ein Pfad bleibt ein Pfad, nur irgendwer meite das für ausgebaute Fuß- und Radwege proposen zu müssen. Man sollte also Tags nicht absichtlich entgegen ihrer sprachlichen Bedeutung definieren.

Wenn JOSM das als Vorlage anbietet, muß es wohl richtig sein.

aighes · 2011-01-26T19:38:17.000Z

Fabi2:

Nee, die Schnapsidee war die unzulässige Ausweitung der bedeutung von path, ein Pfad bleibt ein Pfad, nur irgendwer meite das für ausgebaute Fuß- und Radwege proposen zu müssen. Man sollte also Tags nicht absichtlich entgegen ihrer sprachlichen Bedeutung definieren.

path bedeutet ganz allgemein Weg. Nur die sprachliche nähe zum deutschen Pfad lässt einige Deutsche Mapper etwas anderes glauben…

extremecarver · 2011-01-26T20:05:29.000Z

Das einzig blöde ist highway=path oder highway=footway ohne irgendwelche Zusatztags bezüglich smoothness, width, tracktype, mtb:scale, (der kaum ernsthaft zu nehmenden sac_scale), etc.

Fabi2 · 2011-01-26T20:15:23.000Z

Radeln:

Wenn JOSM das als Vorlage anbietet, muß es wohl richtig sein.

Nein, das weist nur auf die Einstellung des Vorlagenerstellers zu diesem Thema hin. Richtig ist was anderes…

aighes:

path bedeutet ganz allgemein Weg. Nur die sprachliche nähe zum deutschen Pfad lässt einige Deutsche Mapper etwas anderes glauben…

Naja, für irgendwas muß es ja auch noch “way” geben. Außerdem ist z.B. das Routingergebnis der “way” und nicht der “path”.

Basstoelpel · 2011-01-26T21:09:25.000Z

Fabi2:

Nee, die Schnapsidee war die unzulässige Ausweitung der bedeutung von path, ein Pfad bleibt ein Pfad, nur irgendwer meite das für ausgebaute Fuß- und Radwege proposen zu müssen. Man sollte also Tags nicht absichtlich entgegen ihrer sprachlichen Bedeutung definieren.

+1

Baßtölpel

SunCobalt · 2011-01-26T21:21:32.000Z

Basstoelpel:

Fabi2:

Nee, die Schnapsidee war die unzulässige Ausweitung der bedeutung von path, ein Pfad bleibt ein Pfad, nur irgendwer meite das für ausgebaute Fuß- und Radwege proposen zu müssen. Man sollte also Tags nicht absichtlich entgegen ihrer sprachlichen Bedeutung definieren.

+1

Baßtölpel

-1

ich wusste doch, es wird lustig. Ich glaube, die Bedeutung von path wird unterschätzt

SimonPoole · 2011-01-26T21:33:32.000Z

Gähn, irgendwie scheinen es einige immer noch nicht geschnallt zu haben, dass das wirkliche unterliegende Problem ein Mischmasch ist in der Auszeichung von “Wegen” zwischen der Widmung/Nutzung und der physischen Ausgestaltung.

Als eher naturwissenschaftlich angehauchter Mensch, ziehe ich letzeres als primäre Klassifikation vor, also path==einspurig, track==zweispurig … dann bricht leider das OSM Modell. Ich hab mir auch schon überlegt mal ein Proposal zu machen alle aktuelle highway tags zu ersetzen mit path (könnt auch single_track sein), single_lane, multiple_lanes etc. aber ist wohl völlig sinnlos.

Simon

SunCobalt · 2011-01-26T21:37:47.000Z

SimonPoole:

Gähn, irgendwie scheinen es einige immer noch nicht geschnallt zu haben, dass das wirkliche unterliegende Problem ein Mischmasch ist in der Auszeichung von “Wegen” zwischen der Widmung/Nutzung und der physischen Ausgestaltung.

Als eher naturwissenschaftlich angehauchter Mensch, ziehe ich letzeres als primäre Klassifikation vor, also path==einspurig, track==zweispurig … dann bricht leider das OSM Modell. Ich hab mir auch schon überlegt mal ein Proposal zu machen alle aktuelle highway tags zu ersetzen mit path (könnt auch single_track sein), single_lane, multiple_lanes etc. aber ist wohl völlig sinnlos.

Simon

Ich sehe das wie Du. Nur das mit dem “geschnallt” finde ich es etwas merkwürdig. Nur weil Du (und ich) denken etwas wäre richtig, ist das noch lange nicht so.

SimonPoole · 2011-01-26T21:53:00.000Z

SunCobalt:

…Nur das mit dem “geschnallt” finde ich es etwas merkwürdig. Nur weil Du (und ich) denken etwas wäre richtig, ist das noch lange nicht so.

Ich behaupte nicht, dass es “richtig” ist, sondern nur das es unbestreitbar ist, dass das OSM Tagging sowohl die physische Ausgestaltung wie auch die Widmung eine Weges miteinander vermischt… und das das einer der Hauptgründe für die ewigen Popcornrunden ist. Und auch, dass es einige nicht verstehen und es deshalb immer immer immer immer wieder von neuem versuchen irgendwie konsitent zu machen, und dann prompt scheitern.

Ich hab genuegend Abstand, dass es -mir- schlussendlich Wurst ist, solange es in der Praxis halbwegs funktioniert (OSM erzieht einem zum Fatalisten).

Simon

Nop · 2011-01-26T21:58:12.000Z

SunCobalt:

ich wusste doch, es wird lustig. Ich glaube, die Bedeutung von path wird unterschätzt

Ja, Popcorn lohnt sich da jedes mal.

Hat einer “Jehova” gesagt?

bye
Nop