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.

[Lukas458]

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

[Lukas458]

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?

[Lukas458]

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