Relation Editor should update after splitting a member

[Brait]

JOSM should, but don't update geometry in "Relation Editor" after changing geometry outside "Relation Editor" (in main JOSM window).

How reproduce: download any way with relation. For example, in main JOSM menu click "File" -> click "Download object" (or press shortcur key Ctrl+Shift+O on keyboard) -> dropdown menu "Object type:" switch to "way" -> in field "Object ID:" type number 97682988 -> "Download referrers (parent relations)" combobox should be checked -> click "Download object" button. Next, select downloaded way (name=River Thames), and open attached "waterway (River Thames)" relation in "Relation Editor". Now, leave "Relation Editor" window opened, and split downloaded way on two parts (select any middle node, and in main JOSM menu click "Tools" -> "Split way", or press shortcut key "P" key keyboard). After way splitting "Relation Editor" SHOULD UPDATE list of relation members (with new members geometry), but... don't do update. I think, this is defect.

====
[Sorry for my English]

[simon04]

In short:

1. Open attachment:example-11599.osm​​
2. Open the relation editor
3. With the relation editor open, split the way
4. The other split part is not added to the relation in the editor

I fear this is difficult to implement since the relation in the editor with its modifications is not part of the dataset.

[skyper]

Ticket #7070 has been marked as a duplicate of this ticket.

[skyper]

The same is true for combining ways plus deleting or adding members from toggle dialogs.

[skyper]

I think this is fixed with the "refresh button" and conflicts on save.

[taylor.smock]

I think this might be fixed by r15378.

[GerdP]

Interesting! I hit this problem today with r18513 and I had no idea why JOSM makes it so complicated to map a route relation. A route relation contained only 50% of the route and many wrong members, all in a weired order.
My workflow to correct it:
Open relation editor for the (already existing) route relation. Remove almost all members, so that only the correct start sequence remains.
Add a way member as last member, mark the last node and download refererres. Select the way that goes in the wanted direction and add it to the relation. Sometimes I find out that the last added way has to be split. When I do this without removing the member first I run into the problems described in this ticket. A refresh would remove all my changes. The conflict dialog is completely misleading because I thought someone else did an update.

[taylor.smock]

Maybe I misunderstood this ticket.

I thought it was the relation editor not updating the list of relation members when the user splits a way in the mapview. I had been thinking that it wasn't adding both members of the split way to the relation (the connectivity had changed).

In order to fix this, we would have to do one of two things:

1. Make conflict handling smarter (if we haven't changed the relation members around the split, just take the split)
2. Sync the editor changes to OSM and back on membership changes

I think I might have misunderstood the problem.

[GerdP]

I think the relation editor window doesn't update the member list automatically and that's probably wanted. TBH, I am not sure what I would prefer. Some kind of feedback, maybe even something like "Do you really want to split a member shown in the relation editor? This causes conflicts!". In my special use case (members are ordered properly) it is obvious which part of the way I want in the relation, but I know many cases where this isn't easy to detect.
The point is that it is very likely that you split ways when you create a route relation, and the current behaviour in JOSM is unintuitive.

[taylor.smock]

I'm more tempted to "save" the relation on focus loss, and reload it on focus gain. Possibly ask on loss/gain "You have left the relation editor. Do you want to save your current changes to avoid conflicts?".

[GerdP]

When exactly would that be asked? Think also about the case that multiple relation editor windows are open.
At the moment I see no easy solution, but probably skyper is more experienced here.
OT and whishful thinking: Allow to create a route from a given GPX file using some AI which detects the places where OSM ways are possibly missing or have to be split.

[taylor.smock]

Replying to GerdP:

When exactly would that be asked? Think also about the case that multiple relation editor windows are open.

Whenever the relation window loses focus, and whenever it regains focus. That should handle multiple relation editors (since not all of them are going to regain focus at the same time). Having multiple relation editors open for the same relation probably shouldn't be supported though.

At the moment I see no easy solution, but probably skyper is more experienced here.

Easy solution: just pay attention to the conflicts. :)

OT and whishful thinking: Allow to create a route from a given GPX file using some AI which detects the places where OSM ways are possibly missing or have to be split.

I don't think you would need AI for this. Just check if each point is within <x> distance of a road.

[skyper]

Wow, now it gets complicated, especially, regarding new unsaved relations and/or new ways (id:0) as members.
I am not sure, if the correct fix is to sync the relation editor each time the focus changes or better to watch the actions causing the conflicts outside the relation editor. E.g. all action adding or deleting memberships plus split, combine, delete and maybe actions removing nodes from ways.
Actually, I forgot why the relation manager is independent. One aspect could be the command stack and the problem that it does not work layer independent.

Replying to taylor.smock:

Replying to GerdP:

When exactly would that be asked? Think also about the case that multiple relation editor windows are open.

Whenever the relation window loses focus, and whenever it regains focus. That should handle multiple relation editors (since not all of them are going to regain focus at the same time).

This would add a lot of individual updates of the relation to the command stack. Even at the moment, the relation editor's cancel button might be misleading but at least you manually save or reload:

1. open the relation editor and make some changes
2. change focus
3. move focus back to the relation editor
4. Press cancel button

or

1. open the relation editor and make some changes and save relation
2. make some more changes
3. change focus
4. split or delete a member
5. move focus back to the relation editor
6. reload relation
7. Press cancel button

Having multiple relation editors open for the same relation probably shouldn't be supported though.

You cannot open more than one relation editor per relation but for each layer.

At the moment I see no easy solution, but probably skyper is more experienced here.

Easy solution: just pay attention to the conflicts. :)

That is tricky, you carefully need to watch the reload button of each relation editor. As soon as it is activated and the save button next to it, too, you need to undo your last change and save the relations in the relation editors before continuing.

Replying to GerdP:

My workflow to correct it:
Open relation editor for the (already existing) route relation. Remove almost all members, so that only the correct start sequence remains.
Add a way member as last member, mark the last node and download refererres. Select the way that goes in the wanted direction and add it to the relation. Sometimes I find out that the last added way has to be split. When I do this without removing the member first I run into the problems described in this ticket. A refresh would remove all my changes.

Yes splitting members is the most annoying action. My hint is to always save the relation in the relation editor after some major changes within the relation editor and never add a way that needs to be split.

The conflict dialog is completely misleading because I thought someone else did an update.

This is a different story. In fact it is always the same for conflicts between relation manager and data layer or between two data layers when merging or updating. Yes, conflict manager could be improved and there should be some tickets about it, already.

Replying to taylor.smock:

In order to fix this, we would have to do one of two things:

1. Make conflict handling smarter (if we haven't changed the relation members around the split, just take the split)

Actually, I would be happy about that but this is one of the easiest conflicts to find and to solve and I doubt it will work with #4509 in mind.