Talk:Tag:information=guidepost

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)

That pragmatical approach you talks of in this case creates a usage problem. When renderers/searchers try to make use of names on guidepost, a repetition will be seen on the map[1]/search result[2] . And when the feature and the guidepost are quite far of, that might makes it ambiguous to where the real feature is. As a result renderers/searchers creators will tend to just ignore name on guidepost making the contributed name on the guidepost useless. Your most basical "pragmaticality" : setting a name so that it can be seen fails in that regard and the contributor will wonder what he has done wrong or just wont be aware and will not enter it on the feature.

The "standard" map of OpenStreetMap and most maps listed on Hiking#Online-Maps do not show guideposts's names (and some other like Osmand will duplicate text).

Can we at least, if not remove the suggestion to add name to guidepost, remind the contributor that he should also make sure to add the real feature and its name because it might not always be taken into account on the guidepost ? sletuffe (talk) 11:43, 14 November 2017 (UTC)

I agree with your standpoint, but I can also see how it in some situations can be very tempting. Let me illustrate with some increasingly grey area examples. Few people would probably complain that this information plaque would get "Fire in the Guadalupes" in it's name field, since it's quite unambiguous. Then take this map board, still a clear name/title on it but "Kings Weston Estate" does duplicate the name of the actual area. Finally take this guidepost which only serves on direction. If someone would agree with the name for the first two examples, then it becomes hard to deny the name on this last example. --Pbb (talk) 11:35, 22 November 2017 (UTC)

Your first example board is a board where I would even less put a name tag on ! That's the title of an information text on a board, IMHO it has few to do with "the name of the board". Other example to understand my point : Would anyone put "name=Welcome to the city of Denton" on this tourism=information + information=board : [3] ?

As I understand it, the name of something is what you'd use to say "I've been to 'Fire in the Guadalupes'". I've been pointed to the key inscription=* wish would imho be more suited to handle "what is written on board/guidepost/whatever" sletuffe (talk) 13:24, 22 November 2017 (UTC)

inscription=* would certainly have been better than key than name=*, but i'm unsure if it's worth changing this mistake and if the majority would support it. There are already 100k+ guideposts with name=*. Unfortunately, i've also mapped 100+ of it, because i used the editor presets and didn't think much about it. :( --SelfishSeahorse (talk) 20:14, 28 April 2019 (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)

Proposal

I think the current sentence "To describe the access to the shown routes use the access-keys e.g hiking=yes, bicycle=yes or bicycle=yes." causes unnecessary confusion and aversion against using hiking=yes etc. on guideposts. To avoid this I propose to change this sentence to: "To describe the type(s) of routes the guidepost provides information about use the tags hiking=yes, bicycle=yes, ... On guideposts these tags don't describe the legal access to them. To make this explicitly clear instead of e.g. hiking=yes you can also use guidepost=hiking or guidepost:hiking=yes, though this is less widely supported by data consumers and adds no additional meaning."

Compare rexts in Key:access and DE:Tag:information=guidepost.

Is anyone againt this proposed change or does anyone have a better idea? --Hufkratzer (talk) 03:39, 26 January 2018 (UTC)

I don't like this idea. If you introduce these special keys for guideposts, you also have to introduce new ones in many other cases. Adding a statement on a Talk page for just 5 days is not actually a good way to introduce new tags that affect many data consumers. I doubt that there is any tool able to interpret these new tags and there these 50 occurences seem all to have been added by single user 8 years ago. --Mueschel (talk) 23:13, 31 January 2018 (UTC)

Which new tags? I thougt they all were used already and just wanted to document that. --Hufkratzer (talk) 00:28, 1 February 2018 (UTC)

P.S. I am not using the more complicated versions myself, I just wanted to make clear that the tags used here are not "access tags" because some people "feel pretty icky reusing the access=* tags"; the most used tag here is hiking=* and this is not defined in access=* --Hufkratzer (talk) 01:16, 1 February 2018 (UTC)

guidepost:hiking - exists 50 times, all added 8 years ago by a single user. guidepost:bicycle - used 500 times, almost all in the Stuttgart region, added 7 years ago by a single user. No other guidepost:TransportationMode are in the database. Compare to guideposts with 'hiking': 124,000; 'bicycle' 37,000. To me this sounds like a discontinued tagging scheme that should be changed to the much more common version. I'm doing quite a lot with these data, but actually wasn't aware these keys even existed up to now.

Yes, that looks really bad for these tags and I wouldn't be sad if they were removed here, but compare to access:*=*: access:foot=* is used less than 1000 times and access:bicycle=* less than 400 times (compared to about 4 millions for foot=* and for bicycle=*), and nevertheless the access: prefix is mentioned on page Key:access for clarification; I just did it the same way. -Hufkratzer (talk) 13:05, 1 February 2018 (UTC)

These access:* are a bit strange as well - check http://taghistory.raifer.tech/ - 80% of them were added in 2014, and the amount is constant since then. I would propose a slightly more "negative" mention of these tags, something along the lines "few people ... less common and not widely supported"

done --Hufkratzer (talk) 20:57, 1 February 2018 (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)

As you say, since "direction sign" in english would probably be used for road directional signs, and since "Guideposts are often found along official hiking/cycling/skiing routes" has been there since the beginning, it might be that those guidepost weren't intended for roads ones. I've tried to check usage where I live (french alps) and it seams the massive usage is for mountain hiking guidepost.

I would vote for defining a information=direction_sign for roads ones, but I woudn't be hurt either if guidepost were extended to cover roads as well with some road=yes tag. But as you ask, let's make it clear on the page either way. sletuffe (talk) 12:17, 14 November 2017 (UTC)

I believe a decision needs to be made here. I want to start tagging signs in Ireland (they are used a lot in rural areas and very helpful for routing). For now I'm going to use information=guidepost for the physical sign as there is zero usage of information=direction_sign.

It seems rather rare to use information=guidepost for road motorized traffic at the moment. It's preferable to tag the content (i.e. destination tags or destination_sign relations) instead of the sign itself - this makes it easier for any software to pick the correct relevant information. It's the same thing we also do for other traffic signs (maxspeed) - we mostly don't tag the signs, but the restrictions they make. --Mueschel (talk) 14:18, 17 July 2020 (UTC)

Should I read that as meaning that the 'sign' member of a Relation:destination_sign is optional or even desirable not to use? Dónal (talk) 09:01, 20 July 2020 (UTC)

Yes, the sign member is optional. You can add a node if you like but it is not required. It's usage is rare but by no means deprecated or forbidden.

Mapping multiple signs on the same post

The current wiki entry is ambiguous about how to map multiple signs attached to one physical post. On the one hand, it seems to suggest combining all the destinations into the name tag. On the other hand, Relation:destination_sign suggests that all signs pointing in the same direction have the same colour.

urban/frontcountry trail/path signs <> backcountry guideposts

conspicuously absent from OSM features/tags is a means for documenting urban path signs like this one near I-25 in Westminster, Colorado. The brown sign names the city, the trail (I25 Trail) and names the Big Dry Creek trail ahead at the T, with Thornton in one direction and Westminster in the other. Quite unusually, it also lists the sign ID (I2) for 911 emergency location reporting. (Separate issues for sign-makers: the bridge and creek it crosses are not named explicitly. Also, if it's official city open space (seems likely), it does not name the actual property. Note it shows no distance information/milemarker, as is generally expected on "guideposts".) To the point: how do you label this sign - and others like it? DougGrinbergs (talk) 04:31, 18 April 2021 (UTC)