For me, this is 3 roundtrips forming a “network”.
One could follow one of theses 3 “officials” loops.
Another could follow a roundtrip made from parts of 2 loops.
Apologies, I spoke too soon about the “Sentier des Mines”. My local knowledge predates the elevation to an official GR.
So, relations 15897084, 15897365 and 15897712 are clearly regional routes. They use the local base network. That is exactly what is mapped: they are themselves superroutes of node_network edge routes.
In fact, the whole area seems to fit pretty well into the base_network/local/regional/inter-regional/long-distance schema already.
The main relation is not a route at all, it is a collection. It should be a route=network. Note that this would also much better correspond to how the hiking club describes the thing (a collection of three circuits).
You would tag a network with a GR reference? that would create a precedent.
Note that if, as @pyrog said, E2 is one route, then saying that Sentier des Mines is a route is not very different.
I have suggested this approach to our national hiking route provider, Wandelnet. They would have to assign numbers or names (or pictograms other fancy identifiers) to the crossing points to make it work as a node network.
Suppose they simply use capital letters. The end user could then plan their trip as: follow the white-over-red symbol starting at node X, via A, G, C and F back to X.
This picture might help visualise the idea - see how the blue national routes intersect and form a fishing net network, and think a capital letter at each intersection.
The node network trip description would simply be X, A, G, C, F, X.
A verbose output could mention the section’s longdistancepath’s ref or name, just for fun.
Node X -Pieterpad Pi- > A -Noaberpad No- > G -Grote Rivierenpad Gr- > C -Pelgrimspad Pe- > F -Pionierspad Pi- > X
If no node identifiers are visible at the crossings, you don’t have ground truth for this approach.
The organisation said it would be too much work. Would it? Shields with text on are standard. The intersections are already there. So all you need is shields with a label, the number of shields equals the number of intersections in Nederland, let’s say a couple of hundred. Then each operator team (I’m in two of them) needs to attach a shield to the intersections of ‘their’ route, meaning a single volunteer may have none, one or two shields to attach on their section. Let’s say, one on average, to be done on the half-yearly check round, when they pass there anyway. Even accounting for the fact that half-yearly checkrounds are performed once a year, I would not say this is a mountain-moving task.
Anyway, end of rant.
Ok, the operator don’t want to add signs on the ground.
But why couldn’t we explicitly add “nodes” in OSM ?
Currently they exist implicitly. But when route relations are broken this is difficult to guess if an intersection between two routes is really a “node” or if it’s an artefact.
Perhaps I don’t fully understand yet, but it sounds to me like the base network concept is equivalent to named streets in a city. For any particular trip one will follow multiple different streets, often for only part of their length. Should streets be tagged as part of a base network? If hiking routes should be but streets shouldn’t be, what is the difference?
1 Like
Excuse me sir I’d like to digress a bit.
Here is my 2 cents about :type suffix: it should be avoided, no matter it is used or be relevant at some point.
:type means we weren’t able to correctly define what is actually classified.
Years after years we discuss about it and pretty all :type tagging cause issues sooner or later.
It’s a red flag that encourages to refine the current tagging.
Then we’d better thinking about more readable key and the best way to replace it with all due respect to mappers and consumers.
By the way, doing so may help to question what we are actually mapping and finally brings benefits.
1 Like
I agree. At the same time I think we should only change this actual tagging to something else if the party’s that actively use it commit to using the new key, and we make sure that the meaning has not changed at the same time. For this particular key that is not impossible; we can pretty much pin down all users.
This tangent was mainly about bike route networks, which are slightly off-topic here. But to address this point: the difference between a Route 25 and a Route 25 Alternate and a Route 525 is not a network within a network. In the U.S., we call them special routes and auxiliary routes; the collection of the main route and its special routes and auxiliary routes forms neither a coherent route nor a coherent network. It’s just a collection of numerically related routes within the network’s established numbering pattern.
That said, due to the potential for error by data consumers that don’t recognize modifier=*, the U.S. community has taken to also jamming this information into network=*, forming a sort of “subnetwork”, such as network=US:NY:Alternate. This doesn’t mean the routes are part of a distinct network from US:NY, but we figure that any data consumer who cares will know what to do with these values anyways.
Sometimes mappers have attempted to fashion superrelations out of these related routes because they mistakenly thought relations work like an encyclopedia article’s “See also” section, or because they aren’t familiar enough with the network to know that these modifiers or route number suffixes indicate distinct routes.
While the real-world concept of special routes is currently limited to highway and cycling routes, I suppose nothing is stopping a trail operator from extending this system to hiking routes at some point in the future, since trail users would likely be familiar with it from other modes of transportation.
The idea is alluring to computer scientist types who like database design, but less alluring to computer scientist types who like database usage. 
From what I’ve seen so far, countries in East Asia have historically relied heavily on network relations at the expense of indicating this information on individual routes. Inevitably, mappers saw those network relations and began fashioning fantastically elaborate superrelation structures five levels deep, so that nowadays there isn’t a single numbered road in all of South Korea that isn’t indirectly part of a single monster of a category relation, while the bottommost route relations contain no indication of the network whatsoever.
If there is a data consumer out there that does anything with network relations, it’s probably only as part of a hard-coded special case that could be reimplemented more effectively as a simple tag comparison.
I made the mistake of using an example from biking instead of hiking, but as far as I am concerned I can tell you I perceive it as a core topic. We are trying to consolidate the quality of hiking routes and networks (in France, taking adjacent countries into account) and we keep hitting edge cases that prevent us from using standard techniques.
If a operator defines it’s building as church and it looks like a school, we tag building=school. In your case I would agree with @lonvia that this is a route with many alternatives according to OSM standards. For sure, the operator can have different definitions on his side.
route=network is regularly used for collections of routes that somewhat belong together. My personal preference would be to simply delete all these collection relations. route=network is the slightly less definitive suggestion. The important part here is to get them out of the route=hiking classification which should be reserved for routes proper.
E2 is one route with two alternative trajectories - east and west. Further, these alternatives exist only between the Penninies and Antwerp, i.e. for less than a third of the route.
Sentier des Mines is a collection of three circular routes. They are independent (albeit overlapping) not alternative means to get from A to B.
That makes a huge difference.
Precisely. We might as well just invent a tag that is equivalent to highway and put it on the ways. It would certainly make life easier for data users and mappers in the long run. The two main reasons we don’t do it is (a) tradition (all the maps already know about route relations, getting in a new system is hard) and (b) that there is some additional information attached to this pedestrian/bicycle/equestrian networks that might clash with the tags for the car-centric street network we already have. (Also as said above, some base networks are still based on routes, a fact that OSM might like to capture.)
… which is how the operator defines it. My remark about second-guessing the operator was aimed at @lonvia’s perception that it was a basic network before she noticed that it had now the GR status.
I read two things here:
-
we seem to agree on what E2 is
-
you seem to introduce a new object into this discussion (I’m not saying that it’s new to OSM): a collection of routes that would be managed by the operator as one route. Previously I thought that the GR status had swayed your perception in another direction?
lcn=yes has some antiquity for exactly that in OSM, used to be pretty popular and is still found in some places . In at least one example I know, a mapper moved from lcn=yes on ways to monsterrelations only because OpenCycleMap stopped rendering the former.
1 Like
I didn’t realize OpenCycleMap stopped supporting lcn=yes. That’s unfortunate, because that tag has always been the recommended tag for the rectangular “Bike Route” signs in Canada and the U.S. that merely indicate that a roadway is part of a local network of “bike-friendly” streets, not a linear route. We have similar signs for “Truck Routes” and “Wheelchair Accessible Routes”, which is not to say that there’s anything we could model as a route=hgv network=lhgvn or route=wheelchair network=lwcn relation, respectively.
1 Like
What did the support of lcn do for the users of the map?
Was that more than showing bicycle access?
( I really don’t know, I hardly ever use bicycle maps)
As I recall, OpenCycleMap used to highlight individual ways tagged lcn=yes in the same manner as ways that are a part of a network=lcn route relation. It could be combined with the treatment for highway=cycleway or bicycle=*.
In that case, I understand the change. I guess this comes from the early days of route mapping, where the individual ways of linear routes were tagged to indicate that they form a route.
This highlighting would now totally obfuscate any real local routes (relations). Which may not be so bad for bicycle, but for walking, horse, roller skates, many local routes exist, which would be obscured by the l*n ways.
I see sort of the same thing happen when all the cyclable ways in and around a city are entered into one lcn route relation. The whole city is highlighted with this “network”, making it very hard to find real routes.
As always, it depends on how the tag was used. Instead of designating a local network of distinct biking or walking routes, some localities designate an undifferentiated local network consisting of the subset of streets that not only allow biking/walking but also are recommended for biking/walking. There needs to be some method to indicate that a street is part of this kind of network, which is really akin to how some localities designate certain streets as the main streets around town for motorists. Historically, a street could be tagged lcn_ref=* for the distinct local numbered bike route number, and/or lcn=yes to indicate that it’s part of a local network, which may or may consist of linear routes. Eventually network=lcn route relations supplanted lcn_ref=*, but not the undifferentiated use of lcn=yes.
In a locality that designates a network of linear routes where mappers were redundantly tagging lcn=yes on every route relation member, I agree that also highlighting lcn=yes would clutter the map. However, in a locality that instead designates an undifferentiated network, these highlighted streets wouldn’t be redundant. If renderers have dropped support for lcn=yes, that might explain why some mappers are resorting to creating weblike “route” relations. type=network relations might be a solution, especially if it allows additional information about the network that could never be captured on the ways, such as the name of the network. However, it would be a bit more convoluted and difficult to maintain than tagging individual ways.