Today I am starting a “technical” checkup of the Dutch parts of the European long distance hiking routes E2, E8, E9 and E11.
Since I have just checked and repaired all the Dutch official national hiking routes, and the E-routes all use these, it should be relatively straightforward.
Next, I will try to check-and-repair the adjacent sections of these 4 E-routes, in the UK, Belgium, France and Germany.
Outside of Nederland, I can repair simple errors such as wrong order, duplicate ways, problems caused by cutting or extending ways without adapting the routes. However,
I can not check the actual signposted routes on the road
I can not use the national operators as a source
Apply my way of tagging and mapping routes to routes maintained by other active communities
I have no direct connections that I can ask to do this for me.
The working target is that each E-route should, in each country, have one main route, which can be exported as one continuous gpx-track e.g. from overpass-turbo or waymarked trails. WMT then also shows one uninterrupted elevation profile.
If this could be extended over the borders, that would be great, but I doubt that, given the current state of affairs. Future stuff.
A service which will profit from this is longdistancepaths.eu, AFAIK the only OSM-based service that enables users to select their own sections from a long European route, and then export these as gpx’s which can be used by navigation apps and devices.
I think there is a consensus that we need to reach about E2, E4 and E5 in France, given your stated goal.
If memory serves well, each of these routes has two branches of equal importance, and deciding which is the main route is a problem.
You have chosen to solve the issue by creating separate linear routes (e.g. E2 East and E2 West) but this did not trigger an enthusiastic response on French channels last time I checked.
I don’t know if this happens in other countries. Unfortunately for us we also have this particular type of puzzle to solve on purely national routes, and although your solution is not considered satisfactory, none that we have found are.
Maybe the whole notion that all routes must be linear or loops is flawed and we have it wrong from the beginning?
I’m not too happy about it myself, but… if two long variants of a route are of equal importance, you have in fact two separate routes, which just happen to have the same ref / name. In the UK-section, this is the case. Only one of the routes passes throuh Nederland, no problem there. The other one goes through most of Belgium, then joins the first main route, and then run the same course together. The joined section is one route relation (one object), re-used in both superroutes.
Now I perfectly understand that in France, it looks like the same route is mapped twice - but it isn’t, there is only one route containing the ways, and it’s used in two different European superroutes that partially run together.
In Nederland, we of course have the same problem on several nwn and rwn routes. Most of the time we manage to have the operator assign one main route and separate variants which get one of the roles approach, alternative, excursion and connection.
There is one case, slightly different: the superroute is significantly different in breeding season and/or with a dog. Numerous “alternatives” are present as separate routes. This meant that the hiker in the main hiking season or with a dog needed to follow many short variants, not having one route to export to the navigation app. So we now have a separate superrelation containing all the variants to be used in the season or with a dog. In the season or with a dog, pick the route for season or dog, that is a better message than: in the season or with a dog, stitch all the seasonal/dog-variants together with pieces of the main route.
To answer the last question: for rendering it’s not that important to have one continous track, but for other uses it is. A route is usable if it tells you where to go. You choose which route, then navigate it.
This might be different; a navigation could offer choices from a multi-track gpx on the fly. An export could filter alternatives before creating the file or an app could let you piece together which sections you want to use as your itinerary. Problem is, I don’t see that happening in the OSM ecosystem. So we’ll make do with pre-created itineraries.
I’m wondering: could it be that we are overstepping the border between our role and that of route designers? We have a mental (and software) model where a route has such and such characteristics. And when we meet a route that does not have these exact characteristics, we are tempted to adapt it to our model instead of questioning the model.
Could it be that we need to accept routes that are closer to networks than to routes as we currently see them? We have extreme cases in France (at the regional level) where an operator calls a route something that’s neraly a node network.
I think we are accommodating the designs within the limits of OSM rules.
One of the choices is to view what the designers call E2 as 2 separate routes E2 West and E2 East having a rather long section in common, or as one route E2 having 2 rather long (spanning multiple countries) main alternatives. The same choice occurs in Nederland at the national, regional and local level.
In Nederland, we (mapping signposters) managed in all cases I am aware of, to have the operator make one route main, and the others alternative/approach/connection/excursion. So we can accommodate that easily in OSM. Different routes running together for a stretch are easily mapped by including the section in both routes.
For Node Networks, alternatives and ‘extra’ main routes can be mapped, whatever the operators design. Node Network Routes running together for a short stretch (say 5-50 m)are often encountered; in this case the way or ways are included in both routes.
For E2, both routes are equivalent, no operator indicates one as main and the other as alternative. That means we shouldn’t assign a main and alternative role either; we should not ‘correct’ the operators just because of ease of mapping. Note that each of the two E2 routes has its own local/regional alternatives, which is reflected in the roles assigned to subsections and, sometimes, ways.
So I felt the only way to map the real-world design spanning so many countries, was to create two separate full routes, with the common section (the entire French national section, i.e. the GR5) added to both routes; similar to adding a common section to two national routes running together for a stretch.
Since the GR5 in France is mapped and maintained as one national route (or superroute?) there is no additional maintenance burden for the French route mapping community by adding this national route to multiple international routes.
I feel I have not taken the role of a route designer here; if I had assigned main/alternative roles to the two E2 routes I would have done that. The sectioning of the routes also follows the design decisions of the operator(s).
Taking the E2 as an example, that’s often composed of sections of national routes. For example, most of The Wolds Way matches this relation which is a consitituent of E2 in the UK, itself part of the main E2.
I’d suggest splitting the Wolds Way into 2 or 3**, with the middle bit also part of “E2 in the UK” (and add that as a constituent relation to “E2 in the UK”), and the southern bit that differs both part of a new “Wolds Way” superrelation. It also makes sense to split out the Market Weighton diversion as an “alt” route to the national trail (though both have equal signage on the ground). Doing it this way will make maintaining these E routes much easier in the future.
I suspect that you might get issues like this with every section of these E routes, so you’ll probably want to “consult each local community as you go”.
** “or 3” is because I suspect the “end acorn” for the Wolds Way is further along Filey Brigg than OSM has the route going. Needs survey.
Edit: It’s 2, not 3 - the “end artwork” for the Wolds Way is the start of the Cleveland Way. There’s nothing signed for either route onto Filey Brigg. I’ve updated what’s here with images from survey.
Exactly. The things you describe need local/regional/national knowledge and probably survey, taking into account the hierarchy buildup and connectivity from ground level route relations to the international superroutes.
I have more questions than answers about this. But if at some point we, as mappers, need to create information (such as E2 East) that the designer did not provide, it may mean that the current modeling rules are inappropriate to map the designer’s intention. And/or our expectation that a route is made of a main route plus variants may be unfounded too.
Interestingly, the description of the route on its main operator’s web site (European Ramblers Association) mention branches by the names of their extremities, not by East/West considerations: see for instance E2 in Great Britain - European Ramblers Association. Maybe it is something that we need to take into consideration in our data model.
One of our community members, who is a professional network manager, talks about the editorial intent of route managers and our responsbility to respect it. Sometimes we don’t like the intent (and I certainly do not feel comfortable with this one), but it is still theirs to choose.
I remember some time ago the ERA had much less of a description than it, apparently, has now. But they still point to traildino and longdistancepaths.eu for the routes, and these sites name the branches differently. Anyway, that is not a question of datamodeling, but of what value to put in the name and description tags. If the names should be different, I have no objections. Renaming does not alter the routes. Two different main routes with the same ref, no name, only different descriptions: also no problem. The current data model handles this.
The current model handles it once a decision has been made by someone who is not the route designer to split the route into two main routes. It cannot handle very well what we observe as the intent of some route designers, and we end up “normalizing” their intent.
The data model (how we can map and combine routes) handles all situations the route designers come up with. The current way this has been done to enhance usability of the data, that’s open for debate.
What improvement do you suggest?
This is probably just an example, but we have discussed how adding nodes as children to superroutes could turn these superroutes into something that would share traits with both node networks and classical routes. This would allow applications to handle them as a collection of networked segments.
This way there would be one E2, with two branches. Or one E5, with four branches and a diamond shape in the middle.
As it is, what is stopping applications from handling the sections and branches of E2 as a collection of networked segments? What would entering nodes into superroutes actually achieve in that respect?
I have found the changeset which deleted the route.
I reverted the deletion of the grande traversee des alpes, which is part of the GR 5 and the E2 hiking routes, using this great tool. One can set a filter to limit the revert to the object(s) you want.
In the same changeset, other routes were deleted as well, but since I don’t know anything about those I thought I’d better leave those to the French community.