surface=grass_paver als Mittelweg?
| mcliquid Austria moderator
December 19 |
- | - |
surface=grass_paver als Mittelweg?
Visit Topic or reply to this email to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, click here.
das ist ein spezifischer Wert für geometrische Rasenpflastersteine, passt wohl nicht
Na, dann weißt Du bestimmt, wie man unterschiedliche Oberflächen stattdessen erfasst. Ich bin gespannt.
Das stimmt. In diesem Fall wäre wohl so etwas wie smoothness:middle interessant. Den Fotos nach würde ich aber surface:middle=grass angeben. surface beschreibt ja die oberste erste Schicht. Und da scheint Gras zu dominieren.
Gar nicht, wenn man dazu etablierte Tags wie surface und smoothness, welche in der Lage sind, die Situation sinnvoll zu beschreiben, über die Klinge springen lassen muss.
Habe ich mir schon gedacht. Zum Glück denken nicht viele so, sonst wären wir mit OSM nicht dort wo wir heute sind. OSM entwickelt sich weiter und wird detailreicher. Zu Beginn kümmert man sich um 80% der Probleme. Hat man dafür eine Lösung, überlegt man sich Lösungen für 95% der Fälle und später um den Rest.
Tags wie smoothness:right/left/middle einzuführen ist ja kein Ding der Unmöglichkeit und beißt sich auch nicht mit smoothness.
Bisher wurde left/right halt eher mit links/rechts vom Weg benutzt und nicht auf Teile der Fahrbahn bezogen. Das heißt nicht, dass es falsch wäre, das jetzt zu machen, aber zumindest linker/rechter Teil der Fahrbahn würde man wahrscheinlich eher mit :forward und :backward abbilden.
forward und backward ist halt bei einem einspurigen Weg schlecht. 
@OSM_RogerWilco, wenn du den obigen Weg mit smoothness:right/left/middle=* und surface:right/left/middle=* zupflasterst und dafür smoothness=* und surface=* entfernst, erreichst du genau zwei Dinge:
- Du ruinierst die Kartendarstellung
- Du ruinierst das Routing
der Vorschlag ist in meinen Augen keine Lösung eines Problems und mit der Ansicht steh ich offenbar nicht allein auf weiter Flur, denn surface:right und surface:left wurden bisher keine 100 Mal verwendet.
Wie kommst Du denn darauf?
Also smoothness=* + smoothness:left/right/middle zuzüglich dasselbe für surface …?!? Ist das nicht ein bisschen viel des Guten? Und bringt das wirklich einen Mehrwert? Wer soll denn das für einen Feldweg noch auswerten?
Das frag ich mich auch… Ich für meinen Teil würde es bei dem ohnehinschon extrem subjektiv belasteten und ergänzenden smoothness belassen, ohne irgendwelche left/middle/right/forward/backward-Geschichten…
Etwaige Zahlen der Verwendungen wie
sind hier im Kontext und im Vergleich der Anzahl der bestehenden Wegesegmente von highway=* allgemein sowas von unbedeutend, als daß ich kaum glaube, das es jemals auswertetechnisch fürs Routing hinzugezogen werden und eine Rolle spielen würde…
Im Vergleich hätte man z.B. die selbe Situation bei wenig befahrenen Wegen mit surface=compacted… Dem natürlich Verlauf der Situation geschuldet, kann sich da mitunter auch ein grasbewachsener Mittelstreifen ausbilden… Ein erfasste Situatuion kann dann wiederum nach einem halben oder einem Jahr völlig anders aussehen…
Ich würde surface entsprechend erfassen und smoothness vielleicht eine Stufe niedriger setzen, fertig… Wie gesagt, smoothness betrachte ich als extremst subjektiv und ich könnte das für mich nur einschätzen, wenn ich selbst da langgefahren bin und selbst dann könnte ein Mitfahrer eine andere Meinung haben…
Sven
1 Like
Natürlich wird surface häufiger verwendet, da die meisten Straßen eine einheitliche Oberfläche haben. Letztlich ist eine Angabe von surface für Wege mit unterschiedlichen Oberflächen nicht richtig. Und wenn man dann nach (neuen) Lösungen/Tags dafür sucht, halte ich diese Argumentation für nicht zielführend.
Ich würde surface + surface:middle angeben. Ich sehe jetzt nicht das Problem.
Für mich wurde das bei diesem Weg ein Thema. Da kommen wir halt mit surface nicht weit:
Hier würde ich surface:right + surface:left taggen. Bzw. habe es nach der damaligen Diskussion im Forum auch.
Ok, stimme Dir für dieses Beispiel zu, das ist aber auch eine ganz andere Hausnummer … habe sowas ehrlich gesagt in dieser Form noch nicht gesehen. Das könnte man ja fast als 2 völlig unterschiedliche Wege nebeneinander malen. Wie ist denn das beschildert? Zeichen 241?
Das ist eine Zufahrt zu einer alten abgelegenen Wassermühle (und 2 Wohngebäuden). Ich meine es gab keine Beschilderung und es führt ein Radwanderweg dort entlang.
Unspezifische Tags wie surface=paved oder surface=unpaved können trotz unterschiedlicher Oberflächen richtig sein.
Wenn du noch mal genau liest, was ich bisher geschrieben habe, dann wirst du einsehen, dass ich mit dieser Kombination ebenfalls kein Problem habe.
Hast du nicht: Way: 26840360 | OpenStreetMap
Ups. Erwischt.
Edit: Habe ich jetzt nachgeholt. War gestern nicht am Rechner. Danke für das Heraussuchen des ways! Wen es interessiert, hier ist der Link zur damaligen Diskussion im alten Forum: Weg mit unterschiedlichen Oberflächen pro Fahrspur - wie taggen? - Deutschland (Germany) - OpenStreetMap Community Forum
@GerdP Evtl. hilft dir ja diese Idee weiter bei der Objektivierung von smoothness?
bzw. auf Deutsch und etwas ausführlicher: Radweganalyse per Smartphone | Fahrradzukunft
1 Like
Ist bestimmt eine interessante Idee, werde ich selbst aber vorerst nicht umsetzen, da ich das phone für die Fotos brauche.
2 Likes
Also ich habe so was schon mal vor ein paar Jahren versucht und im alten Forum das Fazit “veröffentlicht”. Nach Lesen des Artikels würde ich das immer noch aufrechterhalten. Ich hatte aber auch eine andere Grundidee. Lass das Ding auf der Tour mitlaufen und werte die Ausschläge am Abend aus.
Problem 1: Wo bin ich wirklich gefahren. Auf dem Geh/Radweg oder doch auf der Fahrbahn?
Problem 2: Man reagiert auf den Untergrund. Umfahren von Schlaglöchern, fahren auf der besseren Oberfläche. Am Abend die Frage, wo war das nur?
Man konnte zwar irgendwie herauslesen, da hat sich was geändert. Aber warum und was das für einen Smoothness-Tag ergibt? Die Methode Popo war plötzlich gar nicht so ineffizient.