Modify

Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#17866 closed defect (wontfix)

Merge nodes: youngest instead of oldest id and history kept

Reported by: skyper Owned by: team
Priority: normal Milestone:
Component: Core Version: latest
Keywords: template_report merge node history id Cc:

Description (last modified by 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.

Attachments (1)

josm_17866_example.osm (3.7 KB) - added by skyper 3 years ago.
example file

Download all attachments as: .zip

Change History (15)

comment:1 Changed 3 years ago by skyper

Resolution: invalid
Status: newclosed

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

comment:2 Changed 3 years ago by skyper

Description: modified (diff)
Resolution: invalid
Status: closedreopened
Summary: Merging nodes: youngest instead of oldest id and history keptMerging undeleted node: youngest instead of oldest id and history kept

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

Need to find an example, again.

comment:3 Changed 3 years ago by skyper

Description: modified (diff)
Summary: Merging undeleted node: youngest instead of oldest id and history keptMerging nodes: youngest instead of oldest id and history kept

No undelete needed.

I add an example file.

Changed 3 years ago by skyper

Attachment: josm_17866_example.osm added

example file

comment:4 in reply to:  description Changed 3 years ago by 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.

comment:5 Changed 2 years ago by skyper

Keywords: id added
Summary: Merging nodes: youngest instead of oldest id and history keptMerge nodes: youngest instead of oldest id and history kept

comment:6 Changed 2 years ago by GerdP

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

comment:7 Changed 2 years ago by 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.

Last edited 2 years ago by skyper (previous) (diff)

comment:8 in reply to:  7 Changed 2 years ago by stoecker

Resolution: wontfix
Status: reopenedclosed

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.

comment:9 Changed 2 years ago by GerdP

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

comment:10 in reply to:  9 Changed 2 years ago by 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 :-)

comment:11 Changed 2 years ago by 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.

comment:12 in reply to:  11 Changed 2 years ago by 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.

comment:13 Changed 2 years ago by GerdP

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

comment:14 Changed 2 years ago by 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?

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.