Opened 15 years ago
Last modified 8 years ago
#3384 new enhancement
Prevent modified status even if no real modification has been done
Reported by: | anonymous | Owned by: | team |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | Core | Version: | latest |
Keywords: | Cc: | bilbo, skyper |
Description (last modified by )
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.
Attachments (3)
Change History (15)
by , 15 years ago
Attachment: | dupnodefix-before.osm added |
---|
comment:1 by , 15 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 , 15 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 , 15 years ago
Attachment: | mergenodes.patch added |
---|
Patch to not modify the node while merging if it is not modified
comment:3 by , 15 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 , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:5 by , 15 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 , 15 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 , 15 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 , 15 years ago
Cc: | added |
---|
comment:10 by , 10 years ago
Cc: | added |
---|---|
Description: | modified (diff) |
before merging