Maintaining European e-path hiking routes

The Monitor function of has reached a new level of maturity that makes it a practical tool for monitoring the quality of very large routes, including European e-paths E1 to E12. See knooppuntnet, where most of them are already monitored (actually, all those that pass through France).

Currently, the most useful role of this Monitor function is to detect and manage discontinuities: missing members, ordering issues, etc. It makes it possible to engage in an improvement campaign, and we already have worked on it in France.

Anyone interested in doing the same in the other concerned European countries? If yes you can for instance:

  • go to the above page, find discontinuities, and address them
  • propose focused projects by replying to this message
  • ask here any questions about how current users of this function work with it

I went to the overview page but it is not immediately clear to me how to find the problems. I guess that is the “Deviations” column but for me that does not match with “missing members, ordering issues”, more that the route in OSM deviates from a reference and then I wonder what is the reference?

Based on the overview page the E5 has currently the most deviations: 230, 370 km so I had a look at that.

So one deviation for Nr 3, 4 and 5 are fine.

Clicking map and zooming in for #3 gives as map and bij clicking on the Deviation / zooming in/out I see:

So yes, that is a deviation, no “missing members, ordering issues”.

So two questions:

  1. What is the reference? Would be nice to have a link to it on the knooppuntnet
  2. Where to find “missing members and ordering issues”

There are two kinds of references: gpx, and osm.

  • gpx corresponds to an arbitrary gpx file that a “monitor admin” has uploaded when creating the monitor. It helps when building a route in OSM, or when you want to maintain consistency between an outside reference and OSM.
  • osm corresponds to an OSM snapshot at a date that the admin choses when creating or updating the monitor. It helps to supervise the evolution of the route.

In my own perception, neither are very useful at this stage for the E* routes.

I do it through the number of segments displayed at the right of each line (the target to reach being ‘1’) and the vertical line at its right (the target being a continuous line with no red dot). Red dots at the middle of a segment indicate missing members or ordering issues in a relation, red dots between segments indicate issues when attempting to connect relations.

You will find a number of ‘false positives’, e.g. when a sub-relation is contravariant to the main relation. Issues have been filed for that on the knooppuntnet github.

1 Like

About E5, as far as the French section is concerned, most of the discontinuities are related to issues with Knooppuntnet Monitor: alternative routes and routes that loop back onto themselves are frequent on the Brittany coast and they are not well handled yet. We might need to improve tagging conventions for these cases.

I already do something similar to routes that go through GB/IE as a byproduct of having them in a rendering database there, as described here.

knooppuntnet’s coverage appears too limited to be generally useful.

Excellent! E2 has issues in England, it would be great if you could look into it using your tools.

As for Ireland, I don’t know the current status of E8. I can create the monitor in Knooppuntnet if someone is interested.

Any chance of a clue as to what the “issues” are :slight_smile: ?

Following the link I gave in my first message, you can see them at E2 east and E2 west. See below for a sample picture, and look at the red dots. Mind, there can be some false positives as said earlier. But I saw at least one role in a relation that seems wrong.

1 Like

What do you think the red dots mean?

My guesses might be being confused by relation order within parent relations (meh), or being confused by the alternatives here, but it would be useful for you to say what you think is actually wrong in this case.

Alternative routes are among the cases that confuse Knooppuntnet, we have a lot of those false positives in E5 and E9. When looking at a few examples of red dots on E2, I found some of those but I also found an ‘alternate’ role that seems wrong.

I also found ordering issues in superrelations that may need discussions. For instance in relation 1976184, Cleveland Way and Yorkshire Wolds Way should be contiguous I believe. But some issues may be related to the fact that official order for E2 (from ERA-FERP-EWV) is from North to South, that the main superrelation follows that order in OSM but apparently the UK part does not. I had to change the order of a couple of superrelations in France because of similar issues.

They are - see here and here.

That sounds like a bug in the tool, if it relies on a certain order of relations within a parent relation?

1 Like

Just like JOSM and Waymarkedtrails, and just like it does for the order of ways in a relation. Should there be a difference?

Josm doesn’t “rely” on relation order within a parent (although you can of course use it to reorder relation members), and Waymarked Trails seems to cope OK.

If anyone would like to reorder these, I’m sure that no-one would object.

JOSM before reordering:

JOSM after reordering:

There are remaining issues (red dots between segments) that I did not investigate, they may come from internal ordering issues in Yorkshire Wolds Way.

That is the goal of this thread: share and coordinate work among the (local?) volunteers willing to spend time clarifying and fixing issues (and probably finding missing data, in some areas).

1 Like

Looking at that list now, the “gap” in the Teesdale Way is just a result of braids either side of the river the other side of Barnard Castle. It is in one piece. I don’t know whether one is signed as the main route; the next time someone wants to check their eyesight they can go and have a look.

As discussed previously, the Wolds Way is the same. In that case there’s no E2 signage and the Wolds Way signage doesn’t distinguish which is the main route. It is in one piece.

“E2 (Humber Bridge)” also has braids (either side of the bridge) but is in one piece.

The Viking Way section down to Whitwell looks OK to me. See also here.

The “gap” between the Viking Way and the next link relation doesn’t seem to exist. I suspect that the tool is confused about the superroute having a way in it. I don’t think that there’s any E2 signage on the link relation and it doesn’t correspond to an “on the ground signed relation” so that bit I suspect is guesswork. Likewise this.

Yes, mixing ways and relations is a documented limitation of Knooppuntnet Monitor, an issue has been filed. Still, I believe I saw a discontinuity in the Yorkshire Wolds Way in JOSM. Did not investigate in JOSM, but the elevation profile of WMT seems to agree that something is amiss: Waymarked Trails - Hiking

That link didn’t work for me, but I suspect that’s just confused about (a) the order of the relations in the superrelation and (b) the detour into Market Weighton.

Edit: Try this and manually open the elevation profile.

In JOSM, the continuity line within a superroute indicates whether the relations connect to each other (if all the subrelations have been fully downloaded) AFAIK there is no way to order them geographically, except by hand. Superrelations containing variants and alternatives will always show gaps.
The continuity line in Knooppuntnet Monitor gives more information in one overview, including the hierarchy.

The link you gave links to Knooppuntnet Planner for hiking, that is a planner for Node Networks as found (only) in Belgium, Nederland, Duitsland, France and a small bicycle node network in Austria.

(Switzerland is in fact covered by a hiking node network, but they haven’t mapped it as such. The nodes and the routes are in OSM, so it would not be hard to turn it into an OSM Node Network; if that happens, the coverage of Knooppuntnet Planner can be easily extended for planning of hikes via the regular Swiss hiking network).

AFAIK, Knooppuntnet Monitor has no such limitation, and would also work in the US and Japan.

I think it’s not confused, it just has no way to display this collection relation as one continuous line. Then the supperrelation is not a single route, but a collection of routes, which are then displayed disjunct in the elevation profile.