How would you tag a relation that is equally used as cycling and hiking route. In my specific case it is about the “Rail Corridor” in Singapore.
There was a similar question 12 years ago. He copied the bicycle relation in JOSM and changed the copy to a hiking relation. Is this still the recommended way?
If you don’t mind, I’ve addod this question to the list of issues with the path tag.
Yes, two relations is the sensible way to do it.
Multiple values in the route=* tag are valid, so a single route relation tagged route=hiking;bicycle accurately describes this situation. One of the major route relation data consumers, Waymarked Trails, documents this usage on the about page:
A
routetag with multiple values is supported when they are separated by semicolon without any surrounding spaces.
Here is an example of a single route relation that is displayed on both the hiking view and the cycling view of Waymarked Trails:
So two route relations are not necessary unless the hiking route and cycling route aren’t quite exactly the same (i.e. they diverge in a few places). In that case, two separate relations is a better way to do it.
How is a question about how to tag a cycling route and hiking route related to highway=path?
If the routes are fully identical (the route itself and also all the tags describing the routes) I would suggest as well route=hiking;bicycle. But as soon as that’s not the case (lie each of them has it’s own color, website,…), creating two relations is the way to do.
That’s interesting, I tried this a while back and it didn’t seem to work well so I ended up with the “two relations” approach. Maybe it is an improvement since I looked at it, or maybe I was looking at something other than Waymarked Trails at the time. I wouldn’t be very confident that other renderers will pick up the value after the semi-colon, but I haven’t tried recently.
I suppose that for consistency, the network tag should be something like “rcn;rwn”.
As others have said, for longer trails it often happens that the two routes are not exactly identical (e.g. the cycling route has to avoid a short section of pedestrian-only footway) so it’s difficult to avoid two relations in those cases.
I’m doubtful about this also, the “highway=path” issues seem complex enough without adding route relation issues which seems quite separate, unless I am missing something.
Perhaps not directly, but
How would you tag a relation that is equally used as cycling and hiking route.
and
cycleway is part of a cycle route,
are great ingredients for some interesting development of the topic.
In France there are routes that are identical for hiking, riding and cycling. For one of these routes I made a separate relation for each of the three.
Another idea could also be, to create a route-relation for the route itself and then a route_master for each kind. So each type could have dedicated tags and still the route would be stored in a single relation.
From what I understand of route_master, it serves to share tags and not geometry. If this is true, then probably the solution here would be a bit different, in order to share geometry. For instance a type=route relation that is included as the only member in a route=hiking relation and a route=cycling relation.
Yes, I think these are almost opposite situations: route_master brings together different geometries that share some common tags, whereas here we are trying to express that two sets of tags share a single geometry. Adapting route_master for that purpose might be a stretch too far.
As you say, maybe a “route of routes” or “superroute” concept would work. We already have a lot of usage of these concepts to build long routes from shorter ones. But I think currently, the lowest level relations always have a route=hiking/cycling/etc tag. Leaving that undefined might not be supported by relevant tools.
Looking at actual usage, the semi-colon approach doesn’t seem to have really taken off despite Waymarked Trails support. Where it is used, hiking and MTB is by far the most common combination. But I don’t really know how many routes could potentially use this approach, so maybe 500 or so total uses could be considered quite a lot.
That might be the case, though it would work out in tools which support route_master. If you think about a cycling-route split due to it length in multiple route-relations, the route_master contains the tags of the route and the route inside just are necessary to provide the geometry. Nobody cares actually about the tags of those route
I agree as I said above that the approach could be similar to this kind of “route of routes” mapping.
I just don’t think route_master is used in that way. As far as I know, long routes like Eurovelo are mapped as route=bicycle, type=superroute (or sometimes just type=route).
route_master-relations are used to map variants of the same public transport route. Like a bus, sometimes taking route A, sometimes route B. I also don’t think it can be used for this special purpose 
This 
Oops… you are right, I mixed up route_master and superroute. So there could be one type=superroute with route=bicycle and another type=superroute with route=hiking having the tags and both have as member a type=route relation containing the geometry.
I like this idea, but we should be aware that the concept of “tag inheritance” between parent relations and member relations is unclear in OSM. The documentation of Waymarkedtrails is the most explicit that I ever found about this, but it is only one application and only one tag (route networks). We would need to clarify how some tags are not inherited and others are, ideally.
