in letzter Zeit habe ich Wanderwege in der Schweiz gemappt. Dazu gehörte auch das lokale Wanderwege-Netz. Das sind kurze Strecken, die von einem benannten guidepost zum nächsten führen. Auf den guideposts sind Wanderzeiten angegeben, die ich als duration= bei route ergänzen möchte oder schon ergänzt habe. Dies ist glaub ich, noch nicht so üblich, aber ich denke, diese Information gehört eher an die Route als an den node des Schildes (also so wie bei den Straßenschildern). Irgendwo hatte ich den Einwand gelesen, dass duration bei Wander- und Fahrradrouten nicht so viel bringt, da es von den persönlichen Voraussetzungen abhängt. Da es aber draußen so ausgeschildert ist und jeder Wanderer diese Angaben einigermaßen einschätzen kann finde ich diese Angabe sinnvoll. Macht das sonst noch jemand?
Der eigentliche Grund für den Thread sind die unterschiedlichen Angaben für aufwärts und für abwärts gerichtete Strecken. Ich würde dafür duration:forward und duration:backward angeben. Oder ist duration:uphill und duration:downhill eingängiger? Laut taginfo gibt es das alles noch nicht.
Also ich verstehe nicht so richtig worauf du hinaus willst. Möchtest du angeben wie lange es dauert, ein bestimmtes Stück Strecke bergauf / -ab zu wandern? Ich finde da ist man mit incline besser gehalten. Dann kann noch jeder selbst abschätzen wie lange er für ein bestimmtes Stück Weg in Höhe x mit Steigung y braucht.
Duration finde ich eher bei U-Bahn o. Ä. angebracht, die braucht im Normalfall immer die gleiche Zeit für eine bestimmte Strecke. Da spielen keine Sachen die Wetter, Jahreszeit, persönliche Form, Tagesform, … mit rein wie beim Wandern.
Auf den Wegweisern mag es sinnvoll sein, weil dem Betrachter eines Wegweisers keine anderen Informationen zur Verfügung stehen. Einer Software, die auf Datenbanken zugreift, stehen hingegen alle Informationen zur Verfügung, um Wegzeiten automatisch berechnen zu können (Streckenlänge, Schwierigkeit, mit Laserscan auch Höhenprofil).
Ich finde es nicht so sinnvoll die route-Relation mit der Dauer zu taggen, da jeder sich unterschiedlich schnell zum Ziel bewegt. Eher ist das als Eigenschaft des Schildes zu Mappen, da es da auch steht. Und wie es der Zufall will gibt es auch eine Relation die das beschreibt: destination_sign. Ich will aber gleich mal vorwarnen: Jede Beschriftung ist pro Wegweiser zu mappen, was bei manchen Wegweisern ausarten kann.
Hi,
ich würde die Dauer auch nicht erfassen. In Norwegen sind wir einer gps-track gefolgt, und von vorneherein haben wir mit 6-7 stunden geplant, obwohl die track nur 4:30 lang war. Am ende haben wir tatsächlich 7 Stunden für den Aufstieg und 2,5h für den Abstieg gebraucht. Die schnellsten Schaffen die 1800 Höhenmeter wohl in unter 70 Minuten…
Ist diese Relation denn überhaupt auch mit für Wanderwegweiser gedacht? Ich habe zwar sämtliche Daten der Wegweiser da und vorerst auch mit destination:1 bis x versehen, von der Relation aber abgesehen. Denn da fehlt ein Wert der das genauer eingrenzt. So wie er jetzt ist, ist er für Wegweiser an Straßen gedacht und dürfte, wenn überhaupt, auch entsprechend ausgewertet werden. Unglücklich wenn da nun noch Wanderwegweiser und anderes ungewollt daziwschen ist.
Gegen die Nutzung dieses Relationstyp spricht ansich nichts. Das jedes Ziel in eine eigene Relation muss ist ziemlich aufwendig, nur kann die jetzige API noch nichts besseres. Außer es bastelt einer etwas im Stile des Restrictions Plugins, wo man alles in einer Maske abfrühstücken kann und wenigstens die Bearbeitung vereinfacht wird. Nur wenn wir das für alle Arten von Wegweisern nutzen wollen, sollte da erst einmal ein Unterscheidungsmerkmal her. Denn nicht alle Wegweiser können von allen genutzt werden und die welche man nicht gebrauchen kann, sollte man auch ausfiltern können.
Da müsste z.B irgendwas in der Art wie:
sign_type=hiking für Wanderwegweise
sign_type=tourism für Touristische Beschilderung
sign_type=parking für Parkleitsysteme
usw. rein. Ansonsten haben wir zwar viele Wegweiser mit entsprechenden Richtungen. Die kann aber keiner mehr auseinander halten.
Das gibt es bereits: Im Wiki unter http://wiki.openstreetmap.org/wiki/DE:Key:information findet sich dazu hiking=yes, ski=yes, bicycle=yes. Interessanterweise wird dies dort als “access”-Keys bezeichnet, obwohl es ja eigentlich keinen access-Key hiking=yes gibt, sondern allenfalls foot=yes.
Das ist die Beschreibung am Wegweiser selbst und die ist altbekannt. Hier geht es im die Relation die unterschieden werden muss. Das kann man natürlich auch mit hiking=yes etc. gemacht werden, müsste dort aber mal dokumentiert werden.
Ohne entsprechende Unterscheidung gibt das ansonsten Probleme. Nicht nur das man die Relationen ansonsten maschinell nicht unterscheiden kann, es stehen auch genügend Wegweiser an Straßen und Kreuzungen. Und dort sollen ja, wenn man mit dem Auto navigiert, nur die für das Auto relevanten gelben, blauen etc. ausgewertet, angezeigt, oder angesagt werden. Ungefiltert werden dann aber alle diese Relationen heran gezogen, auch Wanderwegweiser. Die möglichen Konsequenzen kann jeder für sich selber durchspielen.
Natürlich ist die Angabe der Dauer nicht richtig verlässlich, aber es geht hier um das Wanderwegenetz und nicht um regionale oder längere Wanderrouten. Wie gesagt, das geht in der Schweiz von einem markierten Guidepost (http://wiki.openstreetmap.org/wiki/File:Signpost.jpg) zum nächsten. Die stehen dort so nah beieinander, dass die Dauer der Routen nur 5 bis ca. 60 min beträgt. In dem Beispiel sind auch längere Zeiten angegeben, aber wenn die Angaben nicht durch einen waagerechten Strich getrennt sind ist es die gleiche Route, d.h. sie kann in mehrere kurze Stücke zerlegt werden.
=> so große Abweichungen wie in Norwegen sollten nicht vorkommen.
Eventuell kann die Dauer der Strecke berechnet werden, die Höhen der benannten Guideposts sind ja auch gegeben, aber ich glaube nicht, dass das genauer wäre als die Angaben die auf lokalen Kenntnissen beruhen. Außerdem, wie sollen denn bei einer Berechnung die persönlichen Voraussetzungen mit einfließen? Es fehlen auch noch viele Angaben für eine genaue Berechnung, z.B. ein gutes Höhenmodell oder die Schwierigkeit des Weges (wird ja nebenan diskutiert). So lange können doch die ausgeschilderten Daten helfen.
So weit ich es gesehen habe, sind die destination_sign-Relationen nicht für Wander- oder Fahrradrouten gedacht. Ich finde die entsprechende Seite nicht mehr, aber beim Radwegenetz wird empfohlen die Richtungsangaben in verschiedene direction-Keys zu packen (z.B. direction_east=Bassen 5km; Sagehorn 0.3km & direction_north=Fischerhude 7km; Oberneuland 5.8km → http://wiki.openstreetmap.org/wiki/Radwegenetze#Die_Wegweiser-Punkte)
Aber so bekannt ist das wohl auch noch nicht …
Hallo,
ich habe zwar gar keine Ahnung vom wandern, könnte mir aber vorstellen, dass die Angabe der (durchschnittlichen) Wanderzeit sinnvoll ist. So dass man anhand der angegebenen Zeit und den persönlichen Fähigkeiten (und vielleicht noch dem Wetter) eine gute Approximation der eigenen Wanderzeit bestimmen kann. (Besser als nur allein mit Schwirigkeitsgrad, Höhenmetern, Länge und Oberfläche.)
duration:uphill o.ä. find ich nicht so passend, denn was macht man mit einem Weg in der Ebene, oder einem Weg über eine Kuppe mit gleichhohem Start- & Endpunkt. Da Relationen nicht Richtungsgebunden sind könnte man sich bei duration:forward/backward damit behelfen, dass man dem ersten Wegsegment die Rolle “start” und dem letzten “end” gibt. (Bei nur einem Wegsegment einfach Teilen.)
Also die destination_sign Relation ist auch für Wanderer und Fahrradfahrer gedacht, wie sonst erklärst du den (möglichen) Tag time=hh:mm. Das ganze über den direction Tag zu lösen ist eher schlecht, da in eine Richtung mehrere Ziele angegeben werden können und das ganze leicht länglich wird. Mal als Beispiel diesen Wegweiser mit den zugehörigen Relationen angucken, wobei da jetzt hiking=yes noch fehlt. Shame on me.
Um die jeweiligen Arten zu unterscheiden packe ich, wenn ich es nicht wieder vergesse, immer noch ein hiking=yes dran. Fahrradschilder würde ich dann dementsprechend mit cycling=yes taggen. An den Schildern für Autos mache ich normalerweise keine weitere Einschränkungen, da sie normalerweise jeder lesen kann, oder sonst gar nicht in die Nähe kommen kann.
Aber vielleicht wäre es auch sinnvoll das ganze wie geokyf vorgeschlagen hat (also mit sign_type) zu taggen.
Ich finde die oben genannte “Radwegvariante” [1] am Besten. Einfach einzugeben und das Schild kann relativ leicht gerendert werden ohne 10 Relationen auszulesen zu müssen (welche dann aufgrund von serpentinen oder ähnlichem auch zu falschen Pfeilrichtungen führen könnte).
In dem Beispiel sind leider nur die 4 Himmelsrichtungen vorgeschlagen, es ist aber auch z.B. direction_northeast geläufig. (Mir würde es zwar die kürzere Variante mit direction_N, direction_NNE, direction_NE,etc. besser gefallen, aber da ist es wohl zu spät)
Damit, dass diese Relation in der ganzen Welt verwendet werden soll und es möglicherweise in manchen Ländern auch Schilder mit Zeitangaben geben kann. Die gab es hier früher bei uns auch, so einen habe ich mal an einer alten Chaussee gefunden. Da steht nichts von Wanderwegen etc. und Proposal wie Feature beziehen sich auf eine Straße. Wie dem auch sei, ohne dokumentierte und angewendete Unterscheidung, macht man mit anderen Wegweisern eine bereits vorhandene Anwendung, die das für Autonavigation nutzt, definitiv kaputt. Und da reicht auch nicht allein die Farbe als Unterscheidungsmerkmal. Grüne und Braune Wegweiser gibt es sowohl an Straßen und an Wanderwegweisern.
Die Radwegvariante ist für simple Abzweigungen ausreichend, bei komplizierteren Kreuzungen und schlechten Standorten jedoch schon nicht mehr zu gebrauchen. Da ist eine Relation die bessere Wahl. Der ist es egal, ob da 6 Wege aufeinander treffen und das Schild mal wieder ungünstig steht, denn mit zugeteilten Rollen des eigentlichen Weges, der dann dargestellt werden kann, kann es da keinerlei Missverständnisse mehr geben.
