Ist aber information=route_marker nicht das “gleiche”?
Das ist seit 22.12.2013 im WIKI. Ich sehe es auch international. Wie oben beschrieben dient es schon zur Orientierung, wenn ich am Felsblock mit dem roten Punkt angekommen bin.
Wichtig wäre m.E.
eine Vereinheitlichung: route_marker oder trail_blaze - eventuell umtaggen, wobei ich für den älteren Tag stimme.
Im WIKI dokumentieren, das es im Gelände verwendet werden sollte. Eine Verwendung, wie im Beispiel in der Stadt, führt zu “Überinformation”.
Sollte vielleicht auch im WIKI stehen, das es nicht nötig ist, die Zeichen innerhalb weniger Meter zu mappen. Es sollte an Biegungen, Abzweigen oder besonderne Orientierungspunkten eingetragen sein.
Mehrer “route_marker” sind meist an Wegkreuzungen, -abzweigungen an Wegweisern. Dort sollten “route_marker” aber mit den Richtungsangaben entweder in description, inscription oder auch destination stehen.
Ich habe mich damals nicht daran beteiligt. Es ist zwar nett das zu erfassen, damit ließe sich auch sicher eine ganze Menge anstellen,
ich halte das aber trotzdem für eine Niesche. Es ist aufwändig in der Erfassung und Wartung. Gerade in Gebieten mit einer hohen Wanderwegsdichte steigt da die Fehleranfälligkeit der Erfassung.
Was diese trail_blaze/route_marker anbelangt…
die Erfassungsart bei mehreren Markern an einem Ort auch mehrere Punkte zu setzen finde ich danz schlecht.
was man machen könnte, wenn z.B. an einer Lampe oben ein roter Punkt und darunter ein rotes Kreuz prangt:
guidepost, route_marker und trail_blaze sind m.E. Routinginformationen und gehören nicht in die Kategorie tourism=information. Eigentlich müßte man dafür etwas neues definieren, von der Grundidee her in etwa so:
tourism=routing, routing=guidepost
Da man aber 200.000 Objekte (guidepost) kaum umtaggen wird, muss man sich auch mit dem Verbleib von route_marker etc. anfreunden.
Als Auswerter braucht man nur nicht alle restlichen (nach map, board, guidepost etc.) tourism=information in einen Topf zu werfen, bloß damit kein POI durch die Lappen geht. Für’s Taggen bedeutet das, dass tourism=information allein undefiniert ist und als Fehler behandelt werden sollte…
Die 200.000 Guideposts stehen in zumindest in Europa üblicherweise in einem Abstand von 500 Metern bis 5 Kilometern. Die optische “Verspammung” von Karten usw. hält sich damit in Grenzen.
Den gravierenden qualitativen Unterschied zwischen information=board mit einer Landkarte und einem Guidepost mit Ziel- und Entfernungsangabe kann ich nicht erkennen. In allen Gebieten mit “Ostblock”-Wegmarkierungssystem (CZ, SK, PL, RO, teilweise FNL) haben die meisten Guideposts auch einen Namen, der sich traditionell auf allen (Papier-) Wander-/Radwanderkarten wiederfindet, stellen also echte Orientierungsfixpunkte dar.
→ deswegen Guideposts bei tourism=information belassen
Route_marker/Trail_blazes sind typischerweise in einem Abstand zwischen 20 und 100 Metern anzutreffen und tragen keine explizite Zielinformation (nur implizit). Sie spammen das Kartenbild mit "i"voll, wenn der Renderer information=trail_blaze/Route-marker nicht kennt oder ausschließt.
→ hier wäre ich sehr für ein neues Basistagging, tourism=routing, routing=trail_blaze/route_marker gefällt mir als Idee. Damit wäre OSM auch ein attraktives Tool für Wegewarte, und die Wanderwegrelationen würden als Nebeneffekt vielleicht häufiger aktualisiert.
Ist mir aber in Ländern wie PL und SK mit wenigen “Berufsmappern” und vielen Gelegenheitsmappern häufig untergekommen.
+1: Danke für Deine differenzierte Beschreibung der Sachlage! Und auch Dein Lösungsansatz scheint mir eine gute Lösung zu sein.
(Wobei ich immer noch glaube, dass es zusätzlich gut wäre, dass die Renderer das Tag tourism=information etwas differenzierter auswerten, sprich, in der Lagen sein müssen, information=* zu berücksichtigen.)
Die “guidepost” sehe ich auch eher unter “tourism=information” wegen des höheren Informationsgehaltes und der faktischen Verbreitung.
Bei den Wegemarkierungen wäre mir am liebsten, die Renderer würden information=* auswerten, könnte mich aber auch mit einer neuen Top-Level-Kategorie tourism=routing anfreunden, damit die Renderer die potentiell zahlreichen “i” loswerden.
Wie nutzbringend eine generelle Erfassung ist, ist ja ein anderes Thema. Sie wegen Rendering-Problemen auszuschließen, wäre für mich aber ein Systembruch (TfdR).
Zwischen “route_marker” und “trail_blaze” sehe ich keinen wesentlichen Unterschied, da sehe ich den älteren Wert route_marker als intuitiver und international verständlicher an. Da sollte es im Wiki und mittelfristig in der Datenbank keine zwei Alternativen geben.
Sehr schön! Nur leider gibt es ja (wie schon von verschiedenen Seiten gesagt wurde) auch so allerhand Renderer, die das nicht tun, darunter der für unsere allseits beliebte „Hauptkarte“ www.openstreetmap.org verantwortliche … und mit dieser Karte ging dieser Thread ja los.
Ich finde diese Art der Herabwürdigung (“dazuerfunden”) komplett unangemessen und im Übrigen stimmt das so auch nicht. Wenn Du Dir die Geschichte ansiehst ist der tag seit 2010 in Benutzung und steigt seitdem kontinuierlich an, kein Import oder so (ich selbst bin erst viel später auf den tag gestoßen, mehrfach auf [tagging], und habe das daraufhin dokumentiert). Derzeit ist der tag der fünftmeist genutzte für den Key information.
**
Ohne weitere Rückfrage insbesondere auf der tagging ML das aus dem internationalen Wiki zu löschen, nachdem man hier im deutschen Forum darüber diskutiert hat, geht gar nicht.**
Stimmt auch nicht. Wegweiser sind fast dasselbe und sind schon seit Urzeiten mit dabei. Weiterhin muss man auch kein tourism=information zusätzlich an jeden trail_blaze setzen. Für jedes tourism=information ein i auf die Karte zu malen ohne nach einem information-subtag Ausschau zu halten funktioniert schon seit vielen Jahren nicht mehr.
zunächst mal geht es nicht um “einen Einzelnen”, und dass es ein “Fehler” sein soll ist Deine Einschätzung, sowohl z.T. hier im Thread als auch unter der Nutzern des tags wird das anders gesehen.
den Punkt 3 finde ich sinnvoll und 2 ggf. diskussionswürdig, leider hast Du wohl nur den ersten umgesetzt bisher.
Nur leider gibt es ja (wie schon von verschiedenen Seiten gesagt wurde) auch so allerhand Renderer, die das nicht tun, darunter der für unsere allseits beliebte „Hauptkarte“ 
und mit dieser Karte ging dieser Thread ja los.