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
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 …
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.
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:
(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.
The relations are visible now, you made it just before the update at 3 o’clock. 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 ).
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.
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?
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.
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:
“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.
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.
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.