Opened 17 years ago

Last modified 10 years ago

#3384 new enhancement

Prevent modified status even if no real modification has been done — at Version 10

Reported by: anonymous Owned by: team
Priority: minor Milestone:
Component: Core Version: latest
Keywords: Cc: bilbo, skyper

Description (last modified by skyper)

Sometimes there are duplicate nodes in the map, however, if I merge two duplicated nodes (that are not used by anything else, like POIs), this should result in one of the nodes being deleted (and the other kept), however, the result is that one of the nodes is deleted and the other is flagged as modified, so it gets uploaded to server even when it have not changed at all.

This happend both when merging the nodes manually and when merging through validator ("fix" button on listing of duplicated nodes)

Attached is example of JOSM behavior:

dupnodefix-before.osm - situation before doing anything. Two identical nodes at same position
dupnodefix-after.osm - situation after fixing (merging nodes) - note that one of the nodes have action='delete', second have action='modify'

The result should be that only one of the nodes gets deleted and the other is kept intact.

Change History (13)

by anonymous, 17 years ago

Attachment: dupnodefix-before.osm​ added

before merging

by anonymous, 17 years ago

Attachment: dupnodefix-after.osm​ added

after merging

comment:1 by stoecker, 17 years ago

Priority: major → minor
Summary: Merge nodes does not work properly → Prevent modified status even if no real modification has been done
Type: defect → enhancement

Actually that is not restricted to nodes, but to all objects in JOSM. The node is actually changed, as it contains the joined tags of both nodes.

JOSM misses a way to detect changes which actually do not change the object at all. This also applies to changes which have been done and later reversed.

comment:2 by anonymous, 17 years ago

While this can happen also in other ways (some value changed to something and later back), the problem when merging nodes is probably the most common, as nodes usually have same values when merging. Therefore, the merge could check if keys are the same and if they are, donot modify the node (and just drop the others).

I've done small patch that does that, attaching it here...

by anonymous, 17 years ago

Attachment: mergenodes.patch​ added

Patch to not modify the node while merging if it is not modified

comment:3 by stoecker, 17 years ago

Summary: Prevent modified status even if no real modification has been done → [partial PATCH] Prevent modified status even if no real modification has been done

comment:4 by Gubaer, 17 years ago

Resolution: → fixed
Status: new → closed

(In [2064]) applied #3384: patch by anonymous: Prevent modified status even if no real modification has been done)

comment:5 by Gubaer, 17 years ago

Resolution: fixed
Status: closed → reopened

mergenodes.patch applied in r2064, but reopening the ticket which has a much broader scope.

comment:6 by Gubaer, 17 years ago

Summary: [partial PATCH] Prevent modified status even if no real modification has been done → Prevent modified status even if no real modification has been done

comment:7 by anonymous, 17 years ago

Status: reopened → new

A note: Use "see #xxxx" instead of "fixed #xxxx" or "applied #xxxx" to reference a bug without closing :-)

comment:8 by bilbo, 17 years ago

Cc: bilbo added

comment:9 by Don-vip, 12 years ago

Ticket #3804 has been marked as a duplicate of this ticket.

comment:10 by skyper, 12 years ago

Cc: skyper added
Description: modified (diff)
Note: See TracTickets for help on using tickets.