From OpenStreetMap Wiki
Jump to: navigation, search

a guidepost's name ?

Some people are setting names written on guideposts as tag name=* on the guidepost point itself, and I believe this isn't the best way to do as in most cases that I know, the name written on the guidepost isn't the guidepost's name, (Are there really named guideposts ?), but the name of a real life feature nearby. Tagging the feature nearby is of course a good idea in addition to the guidepost, but shouldn't the guidepost have no name ? Should this wiki page warn about this fact and say that only in the rare cases where the guidepost truly as a name ont it's own should it be tagged with name=guidepost of hell. ? sletuffe (talk) 18:25, 23 November 2014 (UTC)

The name tag is the best place to put this information. In most cases the routes and guideposts form a system, and some human way to refer to its elements is needed both on the ground and in the data. How do you refer - in text, speech - to guideposts if there is not a name? And copying verbatim what's written on the physical feature is IMO the right way to make the system stay useful, as that is will be used by texts and people speaking about the guidepost. Of course if there is no name on the guidepost, then name should stay empty, but that's not the argument here. Pragmatical approach overrules semantic optimality, in OSM, I think... Vladimír Slávik (talk) 11:00, 14 October 2015 (UTC)

bicycle=yes conflicts with access tags

See Talk:Radverkehrsnetz_NRW#Tagging_der_Pfostenstandorte (German). I think I would prefer guidepost:bicycle=yes to serve the case of guideposts for different usages (just like it is described now on this page – hiking=yes, bicycle=yes or ski=yes – but just with a namespace prefix). --Aseerel4c26 (talk) 02:29, 13 February 2015 (UTC)

Can you give an example for a collision in meaning? Within the scope of highway=*, hiking=yes, bicycle=yes or ski=yes are used to describe access restrictions, true. It might be possible, but imho it's very unlikely that guideposts themselves are access-restricted, aside from the highways that lead to them. Thesis: In the majority of cases it does not make sense to tag access restrictions on a node attributed information=guidepost, thus it is ok to reuse these keys in a different semantic meaning (as it's a different scope), in short:
scope key semantic meaning
highway=* bicycle=*, .. tags access restrictions
information=guidepost bicycle=*, .. tags targeted audience
There might be reasons to still prefer the namespaced versions, only saying that I do not see a conflict with access tags. --Cmuelle8 (talk) 04:39, 22 March 2015 (UTC)
Also note that you seem to have mis-cited Talk:Radverkehrsnetz_NRW#Tagging_der_Pfostenstandorte, the page pledges to use guidepost=bicycle instead of a namespaced version (and as an alternative to bicycle=yes). --Cmuelle8 (talk) 07:12, 24 March 2015 (UTC)

Hiking time - Proposed feature

Guideposts contains useful information about the time to a destination. It would be interesting to find a way to enter this information in OSM. We have a way to add width in metres to paths, but not the actual time needed to walk it, which for hiking paths can be highly variable.

Times, distances and further details can be included in Relation:destination_sign. --Mueschel (talk) 08:17, 2 October 2017 (UTC)

Road signs also, or only hiking/cycling/skiing?

The introduction on this page clearly states "Guideposts are often found along official hiking/cycling/skiing routes to indicate the directions to different destinations". But the same kind of destination signs (though not normally called "guideposts") are also very common on (car) roads, highways, etc. Should this tag also be used for those direction signs, or should this tag only be used for direction signs for hiking/cycling/skiing routes? Either way this needs to be specified on the page. --Pbb (talk) 23:35, 1 October 2017 (UTC)