Proposal talk:Guidepost
Signpost
Is there any particular reason you've picked the word 'guidepost'? In UK English, at least, 'signpost' feels like the natural word for this feature (and seems to have about 5x the number of Google results). If this applies more widely (US English, other languages perhaps), then I think amenity=signpost would be better. Great proposal though - I'd use this! Frankie Roberto 22:22, 27 July 2009 (UTC)
Route and destination information
I agree we need a way to incorporate Guidepost information into OSM. But I wonder if we shouldn't merge and integrate this discussion into proposed relation Destination_Signs? I think we need a more flexible structure to integrate arrow information into OSM, not only Guidepost name and elevation. We also should add walking time information in some way, as (contrary to distance information) there is easy no way to calculate this information from other data. --Kaitu 00:53, 18 December 2008 (UTC)
I support this guidepost proposal. As someone has already said, they're very important for orientation in outdoor. It would be nice to have all sorts of additional information attached, but still the most important information is that they're there. --Kaspi 15:40, 4 February 2009 (UTC)
+1 for support this guidepost proposal.
but there should be additional (optional) tags like:
type=[hiking|bicycle|...]
route:[Number]=[Name of a route]
operator=[the organization which take care about the guidepost]
time:[to place/point/name]=[Number] --> the time on the guidepost to a place in houres
distance:[to place/point/name]=[Number] --> the distance on the guidepost to a place in km
why we need this information?
for excample because you can later make the relations for the hiking-routes (you see which routes cross this crossing).
example(go to edit to see the guidepostpoint
--fossy 18:33, 18 March 2009 (UTC)
- I agree that as much as possible of the information content of the Guidepost should be included. We should consider that a single guidepost often provides individual information (time, distance, route, etc.) for several different destinations, and it's difficult to add all this information to a single node. Otherwise I don't think it's advisable to add a guidepost node for each destination (as there is physically only one guidepost). I therefore suggest to use a single guidepost node, adding all the tags which are relevant to the guidepost as a whole, like:
- name
- elevation
- operator (the organization which takes care about the guidepost)
- name
- We then use a relation for each destination indicated on the guidepost, and include the guidepost node as a member of the relation. All the information which is unique for a destination goes into the relation. If the guidepost provides information for several routes to the same destination (that is, it has more than one arrow with the same destination name), we just add one relation for each of the indicated routes. Example:
- Tags
| Key | Value | Explanation |
|---|---|---|
| type | guidepost | indicates that this Relation represents a guidepost destination sign. |
| destination | a name | the name of the destination, as it says on the sign. |
| route_name | a name | the route name, as it says on the sign. |
| route_type | bicycle/mtb/foot/ski/... | indicates the type of route. |
| ref | a reference | The route is known by this reference. |
| operator | operator name | The route (not the guidepost!) is operated by this authority/company etc. |
| time | a number | The time on the guidepost to a place in hours. |
| distance | a number | The distance on the guidepost to a place in km. |
| symbol | a text | Describes the symbol that is used to mark the way along the route |
| bearing | number (range 0-360) | The direction the guidepost arrow is pointed to (not the bearing to destination point!) |
- Members
| Way or Node | Role | Recurrence? | Comment |
|---|---|---|---|
 |
guidepost | exactly one | The node corresponding to the guidepost. |
 |
to | optional | The destination |
  |
route | optional | The path to destination (a way or a relation of type route) |
|
via | optional | A hint about the path to destination |
- --Kaitu 18:27, 20 May 2009 (UTC)
- Most of the route information (route type, symbol, name) is already contained in the route relation. So it should be enough to add the route relation to the signpost relation. Apart from that generally there's no destination for a route as it's connecting the location A and B without direction. --Grille Chompa 14:49, 15 May 2009 (UTC)
- Good point, we should add a route relation, whenever this is possible. I modified the proposal to include the possibility to add a relation of type route, with role 'route', to the members of the relation of type guidepost. If a relation of type route is added to the members of the relation of type guidepost, and this route relation already contains pieces of information which are shown on the guidepost sign, I agree it's unnecessary to add this very same information as tags of the guidepost relation. We should also consider the case when we want to add to OSM the information contained in a guidepost, but no relevant route relation is already inserted in OSM, nor we can add it (that is we can read the guidepost and the information it provides about a route, but we just don't know anything more about that route). In this case we have no alternative than to add this information as tags for the guidepost relation. With the tag 'destination' I wish to include the name which is on the arrow of the guidepost. For example, let's consider the picture on the guidepost proposal page, on one of the arrows are written the names of three destinations (namely: Spitzmoos, Regelstein, Egg). I would add a relation for each of those destination, and for each of these relations assign the relevant name, as written on the guidepost arrow, to the destination tag. It's not necessarily the terminal destination of a route, but the destination indicated on the guidepost signal. For example, a guidepost could offer the times to several intermediate destinations along the same route, and each of those destinations has its own name.--Kaitu 18:27, 20 May 2009 (UTC)
- I like this proposal with using a relation. Should it maybe moved to the main page ? I collected quite some information a a recent hiking tour an will try to map them in the next days. That should give some information on the usability of the proposal. --Behrica 08:06, 19 May 2009 (UTC)
Re "The route (not the guidepost!) is operated by this authority/company etc." above, shouldn't that be "operator:route" or similar? There ARE many organisations that operate guideposts, so leave "operator=" for those (presumably as originally intended?). SomeoneElse 14:01, 31 January 2011 (UTC)
- The organization which operates the guidepost can be specified with the "operator" key on the tags describing the node representing the guidepost. As the guidepost node is a mandatory member of the proposed guidepost relation, I deem unnecessary to repeat the very same information as a guidepost relation tag. The organization which operates the route could be specified in the tags of the relation describing the route, in which case it would actually be unnecessary to repeat the same information as a guidepost relation tag. But the route relation is only an optional member of the guidepost relation. That's why I was suggesting that, until a route relation becomes available to be inserted as member of the relation, the operator of the route could still be inserted as a guidepost relation tag. There would be no conflict with the "operator" tag on the guidepost node. Still, we could well rename this key to "operator:route" if it helps preventing confusion.--Kaitu 18:20, 31 January 2011 (UTC)
Operator or context?
In Norway we have signposts for hiking (blue text/arrows) and skiing (red text/arrows). These are not only operated by two organizations, although they typically are in the Oslo area. Should there be an option to specify its usage or context in order to filter signposts that are not relevant? E.g. to create skiing maps with relevant signposts displayed. vibrog 21:02, 1 January 2009 (UTC)
- Yes, context might be very important. I've seen distinct guideposts for hiking, cycling, cross-country skiing, snowshoes walking etc. --Kaspi 15:40, 4 February 2009 (UTC)
Rendering
| symbol | description | rendering example |
|---|---|---|
 |
used on mountain maps of the german alpine club DAV, nearly the same symbol is used on czech hiking maps of KČT (Czech Tourist Club, the originator of the markings) | |
 |
cross is used in czech hiking maps of SHOCart | 
|
 |
| |
 |
| |
 |
I like this proposal and think we should only decide on the symbol for the renderer. My favourites are and , but I can live with any unambiguous symbol.--JND 18:02, 14 January 2009 (UTC)
- Whatever else than the cross. --Kaspi 15:40, 4 February 2009 (UTC)
- My favorite is the
. I do not know, if we could use the 
becouse of copyrights by DAV.
- oh, people, please stop this stupid voting and just use the symbol that is already widely used for decades ... do we really have to reinvent the wheel? - and btw, no copyright prevents us from using DAV-like symbol --Kavol 11:16, 5 August 2009 (UTC)
To see what is in your opinion the best icon, please use this table.
| User |
|
|
|
|
|
|---|---|---|---|---|---|
| Kaspi 15:16, 2 April 2009 (UTC) | + | -- | + | ++ | 0 |
| JND 18:02, 14 January 2009 (UTC) | ++ | 0 | 0 | ++ | 0 |
| Vsandre 13:20, 13 February 2009 (UTC) | + | - | 0 | ++ | -- |
| Vrabcak 07:58, 22 February 2009 (UTC) | -- | -- | 0 | ++ | - |
| Nop 13:07, 14 March 2009 (UTC) | -- | -- | - | ++ | + |
| DRibagnac 12:25, 8 April 2009 (UTC) | -- | -- | ++ | + | - |
| Behrica 17:18, 7 May 2009 (UTC) | -- | -- | + | ++ | - |
| Grille Chompa 14:51, 15 May 2009 (UTC) | -- | -- | 0 | ++ | + |
| T-i 20:38, 15 May 2009 (UTC) | -- | -- | + | ++ | - |
| Theonlytruth 14:37, 30 June 2009 (UTC) | -- | -- | + | ++ | - |
| Phono 21:56, 3 July 2009 (UTC) | -- | -- | ++ | ++ | 0 |
| Kavol 11:16, 5 August 2009 (UTC) | ++ | -- | -- | -- | -- |
| Inetis 16:00, 6 August 2009 (UTC) | -- | -- | - | ++ | + |
| --Walley 15:57, 8 August 2009 (UTC) | -- | -- | -- | ++ | -- |
| User:javiersanp 20:43, 23 February 2010 (UTC) | -- | - | + | ++ | ++ |
| Pavelo 09:01, 10 June 2010 (UTC) | -- | -- | 0 | ++ | + |
| gr8scot.za 13:45, 20 September 2010 (UTC) | -- | -- | - | ++ | + |
| apapadop 13:13, 5 May 2011 (BST) | - | 0 | + | ++ | 0 |
++ love
+ like
0 no comment
- dislike
-- hate
Number of arrows, or signs
Is there a scheme for adding the number of signs on a guidepost? — vibrog 19:36, 15 January 2009 (UTC)
- And is this information any good? --Kaspi 15:40, 4 February 2009 (UTC)
Using Guidepost tag for hiking trail crossings ?
I want to use OSM as well as a kind of repository for POIs for hiking. A lot of times I create POI's for the crossing points of hiking trails, even if they have no visible guidepost
Do you think it makes sense to use this tag for those POi's or do you propose an other tag ?
I think it would make sense, because the metadata for this crossing points would be the names of the trails crossing at this point. Maybe a special flag should be added, such as "visible_sign" = yes/no
- I thought about it myself. It sounds a bit ridiculous to have a tag for a feature "guidepost" and then to have a flag to say that it is not there ... I came up with this because the information to put in a relation for the guidepost, would be very similar. So maybe the proposal to add it to the tag junction is better. --Behrica 17:25, 7 May 2009 (UTC)
- +1 for marking hiking trails crossing points as soon as they are known. A node at crossing point will eventually be inserted anyway when all the crossing trails are fully entered, so it doesn't harm to anticipate this kind of editing as soon as possible. So far I've been marking this kind of information by inserting a short segment of the (yet) unknown departing trails, with a FIXME annotation. I reckon that tagging the node appropriately is a more elegant solution. But I deem that adding it as a guidepost would be confusing (unless a guidepost really exists), I favour the crossing junction tagging.--Kaitu 22:05, 20 May 2009 (UTC)
Outdated comments
highway = guidepost???? Why 'highway'?
information=guidepost
would be ok by me.
- You're right, it's much better, thanks. Jiri.jakes 10:29, 6 August 2008 (UTC)
This is duplicate of already proposed tag amenity= Signpost. I think this two proposals should be merged. However I like rendering in this proposal very much. --Vrabcak 11:05, 6 August 2008 (UTC)
- +1 for merging; as for the graphical symbol, the arrows are very intuitive and it would be nice to use them somewhere, however the cross is nonsene: it is very very very similar to the symbol used for church at some maps, and also it can be mistaken with hospital or first aid facility; in addition, there is already widely used the "DAV" symbol (see the signpost page) or its variations. --Kavol 19:02, 5 October 2008 (UTC)
- It seems like this merging has been done, at least the other proposal has the status rejected... --JND 18:02, 14 January 2009 (UTC)
Level of sign significance?
I'm seeing this tag used (in an area where I have an interest) to mark very simple signposts. I'm talking about a very simple wood sign indicating the two directions of a long-distance walking route. This isn't a significant sign with lots of destinations - it's something very different (much less significant) than the images of 'guideposts' I see in the information. This in itself might not be a problem... but clarity would be helpful so that people use the tag consistently. Is this tag going to be used for every sign (however insignificant) in the countryside, or should it be reserved for significant posts like are pictured? If used for every small sign the tag becomes useless for marking significant posts by which location can be determined. If used only for significant posts is there an alternative for simple route marking signs?
- I don't know an alternative for simple signposts, therefore I always use this proposal, irrespective of the number of destinations listed. But I try to map the marking sign contents with destination sign relations. The number of relations the post is member of, toghether with the presence of optional name and ele tags might help to guess how prominent the post is. The actual appearence could also further described with a free text descripion tag. --Kaitu (talk) 20:26, 1 May 2014 (UTC)
Is this tag still valid?
The proposal has been marked with "Status: Abandoned (inactive)". So what is the correct tag to use for this kind of signs? Anttit (talk) 17:41, 29 January 2017 (UTC)
- Yes its been in active use since at least 2010 when I mapped this one 861268173 861268173. They are rendered on Waymarked Trails as here, and more to the point there are over 200,000 in the database. SK53 (talk) 20:47, 29 January 2017 (UTC)
- Yes its been in active use since at least 2010 when I mapped this one 861268173
usage in relations
It seems that this name is used already as a role for member nodes of a relation, e.g. relation id="2452083", member type="node" ref="2640804457" role="guidepost". --Pascal95 (talk) 11:48, 21 August 2022 (UTC)