Ferienaufgabe "Wanderwegweiser"

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.

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.

Ja, für die beiden produktiven Instanzen ist das aktuell die einzige Option, ansonsten siehe meine Antwort zu Ticket #224 auf Github.

Gruß,
mmd

Das Wanderwegweiser-Thema ist ja weit…

In letzter Zeit war ich auf verschiedenen Wasserwegen unterwegs… einmal dienstlich eine 3½ Stunden Kahnfahrt durch den Unterspreewald (dienstlich :smiley: 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.Ä. )?

Vorschlag: tourism=information + information=guidepost + boat=yes

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.

Sven

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).

Christoph

Ich würde hier einmal fragen: http://forum.openseamap.org/

Oder hier einmal suchen: https://wiki.openstreetmap.org/wiki/OpenSeaMap/Buoys

Ich schaue mit das mal genauer an…

Hier Beispiele:

  1. Spreewald: auf einem Pfahl montierte Wegweiser, stehen an Land:

  2. Schwielochsee: fest im Seeboden verankertes Rohr, darauf Wegweiserschild:

Gesamtsituation: Geschwindigkeitsschild im Bereich der Fahrrinne mit Wasserski-Zeichen (und Möwe), rechts gelbes Rohr mit Wegweiser

Sven

User TSM1904 hat hier eine interessante Frage aufgeworfen: http://forum.openstreetmap.org/viewtopic.php?id=31964

Ich gebe sie mal hier weiter: Wie heißt das Ding in deutsch und ist das ein “Wegweiser”?

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.