Incorrect reorder of relation members when not all members are loaded

[vanjakom]

Initially I thought that issue is appearing when route is made circular, after discussion on Slack and looking into code I was able to narrow it down to case when relation is not fully loaded and new member is added.

How to reproduce:
https://preview.ideditor.com/release/#background=Bing&disable_features=boundaries&map=16.00/43.8434/22.3387
Select path going from centre to north-east, add it to hiking route "Вршка чука - Влашки до - кружна стаза". It will cause iD to add new member and reorder ways, even changing direction of route.
Revert back, before adding path to relation download missing members of relation, add path to relation and everything goes ok.

Maybe useful, I'm attaching v5 and v6 preview of relation. Relation is now reverted to v5 ( v7 = v5 ).

11164146.zip

Relation in question
https://www.openstreetmap.org/relation/11164146

[vanjakom]

Not sure if same bug happened today or this is something else, adding here until I investigate it further. During split of way which belongs to route iD did invalid reorder of elements. On attached images order is listed before and after change. Relation in question is https://www.openstreetmap.org/relation/11185515 and newly created way that introduced error is https://www.openstreetmap.org/way/814498225.

[vanjakom]

iD is also having trouble sorting route which is not fully mapped, happens with hiking routes

and correct order:

Will investigate further what was issue here.

[bhousel]

iD is also having trouble sorting route which is not fully mapped, happens with hiking routes

Yes, I don’t think iD will ever be able to handle this case very well, where the trail is not connected.

The way iD ordered it in your screenshot looks pretty good actually. It just ordered the disjoint segments beginning to end.

[vanjakom]

I understand, think I'm unable to understand is why iD tries to reorder from scratch. For example today I edited perfectly ordered route, simple edit, way which was part of relation is split into two and both ways stay in relation. Before edit I downloaded all ways and guideposts that belong to relation to ensure iD has all data that it needs. I ended up with completely reordered route.

With hiking routes I'm investing a lot of effort to order route as it should be when creating it, why would iD try to reorder it completely when someone performs minor edit later, as way split is? What am I missing?

Zip containing html examples of relation in question across different versions is attached.

10950281.zip

[DujaOSM]

If I may gently ping this towards the top of the backlog...

iD has just made a mincemeat out of my 300-members, 160-km long hiking route:
https://hiking.waymarkedtrails.org/#route?id=11510161&map=12!45.1463!19.7107
members are not reasonably sorted at all, moreover, the route runs in the wrong direction.

Even if I had got the order initially wrong, I could have fixed it by manually redragging. However, after iD's "friendly" reordering, there's no way I can fix it, even sorting 30 numbered control points was a pain. Please just disable the automatic sorting feature, or, better still, make it activated by a button on the relation sidebar rather than ruining [sic] silently in the background.

[yvecai]

This leads to very advice for beginners:
https://community.openstreetmap.org/t/how-to-divide-one-existing-trail-into-two-parts/109387/3