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.
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
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.
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.
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.
Es wird ja am node des Wegweisers nicht das Ziel bezeichnet - es wird der Wegweiser selbst beschrieben und die Richtung in die er zeigt.
Für eine Zielbezeichnung am Weg gibt es destination, aber das ist eine andere Baustelle.
Es wurde immer noch keine Alternative dazu dargestellt. Wenn man abwartet, bis das super-duper Datenmodell entworfen ist, kann man es auch bleiben lassen. So funktioniert OSM nicht. Man macht was, auch wenn es noch nicht super fertig modelliert ist und wenn es das dann ist, kann man das alte Zeug umtaggen und mit dem neuen weitermachen.
Und wer mit 8 Himmelsrichtungen nicht klarkommt, muss sich ja nicht drum kümmern. Es sind nur Wegweiser.
Na dann ist es ja “description” - und da die Richtungsangaben beschrieben werden “description:destination”.
Mit “direction” wird nicht die Richtung angegeben, in die der Wegweiser zeigt, sondern die Richtung in die seine Vorderseite weist. Bei Verkehrszeichen hat das schon öfter zu Missverständnissen geführt.
Selbstverständlich. Destination am Weg macht exakt die gleiche Arbeit und wird von Software problemlos verstanden. Wenn es umbedingt am Wegweiser sein muss, dann der etablierte Key description. Aber in keinem Fall ist eine Zielangabe eine “direction”.
Das mit der destination hab ich erstmal drangegeben. #OSMCount arbeitet normalerweise mit timestamp in der Abfrage, das ist hier aber so aufwendig das es zu timeouts kommt. Ich werde das mit dem timestamp rausnehmen müssen.
In letzter Zeit war ich auf verschiedenen Wasserwegen unterwegs… einmal dienstlich eine 3½ Stunden Kahnfahrt durch den Unterspreewald (dienstlich mit Radtour durch den heimatlichen Spreewald) und dann eine 2-Stunden Schiffstour auf unserem Schweineloch (= Lokaler Name mit Augenzwinkern für den Schwielochsee) Auf, bzw. an beiden Bereichen stehen auch Wegweiserschilder… Bilder liefere ich nach.
Im Spreewald sind es blaue Zeigerschilder mit weißer Schrift an Wasserwegkreuzungen und auf dem Schwielochsee grüne rechteckige Schilder mit weißer Schrift und dann auf eigener Boje oder Pfahl im Wasser (See hat durchschnittliche Wassertiefe von 1-4 Meter).
Das FreieTonne-Tagging sagt dazu speziell auf den ersten Blick nichts aus…
Also Frage: wie mappt man Wegweiser auf Wasserflächen (als Grund-Tagging ohne description o.Ä. )?
Das zieht natürlich auch in der Auswertung eine entsprechende Dateiverarbeitung nach sich… aber das ist nun eben mal so wenn die Datendichte- und Fülle steigt.
Danke, ich habe meinen OverpassURL Mechanismus flexibler gestaltet, und kann ihn nur pro Aufgabe definieren, und gleich das release 0.38 rausgehauen. Das sieht besser aus. Damit stammen diese Daten natürlich aus einer Development Test Umgebung und könnten schonmal 1-2 Tage hinterherhinken, aber das ist ja besser als nix.
Der Geschwindigkeitsunterschied ist aber enorm (nach den ersten Tests).
)
mit Radtour durch den heimatlichen Spreewald) und dann eine 2-Stunden Schiffstour auf unserem Schweineloch (= Lokaler Name mit Augenzwinkern für den Schwielochsee) Auf, bzw. an beiden Bereichen stehen auch Wegweiserschilder… Bilder liefere ich nach.
