Wie ihr vielleicht schon gesehen habt, gibt es jetzt eine ausführliche Beschreibung im OsmBlog:
http://blog.openstreetmap.de/blog/2015/07/ferienaufgabe-wanderwegweiser/
Ich hoffe, ich konnte die Vorstellung über das Tagging der meisten hier im Thread und der Umfrage berücksichtigen und hoffe, ihr alle findet euch beim einen oder anderen Aspekt der Aufgabe wieder. Kommentare und Vorschläge sind selbstverständlich immer willkommen.
zum ref:*
Ich selbst habe stets immer ref:hiking=* und ref:bicycle=* erfasst. An einem Mast sind bei und im Spreewald oft zu einen die Wanderwegs-Pfostennummer dran (eine ein- bis vierstellige Ziffer, in der Regel von hinten und oben) und eine Radwanderegenummer (ein Aufkleber von vorn). Gelegentlich sind an diesen Pfosten auch noch emergency=access_point zu finden( mit ref:access_point=)… eine saubere Ref-Unterscheidung ist da sinnvoll.
Ich habe generell immer ref:hiking= ect. verwendet, egal ob da auch Randwanderegweiser mit dran waren oder nicht…
Auch beim Operator-Tag sollte man verschiedenes zulassen: z.B. operator:bicycle=* oder operator:hiking=* … auch eine Auswirkung von unterschiedlicher Verantwortlichkeit der Beschilderung. Bei und im Landkreis ist bei den Radwanderwegweisern der Landkreis zuständig… beiden Wanderwegweisern muß ich nich nachfragen… ich glaube ein Tourismus-Verband… Das ist rechtlich noch nicht so ganz klar. Beide Operator-Tag-Varianten habe ich noch nicht angewendet… kommt aber bald…
Sven
Alle weiteren Tags sind überflüssig. Wegweiser mappt man, weil es als Orientierungshilfe dient, wenn sie in der Karte angezeigt werden. Was auf den Wegweisern draufsteht, interessiert bei der Tourenvorbereitung niemanden. Wenn man angeben will, dass ein Wegweiser Wander-/MTB-Routen kennzeichnet, kann man ihn in die Routenrelation hängen, mit Rolle “guidepost” oder “information” o.ä.
Hi,
Für deinen genannten Anwendungsfall gebe ich Dir recht. Die Möglichkeiten, die sich Routern bieten (“An der Kreuzung Richtung Hintertupfing”) werden in deinem Usecase nicht betrachtet.
Ehrlich gesagt, ist das eine Anwendung, die ich mir beim Joggen mit Knopf im Ohr wünschen würde.
Bitte nicht von einem Teil aufs Ganze schliessen.
Christoph
Falls keine Route vorhanden ist und man selbst etwas plant, ist es hilfreich, was auf dem Wegweiser steht. dann kann man z.B. auch nach dem “Roten Balken” laufen, der nicht als Route eingetragen ist.
Moin!
irgendwie fehlt eine Overpass Turbo Karte.
Habt Ihr noch was zur Hand?
Jan
PS: es wurde von Bildern gesprochen und das man diese im Web ggf. hinterlegen kann. Dann muss aber ein Lizenzhinweis vorhanden sein. Im OSM Wiki wurde ich das aber für unpassend halten.
So eine Ansage ist schon bei der Kfz-Navigation zweifelhaft, weil eine Ansage “in 100m links abbiegen” viel effektiver ist und eine Anzeige am Display erst recht. Bei der Wander-Navigation kommt noch hinzu, dass die Wegweiser meistens nicht genau in die Richtung zeigen, wo der Weg hingeht. Ohne Mitdenken kommt man da leicht vom Weg ab. Da fallen mir unweigerlich die Leute ein, die mit dem Auto in den Fluss fuhren, weil sie blindlings dem Navi gehorchten.
Und spätestens auf Kreuzungen, wo kein Wegweiser steht, wirst du sowieso andere Anweisungen brauchen.
Beim Joggen möchte ich eigentlich die Natur genießen und keinen Knopf im Ohr. Ich weiß schon, es gibt Jogger, die unterwegs Musik hören, aber das sind solche, die jeden Tag die selbe Runde laufen. Die brauchen keine Navigation.
Die ganze Fußgängernavigation ist hauptsächlich ein Bedürfnis von Programmierern und nicht von Anwendern.
Wieso sollte die Route nicht eingetragen sein? Das ist ungefähr so, wie wenn ein Weg nicht eingetragen ist. Ich finde die Vorstellung komisch, dass ein Mapper sich die Mühe macht, zu taggen, was auf den Wegweisern steht, aber zu faul ist, eine Routenrelation anzulegen.
Noch nicht, das wird genauso wie die Auswertung noch nachgereicht.
“In 500m die Autobahn verlassen und leicht rechts abbiegen” - http://www.mapillary.com/map/im/x6vTveO4zdqK3DOB9_1TjQ - Welche Spur ist die richtige?
“In 500m die Autobahn in Richtung Kelkheim verlassen” - Aha!
Wer sagt, dass der Mapper den Verlauf der Route kennt? Vielleicht hat er auf seiner Tour das Hinweiszeichen für diese Route an drei oder vier Stellen gesehen und möchte diese Information mit anderen teilen? Im Gebirge sind die Möglichkeiten das komplette Wegenetz zu erfassen deutlich eingeschränkter, weil die Strecken erheblich länger sind.
Wenn es um die richtige Spur geht, sollte die Ansage lauten: “Auf der zweiten Spur einordnen.” Auf den Überkopfwegweisern steht oft so viel, dass man es gar nicht lesen kann. (Darum gibt es in solchen Fällen meistens Vorwegweiser, damit auch Leute ohne Navi eine Chance haben.)
In 2m in Richtung “Kleiner Anninger - Husarentempel - Grenzweg Waldrast Krauste Linde - Anningerhaus Abzweigung Hexensitz-Kiental” abbiegen. 
Unvollständige Relation mit entsprechendem fixme anlegen und/oder Map Note erstellen.
Man muss nicht alles an einem Tag machen. Nichtsdestoweniger wär es wünschenswert, dass mehr Leute rausgehen und die fehlenden Wege mappen statt am Sessel festgewachsen an bestehenden Daten herumzupfuschen.
Man kann es auch freundlicher sagen. Die Wegweiser kann man jedenfalls nicht vom Sessel aus aufnehmen.
Ich halte es für unökonomisch, lauter Routenfragmente mit Operator, Markierung etc. anzulegen. Das macht man besser für ein größeres Stück auf einmal. Dazu müssen aber genug Informationen über den Verlauf eben auch von anderen Mappern vorliegen.
Wenn du mit den Routenfragmenten meinst, dass für eine Route mehrere Relationen angelegt werden: Das sollte natürlich vermieden werden. Für kurze Routen findet man die bestehende Relation im Editor, für lange Routen (z.B. Weitwanderwege) im Wiki (z.B. für AT: http://wiki.openstreetmap.org/wiki/WikiProject_Austria/Wanderwege)).
Wer Routen vervollständigt, schaut normalerweise nicht auf Wegweisernodes, eigentlich überhaupt nicht auf Nodes, sondern nur auf die Relationen und Wegstücke. Darum wird oft note=* auf die Wege gesetzt (z.B. note=“blaue Markierung”), was völlig ausreicht. Ich habe die Info auch schon in name=* gesehen (z.B. name=blau), was Datenbankfundamentalisten ausflippen lässt, aber für die Anwender besser ist als gar nichts.
Vehementer Einspruch eines Vielwanderers gegen diese These!
Ich benutze das Fußgängerrouting (auf Osmand) fast ebenso häufig, wie das Autorouting!
Beispiel: Ankunft im Wald auf Wanderparkplatz, diesen als Ziel festlegen, dann 3 POI als Zwischenziele eingegeben und nach ein paar Sekunden Rechenzeit weiß ich die Kilometer und Dauer der (Rund)wanderung, und damit ob noch ein weiterer POI eingebaut werden kann, oder die Route zu ambitioniert ist. (Reduziert Stress durch mitwandernde Partnerin enorm! 
)
Noch zum Thema: Sehe (aus meinem Blickwinkel) (noch) keinen Nutzen darin, für die Wegweiser eigene Relationen anzulegen.
Cepesko
Geschmäcker sind halt verschieden. Mein Wunsch ist daher weiter hoffentlich legitim.
Ich glaube, das wird sich ändern. Die Apple Watch routet mit Brummen (Links, Rechts, Schau bitte aufs Display).
Bisher hat mich beim Fussgängerrouting immer das permanente aufs Smartphoneschauen gestört (wenn ich nicht wusste wo ich hinwollte war mir das egal).
Ich bin da auch hin und hergerissen. Die destination:backward / forward Lösung am Way ist simple, hat aber den Nachteil, das ein Join schonmal ein Tag an eine falsche Stelle beamen kann.
Die Relation beschreibt das ganze am Punkt. Die Relationen sind sogar überschaubar, und mit dem teilweise schon vorhandenen Editor Plugins zu bedienen.
Wer nach schon vorhandenen Wegweisern suchen möchte, kann das mit dieser Overpass-Abfrage machen:
http://overpass-turbo.eu/s/apD
Der Farbcode in dieser Version:
graue Ringe: Wegweiser
rote Kreise: Wegweiser mit description-Tag
grüne Kreise: Wegweiser die Mitglied einer Routen-Relation sind
blaue Kreise: Wegweiser die Mitglied einer Relation type=destination_sign sind
Moin !
ich finde das Thema im Grunde ok - und würde auch mit den Relationen arbeiten. Die allerdings noch sehr sporalisch sind.
Wenn man sich auf das Erfassen der Nodes beschrängt und die Richtung an dieses Objekt hängt, dann sehe ich irgendwo noch nicht den Web wie man das jemals auswerten kann.
Vielleicht kann mich einmal jemand überzeugen.
… und wenn das an Nodes gehängt wird, dann wäre es aus meiner Sicht sinnvoller mit einer Richtungsangabe wie bei http://www.openstreetmap.org/node/2607653936
Gruß Jan
Ich habe heute OSM Count ins Rennen geschickt:
http://thefive.sabic.uberspace.de/table/GuidePost_Node.html
OSM Count zählt die Nodes mit information=guidepost, die destination Relationen und die destination “footways” (track, path, footway, cycleway).
Letzteres scheint aber Overpass technisch aufwendiger zu sein.
Anders als bei der Apothekenaufgabe wird hier für die Schweiz, Österreich und Deutschland in einer Tabelle abgefragt. Ich habe aber den Detaillierungsgrad deutlich gröber eingestellt.
Christoph
Edit:
P.S. Bitte beachten, die Daten für eine Tabelle sind erst vollständig, wenn die “Offenen Queries” unter der Tabelle 0 sind.
Irgendwer hat sich diese Tags ausgedacht und ins deutsche Wiki geschrieben - dafür gab es weder ein Proposal, noch gibt es etwas ähnliches in den anderssprachigen Versionen.
Die Namen sind verglichen mit anderen OSM-Keys völlig unpassend - und Informationen über die Richtung gehört eigentlich nicht in den Key, sondern in den Value.
Ich würde diese Keys gerne aus dem Wiki entfernen - aber dazu bräuchte es die Zustimmung von dem einen oder anderen hier.
Warum sollte das entfernt werden? Das ist eine einfache Möglichkeit, Wegweiser und deren Aufschrift zu taggen. Und für “ich möchte kurz den Wegweiser und das was draufsteht erfassen” wurde auch in diesem Thread keine Alternative aufgezeigt. Es spricht also nichts dagegen, Wegweiser solange in diesem Stil zu taggen, bis der Community etwas besseres eingefallen ist. Und dass es im Wiki dokumentiert ist, dass man es so machen kann, ist wohl u.a. Zweck desselben.
Ich zitiere mich mal selbst von weiter oben:
Außerdem gehören nach allgemeiner Ansicht variable Anteile (hier north, south, southeast, eastsoutheast…) nicht in keys, sondern in den Wert - variable Keys sind einfach nicht gut auszuwerten.