Route relations are broken by iD

[Yogurt4]

When someone edits ways that are part of a route relation (like cutting a way in two, or to delete a piece and draw a new way instead), iD most often corrupts the order of relation members. Even though the order would be very important for routes. Both OSMI, Osmose and JOSM display a "relation contains a gap" error for such relations.

The situation with iD is so bad that you may check the history of FlixBus routes, for example. A great deal of the versions is about "fix the gap" or "correct order" - after someone's edits with iD. Here we are in a continuous daily work to check and fix public transport routes. And it's an endless job as they get corrupted again and again.

a.) When having a route of A->B->C and the middle way is split in two, the proper order could be A->B'->New->C, or A->New->B'->C. So far I could not deduce a sure way of telling which one will happen.

• It might depend on the order of the nodes in the way: the first node stays in B', the last node gets into New.
• It might depend on the number of nodes: most nodes stay in B', the less nodes get into New.
• It might depend on distance: the longer part stays in B', the shorter one gets into New.
• It might be completely random, depending on node IDs or some internal map/tree/hash.

Algorithm-wise it is a simple task to decide the correct order so that chain remains intact.

b.) When adding a new way to a (route) relation, it's often added to the end of the members. Even if that way was added to mend a gap.
iD should walk along the existing relation members and check if the new way is connected to one of them. Of course, things get much more complicated in case of multiple connections (when having loops in the graph, like the two sides of a roundabout) but iD doesn't have to solve all these tricky situations perfectly.

c.) iD could also check the order of route member ways and give the user a warning.

[1ec5]

iD should walk along the existing relation members and check if the new way is connected to one of them. Of course, things get much more complicated in case of multiple connections (when having loops in the graph, like the two sides of a roundabout) but iD doesn't have to solve all these tricky situations perfectly.

Apparently iD does attempt to do this, as seen in some tests, but perhaps there are some cases that are being handled suboptimally.

[matkoniecz]

Can you give example of changeset where breakage was caused by iD?

[Yogurt4]

1. For example changeset #101007031.
   If I see it right, the user split way 348179105 into two. The new way is 917172308.
   Even though it's at the very beginning of a route, it got inserted between the first and the second members of relation 5189472.

2. There is relation 5189473. The new member is way 917172315. It became the second member instead of being the 3rd one, mixed up with its parent way 348179087. Same changeset.

3. Then, 32 minutes later, the same user made another edit to this relation in changeset #101007928. Somehow the 348179087 way got moved from the (incorrect) 3rd position to be the 8th member.

[Elefant-aus-Wuppertal]

Another example might be https://www.openstreetmap.org/changeset/101433951, where
https://www.openstreetmap.org/way/920068254
and
https://www.openstreetmap.org/way/334914447

are wrongly sorted into
https://www.openstreetmap.org/relation/1732029
and
https://www.openstreetmap.org/relation/1732028

[Elefant-aus-Wuppertal]

Maybe anyone knows how to solve this or where in the code the problem is? Unfortunately, I coulnd't find it because I'm not that knowledgeable in this...

[1ec5]

When having a route of A->B->C and the middle way is split in two, the proper order could be A->B'->New->C, or A->New->B'->C. So far I could not deduce a sure way of telling which one will happen.

#8839 fixes a regression in how the two ways resulting from a split are inserted into a simple linear relation. It might address some of the examples given here, even if the trickier issue with nonlinear routes remains elusive.

[urbalazs]

This bug is very annoying. Just take a look at https://tools.geofabrik.de/osmi/ --> Public Transport - Routes view --> Invalid routes. I have no exact numbers, but in most cases the user changed something with iD editor. Same applied for other relations: iD breaks them. Can I ask to handle this bug with higher priority?

[Elefant-aus-Wuppertal]

Could it be that the solution of #8519 has fixed this issue here, too?

[Mahabarata]

Here another example of broken route relations (of a public transport version 2).

This relation is a "special" case : the bus arrives at a roundabout, follows a loop, comes back to the roundabout and continue on another way. The roundabout is here : https://www.openstreetmap.org/edit#map=20/4.88977/-52.33256

Select the roundabout then select the relation "Bus 9 : Encre -> Lycée Balata" : the current version (27) of this relation is ok (I mean the order of the ways) : the roundabout is twice in the relation with ways between them (the loop).

Now select the way on the right of the roundanout (https://www.openstreetmap.org/way/362487805) and cut it.

Select the route relation and look at the order : the 2 roundabout ways are one after the other and the loop is broken (the first way of the loop in no more at the good place : there is a gap between the roundabout and the parking_aisle).

This issue was opened almost 3 years ago, same thing for the issue #8578 : could you please look at them quickly and fix (at least) this special case ?

[olafkryus]

This issue is certainly still not fixed.

Most recent example I've stumbled upon:
https://www.openstreetmap.org/changeset/147754096
Splitting ways in one area resulted in de-sorting already correctly sorted looping fragment in another area for relation
https://www.openstreetmap.org/relation/2879235

Unfortunately it is a commonly recurring annoyance, but I wonder whether providing more examples regularly would be of any help?

[tordans]

but I wonder whether providing more examples regularly would be of any help?

I do not think it is. At least unless there is work being done on the issue which I do not see happening any time soon.

[tyrasd]

this might be the same issue as #7653

[1ec5]

This relation is a "special" case : the bus arrives at a roundabout, follows a loop, comes back to the roundabout and continue on another way.

This relation contains this entire roundabout twice, which makes the route non-linear. If we were to split the roundabout, modeling the actual path of the vehicle through it both times, then it would be linear and iD would be much less likely to scramble the member order.

#7653 compounds the problem, but as long as a full roundabout loop is part of the relation, scrambling could occur even if the full relation is loaded.

[tyrasd]

this should be fixed with #10149