Opened 14 years ago
Last modified 7 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)
Changed 14 years ago by
| Attachment: | dupnodefix-before.osm added |
|---|
comment:1 Changed 14 years ago by
| 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 Changed 14 years ago by
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...
Changed 14 years ago by
| Attachment: | mergenodes.patch added |
|---|
Patch to not modify the node while merging if it is not modified
comment:3 Changed 14 years ago by
| 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 Changed 14 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:5 Changed 14 years ago by
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
mergenodes.patch applied in r2064, but reopening the ticket which has a much broader scope.
comment:6 Changed 14 years ago by
| 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 Changed 14 years ago by
| Status: | reopened → new |
|---|
A note: Use "see #xxxx" instead of "fixed #xxxx" or "applied #xxxx" to reference a bug without closing :-)
comment:8 Changed 14 years ago by
| Cc: | bilbo added |
|---|
comment:10 Changed 9 years ago by
| Cc: | skyper added |
|---|---|
| Description: | modified (diff) |
comment:11 Changed 9 years ago by
So the only way for ways to prevent a new version is to purge it, atm.
before merging