Proposal talk:Guidepost

From OpenStreetMap Wiki
Jump to navigation Jump to search

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)
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
node guidepost exactly one The node corresponding to the guidepost.
nodearea to optional The destination
wayrelation route optional The path to destination (a way or a relation of type route)
nodearea 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)
I gave such a proposing in the topic [[1][information=*]]. I think for orientation it is good to know that there is a guidepost, but for routing the type could be interested. --Vsandre 13:18, 3 July 2009 (UTC)

Rendering

symbol description rendering example
Dav signpost.png 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)
Guidepost render cross.png cross is used in czech hiking maps of SHOCart Guidepost RenderPropose1.png
Guidepost biguidepost.png Guidepost RenderPropose2.png
Guidepost doubleguidepost.png Guidepost RenderPropose3.png
Signpost.png

I like this proposal and think we should only decide on the symbol for the renderer. My favourites are Dav signpost.png and Guidepost doubleguidepost.png, 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 Guidepost doubleguidepost.png. I do not know, if we could use the Dav signpost.png 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 Dav signpost.png Guidepost render cross.png Guidepost biguidepost.png Guidepost doubleguidepost.png Signpost.png
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 node 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)

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)