Réseau de randonnées pédestre : destination et temps ?


Comment peut-on indiquer sur un chemin de randonnée pédestre les destinations et temps indiqués par les poteaux ?

La page
décrit très bien comment positionner ces poteaux et marquer les chemins de randonnées, mais je voudrais aller plus loin, en indiquant les destinations et temps pour rejoindre d’autres poteaux indicateurs.

Les pages
proposent des solutions, basées sur des relations entre les divers poteaux.

  • Est-ce qu’une de ces solutions a été choisie pour la Suisse ? Car si on crée une relation type destinationsign ou destination_sign à la place de route, elle n’est plus visible dans la carte pédestre http://osm.lonvia.de/hiking.html :frowning:

  • Entre chaque poteau il faudrait 2 relations, car les temps dans un sens ne sont pas les même que dans l’autre … Ceci fait beaucoup, non ?

  • Est-ce que ces relations seraient uniquement entre les départs et arrivées, ou entre chaque poteau du parcours (ex : une relation Martigny - Lausanne, ou 50 relations car il y a 50 poteaux entre ces deux villes) ? Chaque poteau intermédiaire indique pourtant lui aussi des temps à destination de Martigny et Lausanne …

Merci pour vos réponses :slight_smile: !

You could start by just adding a duration-key (http://wiki.openstreetmap.org/wiki/Key:duration) to the existing route-relation. But there are also algorithms that compute the duration with the knowledge of length and height-difference.

Thank you for your reply. I think some applications can compute walking time between some points, but my idea was just to keep the data on the guidepost…

I will try to add these informations with the duration tag, and then create “super-relations” for a whole path (as describe in http://wiki.openstreetmap.org/wiki/Relation:route#Mapping_practice))

Salut Tempus,

I have been thinking about the guidepost information a bit. Initially, I thought to put it in the route relation, that’s why the route proposal is formulated in this way. After having mapped quite a few hiking routes, I’m convinced that it’s impossible because the hiking network in Switzerland is too dense.

So, yes, keeping this data on the guide post (and keeping it independent from the hiking routes) is a good idea. I don’t think the two destination_sign proposals work very well with the system in Switzerland. We can do with something much simpler because we have named guide posts, i.e. a network between guide posts is sufficient.

There are some examples in Germany where people tried to keep that kind of information on the guidepost. See, for example:


The advantage would be that the destinations can be entered without yet having mapped the routes. (It still looks a bit ugly to me, but that is not really a valid argument. :wink: )

As a relation, I’d probably do one relation per guidepost. Then put in the guidepost of origin and every guidepost that it points to and put the walking time in the role.

I really encourage you to try something out, tag a small area appropriately and describe it in the wiki or here. I will do my best then to add the information to the hiking map.


Hello Sarah !

Thank you for your inputs … I will try to do someting in my area using direction_east (I don’t have a lot of time) …

We will see if it’s easy and usefull or not !



Here my proposal to map the hiking paths. I made a small example in my area, it can be seen at
(I just commit the relations, maybe the map has not been regenerated yet, but the data are visible using JOSM or at http://www.openstreetmap.org/browse/relation/955368)).

(1) I didn’t create a relation between each guidepost, in my opinion that would be too much. I’ve created only one relation, named “Hiking area Sembrancher”, and put all parts of path into it (and another one for the mountain_hiking). The hiking paths are made as a grid, I think it’s not possible to create a relation from each guidepost to each indicated destination (or even a realtion per guidepost as suggested Sarah, the amount will be really big) …

(2) I think that some intersting paths could be mapped, to see the full way in a map (for example the hiking from Sembrancher to Mont-Brun, http://www.openstreetmap.org/browse/relation/962737)). These relation use the same path than the main relation of the area.

(3) I wrote all texts displayed in the guideposts. I don’t know if it’s really useful, in particular for those which have only a destination information, without time indication (like this one for example http://www.openstreetmap.org/browse/node/761450480)). For each destination I wrote also the direction. Maybe the online maps could dispay a contextual hint on each guidepost, with arrows for direction. For example the guidepost http://www.openstreetmap.org/browse/node/612546574 will show :

→ Mayen du Mont Brun par Les Gueules 02:15
→ Le Châble 01:15
| Vollèges 01:00
| Cries 01:15
v Chamoille 00:30

Another “super-relation” for hiking paths could be found in Martigny area : http://www.openstreetmap.org/browse/relation/555139.

So … I’m waiting for yours inputs … I could try another way of mapping for hiking path if any … and sorry for my bad english !



a few comments

The relations are visible now, you made it just before the update at 3 o’clock. :slight_smile: I can see that you triggered a bug in the map style, where the ways are rendered in the wrong color (violett) when ‘Wanderland Schweiz’ is given as operator. It should not do that, I will fix it. Nevertheless, operator ‘Wanderland Schweiz’ is wrong in this case. These hiking routes are maintained by the local hiking associations which should be ‘Valrando’ in your case. ‘Wanderland Schweiz’ is only responsible for the long-distance routes (rwn and nwn in the Wiki).

Also, you should use either the name-tag or the osmc:name-tag. As the name is not the official name of the route but just a display name, I strongly suggest to remove the name-tag. (I will put the implementation of the osmc:name-tag on my TODO-List.)

Strictly speaking, it is no longer a route this way. It is a network.

I am using a similar system now. I first add longer routes between important points, then smaller routes for the remaining connection ways. It is a bit of a compromise between still mapping routes and creating too many small routes. If you do that then you should remove the way from your network relation. No need to have the same route twice in the database.

I’d really restrict myself to the guidepost that have a name and walking times. Those can then easily set into relation with each other and be used to display walking times in the map. I used to have an example of this on the hiking map but I’m afraid it doesn’t work at the moment and it will take a while to put it up again because I’m restructuring my database.

The problem with your current schema for the hiking posts is that you might run into problems with the maximum length a value can have. Using one tag per destination, as in the examples I posted, will avoid that problem. It’s also easier to read for a human.


PS: Your English is perfectly fine but feel free to answer in French if that is faster for you. People here should be able to read it. It is just writing in French that is a bit scary for some (like me :wink: ).

Hello !

Thank you for your feedback ! I’ve so made the following changes in the same area :

  • Change the operator to Valrando for hiking relations
  • Remove the name tag, keep only the osmc:name
  • Remove from the general map of all hiking path those already referenced in a specific path (like Sembrancher - Mont-Brun for example)

I had put more than one direction per tag like one of your example, http://www.openstreetmap.org/browse/node/705039078. In this case there are two directions in the north : Thedinghausen 7.7km; Morsum 7.4km

I’ve changed the way to reference direction and time, to put only one direction per tag (but for a map renderer I think it will be the same a single tag or a list, only the ; symbol must be managed … ?). See http://www.openstreetmap.org/browse/node/388847822 for example. The display in a browser is better, but in JOSM it’s less ergonomic.

If you think it’s a good way, I will update the wiki page according to these new inputs (operator, tagging, …) :

Thank you !

I have a rather different question. I am simply recording a variety of paths that I hike, with no interest in making routes. Currently I do not record guideposts, but I am wondering which are worth recording. I am thinking of the basic Tag:information=guidepost with nothing added.

My current thinking (I have not yet implemented it, will be hiking tomorrow if the rain stops) is to record all guideposts that have a locality on them:

Another option is to record the intersection of “major” trails (how do you define “major”??). It seems obviously inappropriate to record all guideposts, they would fill the map!

Looking at the maps it seems that very few guideposts have been recorded (which is exactly what I have been doing). I think that some are useful, but how many and which?

Your suggestions much appreciated!

I think you have to figure out by yourself.

Hi RetiredInNH,

Adding at least the guideposts with names would be most helpful. Also add name (name=…) and altitude (ele=). This information is very useful for orientation and to compute the expected hiking time. There is a section on guideposts in http://wiki.openstreetmap.org/wiki/EN:Switzerland/HikingNetwork .

I don’t know in which region you are hiking but there are quite a few guideposts tagged in Switzerland already. Have a look here for example:


(In fact, in some regions are so many guidepost that I will have to think about filtering them on the map.)

You can also add the unnamed guideposts, which still can be helpful for orientation. My personal strategy is to add any guideposts where routes fork or walking times are given.



For information the page
has been updated according to the suggestions of this thread.

My strategy is to add all guidposts with name, elevation or directions. I feel it’s fun during a trail to see the location of the next guidepost in my GPS :slight_smile:



The update seems to be only on the French page, the German and the English version don’t mention anything about it.

I agree with you, there are so many nodes in the Swiss hiking network that creating a route for every possible connection between them would become extremely tedious. But using the route relation to describe unordered local collections of ways feels to me like abusing the concept of a route. From a route I expect that it takes me on a trip from A to B or on a round trip. And maybe a relation is not even needed here.

Basically, what you want is to designate ways as members of the Swiss hiking network. This could be simply expressed by using the tag network=iwn/nwn/rwn/lwn on ways instead of routes only. Or maybe even creating a subkey highway:network=* would make sense, I don’t know if similar problems have emerged for other highway types than hiking paths. But as far as I see, determining the network membership of a way is all that is needed, for the distinction between “hiking”, “mountain hiking” and “alpine hiking” there is already the sac_scale tag.


I do agree on the abuse part and it would make live a lot easier for data processing if we would strictly stick to the node-route model. But then again, I prefer to make life easier for mappers, so that much data is entered, and there seem to develop a majority who prefer entering whole networks, so I can live with that (as a data processor, too).

As for tagging the ways directly: first of all, it would only apply to the local Swiss hiking network (the ways marked yellow, white-red-white and white-blue-white). The routes of “Swiss Mobile” are perfectly valid routes in their own right and merit a relation. As for the local network, a tag like hiking_network=yellow/red/blue might seem practical. That we use relations none the less, is mostly a matter of international compatibility. There is not a lot of consensus on how to tag marked hiking routes but the minimum is: use a relation of type route=foot/walking/hiking. And there is a good reason for that: sooner or later somebody wants to stick additional tags to the route. For example, I started to note the name of ways that sometimes appear on the hiking posts within the frame of the local hiking network because they do not have their own waymarking (e.g. Strada Alta: http://www.openstreetmap.org/browse/relation/1152292 ). Another thing that comes to mind are walking times (although hiking posts are most probably better suited for that).

A final note on the sac_scale tag: this describes the difficulty of the way and not how it is waymarked. I have classified plenty of paths as sac_scale=hiking that were marked white-red-white and I never put a sac_scale tag on anything other than highway=path because roads and tracks are always of difficulty sac_scale=hiking.


As a mapper I do appreciate the possibility to group data together, but the route relation seems inappropriate for that kind of use. However there is a collection relation as well as a network relation. They are both proposals, but widely used: osmdoc for collection and osmdoc for network.

For me a network is a network, and a route is something that uses elements of the network, but that stands out from the network. Just like a bus route uses elements of a city’s street network. But if you’d look at the Swiss mountain areas and huge collections of unrelated paths would show up as (one) route, what would be the point of it? Those routes wouldn’t take you anywhere. And some really interesting local routes like a Chemin des Narcisses or Sur les traces du renard would get drowned in all the noise.

Exactly. Your example makes sense because you grouped together the elements of a route, and not of a whole network. That’s exactly my point: I certainly don’t mind if the elements of the hiking network are tagged/grouped/rendered in a special way, but I think that routes like the “Strada Alta” should stand out from the rest of the network.


This problem kept bugging me, so I have been looking around and found two more things:

  1. “Those who invented relations” seem to have very strong feelings about using relations in the sense of categories or classes. They wrote a page Relations are not Categories on which they advocate for tagging nodes or ways directly instead of using relations for this. After all, the OSM data model (and I guess the software architecture too) is based on bottom up tagging where the properties of each element are self-contained, and not based on classes and top down inheritance of properties.

  2. On wanderland.ch there is a distinction between the extremely vast hiking-trail network and specific local/regional/national routes and their sections. How about reserving route relations for the latter and using specific (to be defined) tags for all the ways that make up the hiking-trail network?

As I said, I agree with you, which is why the original proposal said: a relation contains exactly one route between two neighbouring, named hiking posts. “neighbouring” and “named” turned out to be a rather too strong restriction, but I’d prefer if the ‘exactly one route’ requirement was kept. However, other people find even that too tedious. If the network concept bothers you, stick to the original proposal. If it really bothers you, convince other people to do the same.

By the way, the node/route schema has its origins in the cycle network schema of the Netherlands. It works quite well there, too: http://wiki.openstreetmap.org/wiki/Cycle_routes#Tagging_Cycle_Node_Networks and they also use it for their hiking network: http://osm.lonvia.de/world_hiking.html?zoom=13&lat=51.48007&lon=5.66224&layers=FFBT

That’s a post processing problem. You can easily find the routes that fall into your definition of interesting by filtering away relations without a name tag.

No, it’s not really worth standing out. It just happens that in Tecino a lot of marked hiking ways have been named. (I should have choosen an example that is less well known, maybe.) The actually marked out route there is the nwn 2.

Anyways, you have ignored the main reason for using relations: consistency. I like the fact, that you can find all marked hiking routes in OSM (worldwide!) by looking for relations with route=foot/walking/hiking. It makes life so much easier. Yes, there is a small difference on how hiking routes work in Germany and Switzerland but the difference is IMHO not big enough to merit a completely different way of tagging it.



A nice looking local network indeed! But what about the routes, I mean more far reaching ones than those ones linking two guideposts?

This is not about my personal definition of “interesting”, but rather about the fact that there is a difference between a local hiking route, and a local hiking path.

The Strada Alta has its own website, so even if it is a part of a bigger national route, it seems to be a segment worth naming and speaking of on its own.

On the other hand, if it is true that local hiking paths might be carrying their own name tags, then what you said above would be wrong: there would be no way to distinguish local hiking routes from simple hiking paths.

I appreciate the idea of consistency, but it seems that at least in Switzerland it comes at a rather heavy price: either we frustrate the mappers with the requirement to create micro-relations for all those micro-routes, or we will fill the map with “routes” that look like the ones created by Tempus here and here.

The difference between Germany and Switzerland is not so small, it’s an additional level: in (the non-touristic areas of) Germany, intersecting hiking routes themselves form the network. In Switzerland, the hiking routes run through a very dense network of interconnected hiking paths, not all of which are part of a route. After all, the organisation that maintains the hiking paths is called Schweizer Wanderwege, and here, that seems to be ment litterally. In Switzerland, at the basic level, it’s about the infrastructure of paths, not about routes. And yes, it is a question of levels and hierarchy. Switzerland doesn’t “own two different hiking networks”, as it was wrongly described in the OSM wiki. Hiking in Switzerland is operated by Schweizer Wanderwege in the framework of SwitzerlandMobility. It’s the same organisation, presenting itself at different levels of the hierarchy of paths and routes.

The tagging of the local hiking path network in Switzerland has barely begun, and we have already reached the point where route relations become mere categories with the osmc:symbol tag and a region as only common denominator. I think it is time to question whether we really need relations for describing hiking paths, or if we were not better off applying an osmc:symbol tag (or another appropriate tag) directly to the underlying ways.


This is were our opinions differ. The tagging has been going on for one and a half years now and the network tagged so far is quite extensive already. And, honestly, your objections do not seem to weigh heavily enough to change a running system. But I can easily be proven wrong.

So, I suggest you do that in the usual OSM way. Come up with a good proposal and convince mappers to use it instead of the current tagging schema. If you manage to do that (that is, new routes are created more often than not with the new schema), the hiking map will adapt itself, no problem.