Merge nodes: youngest instead of oldest id and history kept

[skyper]

What steps will reproduce the problem?

1. Have an node and another node with higher id than the first one.(568979540, 3825090301)
2. select them (order does not matter)
3. merge them with menu function or keyboard shortcut 'm'

What is the expected result?

Lowest Id and history of the oldest node is used/preserved.

What happens instead?

Id and history of the younger node is used.

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

Thought the order of selection did matter some time ago.
Strange, it seems to happen only on some sessions.

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2019-06-24 20:49:39 +0200 (Mon, 24 Jun 2019)
Build-Date:2019-06-25 01:30:58
Revision:15195
Relative:URL: ^/trunk

Last errors/warnings:
- W: No configuration settings found.  Using hardcoded default values for all pools.

[skyper]

Strange, now I can not reproduce. Damn, should have kept the example.

[skyper]

Forgot about that I had undeleted (edited) the older node.

Need to find an example, again.

[skyper]

No undelete needed.

I add an example file.

[skyper]

example file

[skyper]

Replying to skyper:

Strange, it seems to happen only on some sessions.

Some thing strange is going on:
It seems to work as expected for all nodes except the one with tags where always the id of the untagged node is used.

Had this problem with two tagged nodes as well, today. Quite annoying to watch the ids on every merge and once it happens you need to construct around with temporary objects.

[GerdP]

The current code prefers to keep the node which has parents.
See r5989 (#8760)

[skyper]

Oh, I see, it tries to make less changes as possible. It uses the lowest, positive id of objects with parent and if there are no parent objects it uses the lowest, positive id. So, in my example, the reason is the way which is parent of one node.

I understand the logic behind it, though, for a user experience this is too complicated and there is no option to make a manual decision but to construct around.

Note: Combine Ways does not take relations into account.

[stoecker]

Replying to skyper:

Oh, I see, it tries to make less changes as possible. It uses the lowest, positive id of objects with parent and if there are no parent objects it uses the lowest, positive id. So, in my example, the reason is the way which is parent of one node.

I understand the logic behind it, though, for a user experience this is too complicated and there is no option to make a manual decision but to construct around.

Note: Combine Ways does not take relations into account.

Regarding "user experience" - A normal user does not really see the node history - that's way under hood of the software. As the API has no real dependency tree there always will be situations where the users looking at such things don't get what they expect. JOSM usually tries the best with the available possibilities.

[GerdP]

@Dirk: Did not yet check Combine Way, but I think it would be a good idea to have common code for this decision.

[stoecker]

Replying to GerdP:

@Dirk: Did not yet check Combine Way, but I think it would be a good idea to have common code for this decision.

If it feasible and you want to do it, why not. But I personally would vote for spending time on more important tickets :-)

[GerdP]

Sorry, should have looked first. Combine Way shows the CombinePrimitiveResolverDialog when any of the combined ways is memmeber of a relation. So, nothing to do here and I think the current stategy used in MergeNodes is OK.

[skyper]

No, JOSM does not use the logic to prevent unneeded changes of relations when combining ways and choosing the id of the remaining way.

[GerdP]

You are right. Is there already a ticket for this?

[GerdP]

I didn't find one, but I think that Combine Ways doesn't ignore the order in which you select the ways, so maybe users don't expect a change here?