Nodes that are not changed are included in changeset?

[tomasmarklund]

What steps will reproduce the problem?

1. Download a railway-way which has directional-dependent node tags (Railway signals), for example way ​https://www.openstreetmap.org/way/28787650
2. reverse the direction of the way. The directional-dependent tags for the signals are also reversed

railway:signal:direction=backward --> forward
railway:signal:position=right --> left
This is correct!

3. reverse the direction of the way again, back to the original direction. The directional-dependent tags for the signals are also reversed (again),

railway:signal:direction=forward --> backward
railway:signal:position=left --> right
This is also correct!

4. Upload

What is the expected result?

Since the values of the tags are exactly as they already are saved in the database, these nodes should not be included in the changeset, since they are not changed. Niether the tags, nor the position

What happens instead?

Nodes ARE included in the changeset as "changed", and the nodes will have a new history version in the database.

Please provide any additional information below. Attach a screenshot if possible.

Example of a node that exists in 4 versions, where version 2, 3 and 4 are identical

​https://www.openstreetmap.org/node/1501420752/history

I believe (without proof) that this has not been the case earlier.. but I am not sure.

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2022-01-02 21:24:43 +0100 (Sun, 02 Jan 2022)
Build-Date:2022-01-02 20:26:19
Revision:18360
Relative:URL: ^/trunk

Identification: JOSM/1.5 (18360 sv) Windows 10 64-Bit
OS Build number: Windows 10 Home 2004 (19041)
Memory Usage: 910 MB / 910 MB (133 MB allocated, but free)
Java version: 1.8.0_321-b07, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Look and Feel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
Screen: \Display0 2560×1440 (scaling 1.00×1.00) \Display1 1920×1080 (scaling 1.00×1.00)
Maximum Screen Size: 2560×1440
Best cursor sizes: 16×16→32×32, 32×32→32×32
System property file.encoding: Cp1252
System property sun.jnu.encoding: Cp1252
Locale info: sv_SE
Numbers with default locale: 1234567890 -> 1234567890
VM arguments: [-Djava.security.manager, -Djnlp.application.href=https://josm.openstreetmap.de/download/josm.jnlp, -Djava.util.Arrays.useLegacyMergeSort=true, -Djnlp.tk=awt, -Djnlpx.jvm=<java.home>\bin\javaw.exe, -Djnlpx.splashport=60958, -Djnlpx.home=<java.home>\bin, -Djnlpx.remove=false, -Djnlpx.offline=false, -Djnlpx.relaunch=true, -Djnlpx.session.data=%UserProfile%\AppData\Local\Temp\session555062235586849605, -Djnlpx.heapsize=NULL,NULL, -Djava.security.policy=file:<java.home>\lib\security\javaws.policy, -DtrustProxy=true, -Djnlpx.origFilenameArg=%UserProfile%\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\56\1ee8cfb8-39974266]
Dataset consistency test: No problems found

Plugins:
+ FastDraw (35893)
+ SeaMapEditor (35893)
+ apache-commons (35893)
+ areaselector
+ austriaaddresshelper (1597341117)
+ buildings_tools (35916)
+ continuosDownload (99)
+ editgpx (35893)
+ ejml (35893)
+ geotools (35906)
+ jaxb (35893)
+ jts (35893)
+ log4j (35893)
+ measurement (35893)
+ opendata (35910)
+ reverter (35893)
+ scripting (30798)
+ utilsplugin2 (35893)

Tagging presets:
+ https://raw.githubusercontent.com/yopaseopor/traffic_signs_preset_JOSM/master/SE.zip
+ https://raw.githubusercontent.com/OpenNauticalChart/josm/master/INT-1-preset.xml

Map paint styles:
+ https://raw.githubusercontent.com/OpenSeaMap/josm/master/INT1_Seamark.mapcss

Last errors/warnings:
- 00039.328 W: Plugin areaselector requires Java version 11. The current Java version is 8. You have to update Java in order to use this plugin.

[GerdP]

This is the expected behaviour and I don't think that older versions of JOSM behaved otherwise. The same happens when you add a tag and remove it again. JOSM isn't able to detect that these two changes have no effect.
Only when you use Undo to reverse a change JOSM will restore the "unchanged" status.

[stoecker]

If you want to prevent that, you can call "Update modified" from the first menu. That downloads all modified elements from the server and checks them against current state. When the state didn't change the modified flag is removed. When the server is newer a conflict is created (i.e. that's a pre-upload method for checks).

JOSM doesn't track changes which undo previous changes. It's simply not worth the effort.

If you want you can ask API maintainers that they simply ignore such changes, but apparently they didn't consider this important as well.