Comparison of versions in history is broken

[OttawaHiking]

What steps will reproduce the problem?

1. Download object... relation 148838.
2. Select the relation (boundary[2] "United States") and click "History".
3. Click on tab "Members".
4. Compare versions 613 and 614 (the last two versions as of this writing).

What is the expected result?

JOSM is expects to highlight the differences between the two versions.

What happens instead?

JOSM shows incorrectly that the versions are very different, because version 613 is not shown properly.

Please provide any additional information below. Attach a screenshot if possible.

Version 613 (as it is on the server) could be seen by choosing to compare version 613 with itself, i.e., choosing version 613 in both column A and column B of the left panel.

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2020-04-06 02:17:07 +0200 (Mon, 06 Apr 2020)
Build-Date:2020-04-06 00:18:43
Revision:16239
Relative:URL: ^/trunk

Identification: JOSM/1.5 (16239 en) Windows 10 64-Bit
OS Build number: Windows 10 Pro 1909 (18363)
Memory Usage: 859 MB / 1794 MB (609 MB allocated, but free)
Java version: 1.8.0_181-b13, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: \Display0 1920x1080
Maximum Screen Size: 1920x1080
Dataset consistency test: No problems found

Plugins:
+ reverter (35409)
+ undelete (35405)

Last errors/warnings:
- W: org.openstreetmap.josm.tools.bugreport.BugReportSender$BugReportSenderException: java.net.SocketTimeoutException: connect timed out. Cause: java.net.SocketTimeoutException: connect timed out

[GerdP]

At a first glance I'd say you changed the order of the members.

[GerdP]

You even documented it in your changeset comment "Reordered boundary members". I suggest to revert the change for the very reason that it makes comparing the revisions difficult.

[OttawaHiking]

@GerdP: I uploaded images that show the initial members of versions 613 and 614. The first three members of both versions are the same, but the comparison is not catching this similarity. Is not it a problem?

Because I reordered segments of a very long boundary in a sequential way, without making any additional changes on the top, the resulting relation can serve as an excellent reference point for a number of following edits. OSM Inspector was complaining about the Contiguous United States boundary, so I opted to reorder its segments.

[OttawaHiking]

@GerdP: I guess you would argue that inversion of the sequence of members (regardless of their role in a relation) is giving a slightly better match in this case, so it was applied.

[GerdP]

Replying to OttawaHiking:

@GerdP: I guess you would argue that inversion of the sequence of members (regardless of their role in a relation) is giving a slightly better match in this case, so it was applied.

No, sorry, I got you wrong and was to lazy to double check :(
You are right I think what you see is an effect of this ticket: #6994
Still, the actual result for r148838 looks very different compared to picture shown in that ticket.

[GerdP]

OK, I've learned a lot of new things about this dialog. I see two possible improvements:

• When way nodes are compared, there is a small arrow indicating the order of the nodes. This is missing in the member list.
• It should be possible to change the displayed order manually.

[simon04]

Could you create an annotated screenshot to illustrate whatcan/should be improved? It's not obvious.

[GerdP]

1) The marked "Down" symbol next to the Nodes symbol should trigger some kind of reverse action when clicked, so that the compare is done with the reversed order. Not sure if it makes sense to click on the right one, I think the left is the reference.
2) The symbol (and the action) is missing in the members dialog.