A typical hiking guidepost in the Austrian Alps and its node in the OSM database

How a guidepost can be mapped and which level of detail is desired has been the topic of a thread in the German forum and a dedicated poll (not available any more). The outcome of both discussions was that people have very different opinion on how mapping should be done. Fortunately, there is no conflict between the different options, they merely represent different levels of complexity.

Besides the personal interests of each mapper, the location and type of the sign plays a role when deciding on a mapping scheme. Some guidepost just point to the next locality along a path which is already fully mapped—the additional information by adding these destinations to OSM is marginal at best and can be skipped. The same holds for guideposts along an existing hiking route. In this case, the guidepost itself can be added to the OSM relation and it’s content doesn’t need to be mapped. In other regions, the pure existence of a mapped guidepost is valuable information—e.g. if ways have not been fully traced, the map user could be told to take a way that doesn’t even exist on his map yet.

These considerations led to a three-leveled recommendation how to map guideposts:

Level 1—The Guidepost

Each and every guidepost found should exist in OSM as a node tagged tourism=information and information=guidepost. Following additional tags that can be used:

• hiking=yes / bicycle=yes — is the guidepost designated to a specific group of users?
• operator=* — the organization responsible for the guidepost
• ref=* — some operators use reference numbers on their signs
• material=* — the material the guidepost is made of, e.g. wood or metal
• colour=* — the color of the guidepost

If someone does not want to map destinations, the content of the signs might be made visible to other mappers or map users by either adding a url tag pointing to the image taken or the text of the signpost can be put into a note:destination or inscription tag.
In case the guidepost is part of an existing hiking route relation, it should be added to it. Further mapping of destinations is not required in this case.

Level 2—Destinations as Keys on a Way

On most highways destinations are mapped using the destination=* and its sub-keys including the :forward/:backward suffixes. This scheme can be used on hiking routes as well. The tags are put on a way in OSM starting or ending near the actual guidepost. Useful keys are

• destination=* — Give the destinations as a list, separated by semicolon.
• destination:symbol=* — in case a symbol is shown (usually for amenities like restaurants)
• destination:ref=* — the reference number of another way the guidepost points to
• destination:lang:XX=* — some destinations might be posted in several languages. Use the common language keys in place of „XX“

Please note that the addition of :forward or :backward is necessary in most cases – the destination given is only valid when travelling the way in one direction but not in the other. The suffix is always added to the very end of the key.

Level 3—Destinations as Relations

The most precise though time consuming option is to use relations of type destination_sign. A destination sign relation has three members. The guidepost (using role sign), the intersection node on the way (role intersection) and the way the sign points to (to). Besides its type, the relation takes the keys mentioned above and in addition:

• distance=* — the distance to the listed destination as shown on the sign. Default unit are kilometers, others can be used but need to be specified (e.g. 6.5 miles, 550 m)
• time=* — The time to destination indicated on the sign. The format is „HH:MM“, giving both hours and minutes.
• colour:back=*, colour:text=*, colour:arrow=* — the colors used on the sign

Remarks

Some general remarks about tagging: Always choose the most appropriate scheme—none is better or worse. Keep the tagging as simple as possible without losing too much information. Trivial information does not need to be mapped.

[This text also appeared on http://www.weeklyosm.eu/archives/4504 in 2015, thanks to Nakaner and Manfred for proof-reading]