There is a lot of potential for improvements to route relation editing (bus lines, bicycle routes, etc) that would massively speed up making and maintaining route relations. The concepts below I’ve been brooding on for a while now. I’m putting them up here in case someone is inspired to implement them (as a plugin, or directly in an editor).
1. Pathfinding
The user selects one road, then a second road; the editor calculates the shortest path in between them using the data it already has, and adds these to the relation.[1] When relevant, it calculates in both directions, and uses the forward/backward roles as appropriate. It shows the newly added path, and the user can visually check that it matches expectations.
Something like this has been proposed in 2019, but hopefully I can work up an itch with someone to develop this.
2. Rerouting multiple routes
When road infrastructure has changed where a lot of buses pass, it’s a pain to update all the relations. An editor could identify routes following a similar trajectory across an area and allow manipulation of this subroute at once.
Edit: Simon Poole shared a trick using temporary ways so #2 is not a priority.
If some ways are already in the relation, possibly they could be moved to the correct place, but there is an important edge case when a route needs to have segments twice, e.g. a bus looping back on its own route. ↩︎
As it stands, all the bus routes will have to be modified one-by-oneusing a hack with temporary ways to use the new tunnel to the east. But they have a lot of roads in common, which could be detected and so the routes modified in bulk.
I would note that there are super simple methods to reroute bus routes without having to do them one by one with essentially every editor that supports relations (tip: use temporary ways).
Chop off a piece of a way that is a member of the relations in question move it to way that is going to be a new member of those relations, join and merge, chop off and repeat as necessary. Not the most elegant but it moves the lower bound of how simple alternative methods have to be to make sense.
I’ve used this trick (worthy of the descriptor “hack” imo ) just now in JOSM. The members ended up being in the wrong order, but I suppose that with more care that could be avoided (at worst doing it twice, if the relations are sorted differently). And granted, opening every relation to hit Sort is less cumbersome than having to do the bulk of the editing manually.
The sorting bit is an issue in any ‘fix’ for this, as route relations don’t contain enough information to be automatically ordered. It is possible to do this correctly incrementally for splits (and naturally for mergers) and presumably would work for an automatic ‘replace’ service. Definitely trying to automatic sort a PT route is a bad idea.
I don’t see how this would help to re-route relations around a construction, but it might be depending on the amount of way segments.
In jOSM I would rather create a temporary relation, to have a collection of the new road segment and then paste that section at the proper position of all the effected relations.
@M_dgard, maybe something like relatify is what you are looking for (and I agree, it would be great to have something like it jOSM).
I can’t imagine a relation editor to reliably automate multi-relation tasks (e.g. applying a route change to multiple routes, or adapting multiple PT-lines for a new roundabout) for all types of route relations. I can imagine it for a simple subcategory, e.g. hiking routes, but even then I think I would almost never use it.
I would rather have e.g. a clever bicycle route modeler to help with bidirectional bicycle routes with direction splits in the middle and/or at the ends. And, add a “copy” function between route relations, so I can correct a section in one and copy it to the other (now only replace is available, so I need annoying trickery).
(as an example:) I was very happy when the sort function in JOSM was improved to do bidirectional sort even when the end points were split points (bicycle route ending/starting at different sides of the road).
) just now in JOSM. The members ended up being in the wrong order, but I suppose that with more care that could be avoided (at worst doing it twice, if the relations are sorted differently). And granted, opening every relation to hit Sort is less cumbersome than having to do the bulk of the editing manually.