For those of us who have not yet noticed, Waymarkedtrails now has an improved quality assurance system for route relations, both:
in the routes panel, with red / green / “orange” icons attached to route names: red means broken, green means OK, “orange” (actually, a brownish icon) means there is a relation ordering issue.
on the map itself, with a very clear representation of the main route and its alternatives, excursions, approaches, etc as well as red circles where the route is broken (plus dashed lines that show how the algorithm attempts to reconstruct the route)
This constitutes a very useful addition to Knooppuntnet.nl that some of us already used to maintain route relations. Please note that sometimes the algorithm in Waymarkedtrails is picky about route structure; for instance, it does not like it when there are both sub-relations and ways in a relation; also, I found no solution to deal with routes that have two main branches, e.g. Relation: Via Turonensis (6026933) | OpenStreetMap; and I noticed that Waymarkedtrails does not make a fuss over foot=no on ways while it probably should.
I have successfully used this new function for both routine maintenance and a few remaining structural issues in France, with very satisfactory results. Now you may notice that some work remains on international routes (see below). Any interested organizing a group effort in all countries to get international routes routable?
That should work just fine, as long as it is properly used, e.g if you put the same way in the relation and in the subrelation, then the way will appear twice.
That said, I wouldn’t recommend mixing ways and relations because it is simply confusing to handle for mappers.
That likely will never be supported. Any particular reason why one of them cannot be an alternative?
Are you sure? In all honesty, I must say that there were many times when I thought that Waymarkedtrails was wrong and I later found an issue in the relation that explained the red sign. But here, I believe that I have tested quite thoroughly (although switching multiple times from JOSM’s relation editor to Waymarkedtrails might have blurred my mind)
I believe we discussed this already, and you yourself considered that E2 should be treated as one route and not two routes (E2 east and E2 west). It happens sometimes that route designers do not choose to treat two branches as a main route and an alternative, just as two branches.
EDIT: and sometimes there are even wilder beasts, with multiple branches or multiple loops that the designer explicitly documents as being of the same importance. One could argue that node networks are the ultimate case of that. I believe that the goal is to spread the number of hikers on the trails.
I don’t see the alternative role as making any qualitative judgement. It just says that there is another route that can be chosen. If your route has two main branches just chose one to tag as alternative at random and be done with it.
I’ve been on record for arguing that these are not routes but really just networks of foot-worthy ways. They are out-of-scope for waymarkedtrails’ QA support. I might given them their own category one day, similar to the base networks.
I would consider that as a case of “tagging for the QA system”, sorry. In Waymarkedtrails, for instance, one is displayed with a continuous line and the other with a dashed line. Talk about qualitative judgement But these are edge cases, and maybe we can discuss them elsewhere. My goal here was more to propose that we launch a quality assurance campaign on international routes.
So, basically you don’t want to use alternative because you don’t like that it gets rendered in dashed lines…
You clearly have the situation here that the user has two alternatives and they have to decide to use one of the two. If they are of equal importance or not is not relevant. The user still has to decide. I can’t think of a better word than alternative for this situation but feel free to use a different role name. Marking that a part of the route is not linear but split up in some way or another would still be helpful.
(lots of red dots, and red dotted lines between them)
then what’s most likely to be the problem, and what to do about it? Are the segments found in the wrong order?
I hope one day we will have a “how to perform quality assurance on route relations” wiki entry that will help new users get started with good route relation mapping. I hope @lonvia 's diary entry will be part of it.
I have used the Waymarkedtrails QA system for a few days in a row until the French national routes or part of international routes were OK. A practice has emerged during that period. And I must confess that, when I see this, I take it as a sign that it is time to copy the relation number, switch to JOSM, open the relation and work with the relation editor.
With keeping in mind at all times the quirks of the continuity analysis in the JOSM relation editor, of course.
As for E4 in Cyprus, I remember from the Knooppuntnet analysis that it looks like ordering problems. But it’s best to check with JOSM.
I know of two ways to reorder members in relations with iD
In the first method, you click on the member in the list (not on the link, more on the right of the rectangle) and you move it where you want. You can scroll the list while “grabbing” the member to speed up movement, or you can drop it, scroll the list, and pick it again.
This is very awkward, and knowing where you are and what you need to do next can be awkward too. That is what people mean when they say that you cannot manage relations with iD. But, combined with Knooppuntnet, I have done it sometimes.
in the second method, you use iD’s current ability to auto-sort relations that contain ways only. It works only when the relation is complete (no missing segments). What I do then is remove a member from the relation, then re-add it. Usually, iD succeeds in sorting the relation.
That’s an unsorted route. Waymarkedtrails is generally okay with that as long as it can put the segments in a linear order. If it can’t then it just keeps the order it finds in the relation and then the “Route Analysis” view is currently a little bit useless. I try to improve that soonish.
That said, most of the red dots in that route seem to be caused by real issues and not the order. Just zoom in on the red dots and you’ll quickly see them. The eastern side is missing quite a few alternate roles and there are lots of little extrusions like these two:
As the original poster I decree that this is the main thread and the other one is the alternative and can safely be tagged as such. Nobody will accuse you of tagging for your own purposes
@lonvia just a clarification, likely of general interest: I’m assuming the blue dots “More than two segments of the route meet in this point.” are just purely informative?
It would seem that you would always have three segments meeting at the start or end of segments that can only be traversed in one direction (and which have forward/backward roles).
I’ve slightly changed the display in the route analyser so that the split points have different colors: Red ones are open ended, those always need checking where they are not at the beginning and end of the route. Cyan ones are points where more than two ways meet. Usually there is an issue with forward/backward around those. And grey ones are a normal linear connection which is just broken because of route order. Ignore those if you don’t care about order.
Split sections with forward and backward section are handled as a being a single line, if waymarkedtrails is able to put them together correctly. Thus there is no cyan point at the beginning and end. However, note that this only works when the ways for the forward and backward section appear together in the relation and are ordered.
Same as JOSM. The elements of each part of the split section must be sequentially ordered from the start to the finish point. You can mix elements from the different parts though. If the route is ordered, then the direction of the sections must follow the direction of the route. If you don’t care about order, then either will do.
If the route is sorted, then even a loop created from forward and backward direction will work. But that really only works for sorted roues because there is no way to guess where the forward section ends and the backward section starts.
Things would be a lot easier if we had roles that are defined relative to the route direction. But that ship has sailed.
No, it does not need to be ordered and, no, it is not easily done on the application side. It could be easily done if all routes in OSM were perfectly linear after sorting but that’s simply not the case. Lots of routes have errors like holes or extrusions. We have routes where the designers outsource the choice of which way to take to the user, as well showcased by @StC in this thread, and then there are relations that are really just collections but still tagged as route.
But these are edge cases, and maybe we can discuss them elsewhere. My goal here was more to propose that we launch a quality assurance campaign on international routes.
