In the OSM Wiki there are already various great overview pages for routes, such as the page for the D-Netz cycle routes These lists also include the corresponding relations.
Currently, the status (e.g. whether the relation is complete) is entered manually – and this information quickly becomes outdated especially once it is 100% and a relation > 300 km, since relations are constantly changing on such a long distance.
To access the state of a relation, I currently use Waymarked Trails. There it is automatically shown whether a relation is complete and properly ordered. That’s a great tool!
My proposal is that the status of a relation (sorted / unsorted / incomplete) should be displayed automatically – similar to how Waymarked Trails does it. additional to the manually entered state. Ideally, this would be shown directly in the Wiki overviews.
This way, it would be immediately visible if a relation needs fixing, without having to manually check it each time. One option could be a script or bot that regularly analyzes the relations and updates the status automatically.
I am a programmer, but new to the wiki world and know nothing about the API, yet. So I’d be interested to hear your thoughts:
Would you find such an automatic status display useful?
Are there existing approaches that could be used alternatively?
When I started coding [PTNA](https://ptna.openstreetmap.de) for public transport routes back in 2017, this tool used to create the result pages in the OSM wiki. That wasn’t really a good idea, because uploading the data triggered a page-rendering process which sometimes took 2-3 minutes to complete inducing a high load on the server. I really soon got a message to stop this.
PTNA does analyse route and route_master relations for public transport. I could imagine of a fork of this handling cycle, hiking, … routes.
But: those cycle, hiking, … routes are much more challenging regarding sorting, completeness, …
Just read the explanation about sorting, … on the waymarked trail site (I don’t have the URL at hand).
Surely that will have to continue to be the case, since it requires a mapper to notice the new signage?
Maybe in the future we can foresee a fleet of OSM drones monitoring long distance paths for landslides or other rerouting, but I suspect that day is some time off…
What I’m actually trying to solve is that many routes are edited somewhere, and in the process, a section is split off here and there and then not included in the relation. (Which is perfectly fine, since we all have different skills and areas of focus…) This fragments the relation, even though it’s probably 99.9% correct but there is a gap. I would like to be able to see this represented in any table. Waymarktrails is already doing a great job here, but I thought the wiki would also be a useful place for this. I wasn’t familiar with PTNA before, but I’ll take a look at it - Thanks!
I don’t want to solve this problem with my suggestion. It’s okay to leave the house. I don’t need drones or Wall-E to do that for me. But this way I can better control the destination of my next tour.
Ah! I understand what you mean now. I do that by having a series of scripts that check for changes to a relation in an osm2pgsql database, that email me when something changes, but that’s just one example of how to deal with them - lots of other tools exist.
A gap is not always an error - this gap in a cycle route was introduced deliberately by the route operator.
This is exactly what PTNA does for the so-called PTv2 type of routes. PTv2 is quite strict regarding the order of the members of a route relation. Much more strict than for cycle, hiking, … routes.
Actually all routes have the same ordering issues, it is just that such situations are less common than with PT routes and, might, have less impact when they are wrong.