#19161 closed enhancement (fixed)
History browser: relation member table lacks reversed diff incidator
Reported by: | OttawaHiking | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | 20.05 |
Component: | Core | Version: | tested |
Keywords: | history; versions; members, comparison | Cc: | Don-vip |
Description (last modified by )
What steps will reproduce the problem?
- Download object... relation 148838.
- Select the relation (boundary[2] "United States") and click "History".
- Click on tab "Members".
- 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
Attachments (5)
Change History (21)
by , 4 years ago
Attachment: | History for relation 148838.jpg added |
---|
comment:1 by , 4 years ago
comment:2 by , 4 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
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.
by , 4 years ago
Attachment: | version 613.jpg added |
---|
by , 4 years ago
Attachment: | version 614.jpg added |
---|
comment:3 by , 4 years ago
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
@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.
follow-up: 5 comment:4 by , 4 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
@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.
comment:5 by , 4 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
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.
comment:6 by , 4 years ago
Cc: | added |
---|---|
Type: | defect → enhancement |
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.
comment:7 by , 4 years ago
Could you create an annotated screenshot to illustrate whatcan/should be improved? It's not obvious.
by , 4 years ago
follow-up: 11 comment:8 by , 4 years ago
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.
comment:9 by , 4 years ago
Description: | modified (diff) |
---|
by , 4 years ago
Attachment: | 2020-05-17-220545_1118x658_scrot.png added |
---|
comment:11 by , 4 years ago
Replying to 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.
Allowing the user to manually change the sorting of any of the two tables, and taking the possibly reversed diff output into account, sounds difficult to get right and super error prone for (in my opinion) little value gained.
comment:12 by , 4 years ago
Milestone: | → 20.05 |
---|
comment:13 by , 4 years ago
What do you think about a new column for the position of the node/member? Might make it clearer that the order is changed.
comment:14 by , 4 years ago
Indeed, this would make it very clear and should be also adopted for the NodeListViewer of ways.
comment:15 by , 4 years ago
Summary: | Comparison of versions in history is broken → History browser: relation member table lacks reversed diff incidator |
---|
comment:16 by , 4 years ago
Description: | modified (diff) |
---|
At a first glance I'd say you changed the order of the members.