Es ist gut und lobenswert, wenn jemand den Mut und die Zeit aufbringt, die Wiki aufräumen zu wollen. Dabei kann sehr vieles vereinfacht und eindeutiger werden.
Im Grunde gibt es ja schon ein Taggingschema für highways. Und da sind auch ein paar Bilder enthalten. Auch die weitergehenden Eigenschaften für tracks, paths u. dgl. und die zugehörigen Eigenschaften (access, surface, smoothness, sac_scale, trail_visibility, mtb_scale u. a.) sind vorhanden. Ich denke, hier sollte erst einmal aufgeräumt werden. Am Besten so, dass - für Neueinträge - nur eine Möglichkeit der Beschriftung existiert.
So lange aber z. B. bei der Oberfläche/surface zwischen Zuständen und Materialien (compacted vs. gravel) [Auch asphalt und concrete sind compacted] kein Einvernehmen herrscht, sehe ich die Vereinfachung in der Wiki leider nicht kommen.
Und selbst wenn wir es in unserem deutschsprachigen Raum hinbekommen würden, es gibt noch einen sehr großen anderen Teil der OSM-Welt.
Ich möchte das Thema nicht weiter strapazieren.
Für mich nehme ich folgende Erkenntnisse aus der Diskussion mit:
Track = Traktor, trackgrade je nach Fahrzeug.
Path = schmaler als Track.
Andere machen es anders, richtig falsch gibt es nur selten.
Die Beispielseiten im Wiki lasse ich so, wie sie sind.
Ich unternehme später einen neuen Anlauf, wenn RTK die Ortsauflösung auf Dezimeter Genauigkeit verbessert und Einvernehmen besteht, wie die Elemente getaggt werden sollen.
Highway=path als generischer Weg ist nur eine halbe Lösung und ich lehne sie deshalb auch u.a. aus genauigkeitsgründen ab, weil man alles bis auf z.B. Wiesen-/Wald-/Bergpfade nach dem momentanen Schema anders viel besser und genauer mappen kann!
Highway=path ist das kaputte Konzept eines generische Weges, wobei da aber, anders als es sinnvoll wäre, alles ab PKW-Breite standardmäßig nicht mehr mit dazu gehört. Weil wenn schon eine generischer Weg, dann doch bitte auch konsequent für alles! Ja, auf der Seite fehlen noch die Beispiele für highway=residential, highway=service, highway=unclassified, etc. … spätestens dann merkt man den konzeptionellen Fehler von highway=path: im Unterschied zu z.B: highway=residential und highway=unclassified, beinhaltet eine einfaches highway=path + lanes=2 + surface=*, etc. nicht mehr die Information das es sich um eine Wohn- bzw. Verbindungsstraße handelt.
Der nicht konsequente Einsatz eines generischen Tags für alle Straßen/Wege führt dann das highway=path-Kozept in puncto Auswertung komplett ad absurdum. da kann man dann also auch gleich zu Gunsten der höheren Aussagekraft (s.o.) auf ein generisches highway=path verzichten. Vielleicht sollte man mal z.B. highway=motorway passend auf highway=path + lanes=3 + oneway=yes + minspeed=60 + access=no + motor_vehicle=yes umtaggen… :D:P
Da ist mir nicht bekannt, wo es mehrheitlich abgelehnt wird. Aus meines Sicht muß man es nur so machen, das man es leicht automatisch ausfiltern kann, also z.B. highway=footway + footway=sidewalk taggen. Alternativ habe ich ja auch schon andere Konzepte wie man das Gehwegproblem lösen könnte, in der Spurmappingdiskussion vorgeschlagen.
+1, auch wenn highway=path neuer als highway=footway/cycleway ist.
Aus meiner Sicht ist tracktype=* auch nur ein Zusatztag zu highway=track.
Gehsteige gehören per se zur Straße. Ein getrenntes Taggen wie oben ist IMHO falsch. Wenn überhaupt dann analog zu straßenbegleitendem Radweg: footway=track. Und bei highway=residential sind die beidseitigen Fußwege default, da könnte man dann höchstens taggen, wenn nur einseitig vorhanden.
Zusatztags beschreiben aber nicht den genauen Verlauf des Fuß-/Radweges und sind zudem auch nicht durch übliche Tags erweiterbar, es gibt die Regel mit ein Objekt in der Realität = ein Objekt in OSM ja nicht ohne Grund. Außerdem ist es für mich kein Unterschied ob der Fuß-/Radweg 20 m oder 10 cm (Bordstein) von der Straße entfernt ist, es bleibt trotzdem ein Fuß-/Radweg.
Bei der aktuellen Entwicklung ist die Frage, ob die Unterscheidung überhaupt noch von nöten ist. Wenn das einzige Unterscheidungsmerkmal zwischen track und path ist, ob ein Traktor drüberpasst (egal ob erlaubt oder nicht). Dann kann man das doch auch mit der Breite auswerten (ab 2m oder ähnlichem).
+1, auch wenn ich path als (temporäre) Beschreibung eines Fuß- oder Radwegs zulassen würde, welche durch foot- oder cycleway ersetzt (und damit genauer spezifiziert) werden kann/sollte.
Man könnte meinen, highway=path wurde (später) eingeführt, eben weil sonst bei kombinierter Nutzbarkeit durch eine genauere Spezifikation mittels highway=footway bzw. highway=cycleway die jeweils andere Nutzungsart ausgeschlossen wird.
Was aber nicht das selbe ist, da bei footway und cycleway die jeweilige Art bevorzugt ist. Gleichberechtigt kannst du so nicht ausdrücken. Wenn dem nämlich so wäre, bräuchte man ja keine Unterscheidung zwischen footway und cycleway machen oder footway mit foot=no und bicycle=yes wäre völlig korrekt.
Die beiden Tags sind halt noch aus einer OSM-Zeit, als man in dieser Hinsicht noch bei schwarz und weiß war. Das es aber viele grautöne gibt, die man damit nicht oder nur sehr umständlich lösen kann war damals noch nicht so im Fokus. path trägt genau dem Rechnung.
In der Mehrheit der Fälle ist doch schnell klar, ob ein highway=footway oder highway=path ist. Für mich ist alles, was mehr oder weniger ungeplant an Wegen entstanden ist, ein path und wenn der Weg dann später ausgebaut/asphaltiert/ständig zugänglich gehalten + vielleicht beschildert wird, dann hat er den gle4ichen Status wie ein von vornherein geplanter Weg und ist dann highway=footway. Ja, bestimmt kann man da auch über Grenzfälle von Berg- und Waldwegen diskutieren, aber meistens sollte es eindeutig sein.
Fuß-, Rad- und Reitweg haben jeweils unterschiedliche Kriterien ihrer Beschaffenheit. Fußgänger können auf Radwegqualität gehen, Radfahrer nicht immer auf Fußwegqualität.
Meines Erachtens ist das Problem, dass foot- & cycleway die Berechtigung implizieren (=designated). Wenn dies nicht der Fall ist, kann die Art des Weges mit highway= und die Berechtigung mit foot/bicycle=* angegeben werden.
Die Definition zu Ändern sollte kein großes Problem darstellen, da es sich nur um Feinheiten handelt.
[Dann muss man nur hoffen, dass niemand highway=footway foot=no bicycle=designated für einen unterirdisch schlechten Radweg taggt ;)]
Für mich impliziert highway=footway nur foot=yes und highway=cycleway nur bicycle=yes. Weil wenn das *=designated implizieren würde, wie stellt man denn dann einen nicht explizit ausgewiesenen Weg dar, die ja nun mal überwiegen dürften? Ich handhabe es jedenfalls so, das bei mir designated noch mal extra was Besonderes ist, was dann auch explizit getaggt wird. Im Wiki steht wie üblich viel und nicht alles davon ist auch logisch oder sinnvoll. Man sehe sich doch nur mal an, wie viele Leute z.B. highway=footway auf nicht explizit beschilderte Fußwege taggen. Daran sieht man doch klar, wie es oftmals verstanden wird.
@MasiMaster: Weder highway=cycleway, noch footway noch path noch track implizieren irgendeine Oberflächenbeschaffenheit. Zeigt aber schön einen Teil des Problems auf.
Zu den Access-Implizierungen:
Default-Access-Value: bei highway=cycleway ist bicycle=designated, in Deutschland yes oder designated (laut wiki: depends, designated only with sign 237)…ja was denn nun???
josm-Vorlage: bicycle=designated
highway=cycleway: bicycle=designated
Meine Erfahrung in der Praxis: alle Wege, die der Mapper mit dem Rad befahren ist sind cycleway, ergo eher ein bicycle=yes und foot=yes
Manche Mapper sagen aber auch noch: cycleway ist es nur, wenn es auch eine schöne Asphaltdecke hat usw…
Wie soll man daraus jetzt etwas sinnvolles ableiten?
letztlich bleibt einem nur übrig alle (footway, cycleway und path) gleich zu setzen und foot=yes und bicycle=yes als default zu nehmen oder aber man schließt viele Wege für die andere Gruppe aus, die egtl. völlig legal genutzt werden dürfen.
Das ist vollkommen richtig Chris, aber es gibt unzählige highway=cycleway, die man legal zu Fuß nutzen darf, die aber kein foot=yes haben. Gleiches auch nadersrum mit footway und der Nutzung als Radfahrer.
