A Task for the Summer Holidays—Guideposts along Hiking Routes

A typical hiking guidepost in the Austrian alps

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

For the German community it has become a habit to do so-called “tasks of the week”—a common mapping effort with a specific topic like turning lanes or pharmacies. This time we are going one step further—a task for the summer holidays. Mapping guideposts along hiking or bicycle routes. Due to its inherent complexity—guideposts are usually spread over a large area and are not as easy accessible as other objects, the task was divided in two parts. First, mappers are asked to take pictures of guideposts during their summer holidays—a time that many people spend doing hiking or biking tours with their families. The actual mapping of the surveyed information will take place in early September, when people are back home. To refer to this task in blog posts and changeset comments the hash tag #OSMWA1536 can be used.

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 (in German forum as well). 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-levelled 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.

6 thoughts on “A Task for the Summer Holidays—Guideposts along Hiking Routes

    1. Oliver says:

      Hello, as we announced before, the weekly-team is taking a break for some days. Producing the weekly news is quite time-comsuming work, we all have families and many are mothers and fathers. So about this last guidepost-task, we made the decision to post it for some days on the main page and then move it some days later to a subpage. As we have no capacities at the moment to translate all the regular news in all languages, the german team decided to translate their task into english for us this time. So we used this chance to bridge the gap and offer at least some little “pseudo-news” for those, who are interested. This is just a well-meant offer to show we are alive, but this will not become the standard in the future. We hope to get some understanding from you. Oliver

  1. Santi says:

    Hi! Perhaps this is not the appropriate forum but I cannot speak german…
    I found some guideposts containing two destinations with two times and two distances, Should I do one relation for each destination? Thanks!

    1. Jan says:

      Hi Santi,
      as Nakaner wrote, times and destinations can only be mapped using relations. You need an own relation for each destination in this case. Adding the information to the way is not possible as they are only valid at the point of the guidepost, but not at any other position along the way.

      Before mapping such information in detail you should take into account that at least distances can be extracted from existing OSM data easily if both the way and the destination itself are available in the database. In this case the relation doesn’t add much valuable information and could be omitted.

      If you don’t want to take the effort of many relations, you could add the times and distances as description to the guidepost itself.

Comments are closed.