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).
Die sind ja meist auf Podest angebracht (zum Peilen) und heißen da Orientierungstafeln. Ich wüßte nicht, weshalb sie am Boden anders heißen sollten (höchstens noch Boden-…).
Ein Wegweiser ist das nicht, es sei denn, es wird noch weitere Information auf der Tafel angebracht. Das habe ich aber noch nie gesehen.
Sie müssten sich eigentlich immer an einem tourism=viewpoint befinden.
Siehe auch http://wiki.openstreetmap.org/wiki/DE:Tag:information%3Dmap
Danke, Orientierungstafel scheint der richtige Begriff zu sein. Und ob auf dem Boden oder auf einem Podest dürfte wirklich keine Rolle spielen. Was eine Rolle spielen könnte ist, ob die angezeigten Örtlichkeiten sichtbar sind (z.B. sichtbare Kirchtürme oder Berggipfel in der Nähe) oder ob es so abstrakte Dinge sind (wie mehrere tausend Kilometer entfernte Partnerstädte).
Vielleicht spielt es auch noch eine Rolle ob Entfernungsangaben gemacht werden?
Wenn die Updates nicht abrauchen, sollten die Daten nur im Minutenbereich zurückliegen, also genauso wie auf der produktiven Instanz.
Schön wäre es, wenn es den Unterschied nicht gäbe und wir überall die gleichen Antwortzeiten hätten. Aus verschiedenen Gründen, auf die ich hier nicht weiter eingehen möchte, ist das z.Zt. jedoch nicht der Fall.
Die Anmerkung im Github-Ticket zum Thema Email war in diesem Zusammenhang durchaus ernst gemeint.