Modify

Opened 22 months ago

Closed 14 months ago

Last modified 14 months 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 22 months ago.
example file

Download all attachments as: .zip

Change History (15)

comment:1 Changed 22 months ago by skyper

Resolution: invalid
Status: newclosed

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

comment:2 Changed 22 months 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 22 months 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 22 months ago by skyper

Attachment: josm_17866_example.osm added

example file

comment:4 in reply to:  description Changed 22 months 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 14 months 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 14 months ago by GerdP

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

comment:7 Changed 14 months 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 14 months ago by skyper (previous) (diff)

comment:8 in reply to:  7 Changed 14 months 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 14 months 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 14 months 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 14 months 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 14 months 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 14 months ago by GerdP

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

comment:14 Changed 14 months 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.