Ich würde sagen der Eintrag im Wiki ist in der Tat falsch.
Der Wert trail_blaze wurde erst am 18.2.2016 dazuerfunden. Soweit ich erkennen kann ohne jede Diskussion oder Abstimmung. Vorher - und auf der deutschen Seite immer noch - sind nur zusammenpassende Werte genannt.
Dabei wurde der Fehler gemacht, das Schema inkompatibel zu erweitern. Alle anderen Tags sind für das Makromapping von großen Objekten (Infobüro, Wandertafeln etc). Allen gemeinsam ist, daß es große Objekte sind und daß es Sinn macht sie zusammengefaßt als “i” für Touristeninfo auf Karten darzustellen.
Da wurde jetzt einfach ein Wert für extremes Mikromapping von zentimetergroßen Wandermarkierungen dazugeschrieben. Das paßt eben logisch überhaupt nicht dazu und versaut alle existierenden Karten.
Es im Hauptstil anzupassen ist technisch nicht so einfach möglich. Mit einer neuen Renderregel ist es nicht getan, sondern Du brauchst eine Datenbankänderung da der Tag information=* bisher nicht verfügbar ist - wurde ja auch nicht gebraucht.
Abgesehen davon finde ich es auch nicht sinnvoll, für den Fehler eines Einzelnen im Wiki allen Kartenrenderen Arbeit zu machen, um das wieder auszubügeln.
Die Daten wieder zu entfernen ist auch nicht zielführend. Wandermarkierungen entsprechen der on-the-ground-Regel und halten sich nach meinen Erfahrungen Jahrzehnte. Manche direkt auf Bäume gemalte sind inzwischen auf dreifache Größe angewachsen. Ich würde sie zwar weder mappen noch anzeigen - aber das trifft für viele andere Mikrodetails ebenfalls zu.
Mein Vorschlag wäre:
Wiki korrigieren und den unpassenden Wert für Trailblazes wieder entfernen
neues, eigenständiges Tag für trailblazes definieren und bereits mikrogemappte Schildchen automatisch umtaggen.
auf jeden Fall muß das logisch falsche Obertag “tourism=information” von den kleinen Schildchen entfernt werden, das alle bestehenden Auswertungen versaut
da es aber ni um Qualität sondern um eine Fehde geht, ist das bei uns immer noch falsch drin
Zitat:"Edit: gestrichten, da inzwischen klar geworden ist (danke malenki), daß es in diesem Faden nicht um Ratschläge zur Erfassung geht, sondern um die bekannte sächsische Privatfehde" https://forum.openstreetmap.org/viewtopic.php?pid=379874#p379874
Ich erweitere die Diskussion mal: “information=guidepost” paßt m.E. ebenfalls nicht so richtig ins Schema “tourism=information” … ist nämlich auch nichts anderes als eine Routenmarkierung.
Dann wird es aber schwierig mit der Abgrenzung, denn ein Wegweiser ist eben auch eine Information für Wanderer/Rad-/Skifahrer.
Man müsste dann in etwa definieren:“tourism=information” sind alle Informationen außer Wegweisern und Wegemarkierungen.
Etwas ketzerisch würde ich sagen: Die Unterscheidung wird gemacht, weil die Renderer sonst zu viele “i” setzen.
Es gäbe dann so was wie tourism=information und tourism=guiding_information. Sehr logisch sieht das nicht aus.
…auch richtig. Aber die information=guideposts haben die “normative Kraft des Faktischen” auf ihrer Seite: Laut Taginfo schon >200.000 Mal verwendet. Dagegen wurde trail_blaze/route_marker nur >8400 Mal verwendet. Da lässt sich noch was retten.
Jo, aber wenn ich information=guideposts akzetiere (Farbkleckse auf Bäumen) dann kann man auch information=trail_blaze (kleine Schilder mit Nummern) akzeptieren. Häßliche Is auf Karten die information=* nicht auswerten machen beide.
Stimmt so nicht.
information=guidepost sind die ausgewachsenen Wegweiser mit textuellen Zielen und Richtungsangabe(n), meist mit Entfernungen.
Die Kleckse laufen unter trail_blaze/route_marker (http://wiki.openstreetmap.org/wiki/Tag:tourism%3Dinformation).
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.
Ich würde sie zwar weder mappen noch anzeigen - aber das trifft für viele andere Mikrodetails ebenfalls zu.
und mit dieser Karte ging dieser Thread ja los.
