id summary reporter owner description type status priority milestone component version resolution keywords cc 24956 "[RFC PATCH] Way ""modified"" flag should be based on node IDs, not coordinates" mattmccutchen team "Generally, if the user changes a primitive and then manually reverts the change (without using ""undo""), JOSM doesn't automatically clear the modified flag, but any command that re-downloads the primitive (such as ""Update modified"") will clear the modified flag (see #3384 and ticket:17983#comment:1). However, for a way, the decision to clear the modified flag is based on the coordinates of the nodes in the way. This does not match the OSM data model, which stores only the node IDs. As a result, if a node has been moved, the way can get stuck in the ""modified"" state. This is confusing when I'm reviewing my own change by searching for `modified` objects, and a new version can even get uploaded that has no diff from the previous version. The latter happened to me in [https://www.openstreetmap.org/changeset/184037358 changeset 184037358] ([https://www.openstreetmap.org/way/1155668688/history/3 affected way 1], [https://www.openstreetmap.org/way/1234242974/history/7 affected way 2]). There's also a reverse scenario in which there are two nodes N1 and N2 at the same coordinates and a way W that contained N1 is modified to contain N2 instead. An ""Update modified"" will mark W as unmodified because the node coordinates match. At that point, the history dialog will show no diff and an upload will not upload W because it is marked unmodified. But internally, W still contains N2! If the user then makes some other change to W and uploads it, the replacement of N1 with N2 will get uploaded along with the other change. This is potentially dangerous because a change is uploaded potentially without the user's knowledge. Fortunately, I think the scenario is rare because duplicate nodes are discouraged. Also fortunately, if W is updated a second time (""Update modified"" would not do it, but ""Update data"" would, for example), it gets reverted to contain N1. I'm going to focus on the first scenario in this ticket. ==== What steps will reproduce the problem? 1. Download some data. 2. Move a node that belongs to a way. 3. Search for `modified`. Only the node is selected. 4. Change a tag of the way, then change it back manually (not using ""undo""). 5. Search for `modified`. Both the node and the way are selected. 6. Perform the ""Update modified"" command. 7. Search for `modified`. ==== What is the expected result? In step 7, only the node is selected. ==== What happens instead? Both the node and the way are selected. ==== Please provide any additional information below. Attach a screenshot if possible. The behavior is coming from [https://github.com/JOSM/josm/blob/9eace0f57c6ebc551b8012e0cebc6c9b4c63e88c/src/org/openstreetmap/josm/data/osm/Way.java#L329-L330 this code] in `Way.hasEqualSemanticAttributes`. Changing `Way.hasEqualSemanticAttributes` to compare node IDs instead of coordinates (as [https://github.com/JOSM/josm/blob/9eace0f57c6ebc551b8012e0cebc6c9b4c63e88c/src/org/openstreetmap/josm/data/osm/Relation.java#L324 it does for relations]) fixes the bug. But I wonder why `Way.hasEqualSemanticAttributes` was written to compare coordinates. Are there other use cases that rely on it? A wild guess: do some users rely on that behavior to deduplicate ""new"" ways when merging layers? If so, a possible compromise might be to have `Way.hasEqualSemanticAttributes` compare the coordinates of a node if it is ""new"" and the ID if it is not ""new"". To help get things moving, I'll attach a patch that just changes `Way.hasEqualSemanticAttributes` to compare node IDs. However, even if that approach is acceptable, I think it might help to have at least one unit test of the scenario from this ticket to help ensure that someone doesn't change the code back without being aware of the scenario. Any advice on how to write such a test would be appreciated. Side remark: I noticed that the map paint style for ""Modified objects"" shows the way as modified starting from step 2. I haven't figured out why that's happening, but I think it's a separate issue and I'll file a separate ticket if I care about it. {{{ Relative:URL: ^/trunk Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Last:Changed Date: 2026-10-12 17:25:48 +0200 (Mon, 12 Oct 2026) Revision:19647 Build-Date:2026-10-13 01:30:50 URL:https://josm.openstreetmap.de/svn/trunk Identification: JOSM/1.5 (19647 en) Linux Fedora Linux 44 (Forty Four) Memory Usage: 240 MB / 4072 MB (38 MB allocated, but free) Java version: 25.0.4.1+1, Red Hat, Inc., OpenJDK 64-Bit Server VM Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel Screen: :0.0 1920x1080x[Multi depth]@46Hz (scaling 1.00×1.00) Maximum Screen Size: 1920×1080 Best cursor sizes: 16×16→16×16, 32×32→32×32 Environment variable LANG: en_US.utf8 System property file.encoding: UTF-8 System property sun.jnu.encoding: UTF-8 Locale info: en_US Numbers with default locale: 1234567890 -> 1234567890 Desktop environment: X-QUBES VM arguments: [--add-exports=java.base/sun.security.action=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.spi=ALL-UNNAMED, -Djosm.home=] Dataset consistency test: No problems found }}} " defect new normal Core template_report