conflict resolution broken for deleted objects via reverter plugin

[mkoniecz]

What steps will reproduce the problem?

1. Spot copyright violation added in changesets ​https://www.openstreetmap.org/changeset/72260628 and ​https://www.openstreetmap.org/changeset/72260619
2. Use reverter plugin to revert one of changesets
3. Run into 9k+ conflicts (as someone edited what was added in undiscussed import to remove invalid tags) - note that conflicts are between my version (deleted) and their version (edited, not deleted)
4. Select all conflicts with ctrl+a, right click, select "resolve to my versions"
5. wait for conflicts to resolve (around one minute)
6. Try to upload changes

What is the expected result?

I will delete thousands of objects.

What happens instead?

Upload button is grayed out, in slightly older version I was able to press but I was getting message that there are no changes for upload.

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

Import was discussed in ​https://www.openstreetmap.org/changeset/72260608 and with DWG that confirmed that reverting it is OK.

First revert is in ​https://www.openstreetmap.org/changeset/75351558

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2019-10-08 00:03:30 +0200 (Tue, 08 Oct 2019)
Build-Date:2019-10-08 01:30:52
Revision:15443
Relative:URL: ^/trunk

Identification: JOSM/1.5 (15443 en) Linux Ubuntu 16.04.6 LTS
Memory Usage: 439 MB / 869 MB (173 MB allocated, but free)
Java version: 1.8.0_201-b09, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: :0.0 1920x1080
Maximum Screen Size: 1920x1080
libcommons-logging-java: libcommons-logging-java:all-1.2-1+build1
fonts-noto: fonts-noto:-

Plugins:
+ OpeningHoursEditor (34977)
+ PicLayer (35104)
+ apache-commons (35092)
+ buildings_tools (35171)
+ continuosDownload (82)
+ ejml (35122)
+ geotools (35169)
+ imagery_offset_db (34908)
+ jts (35122)
+ log4j (34908)
+ measurement (35051)
+ reverter (35084)
+ todo (30306)

Validator rules:
+ ${HOME}/Documents/install_moje/OSM software/josm/data/validator/deprecated.mapcss
+ ${HOME}/Documents/install_moje/OSM software/josm/data/validator/unnecessary.mapcss
+ ${HOME}/Documents/install_moje/OSM software/josm/data/validator/combinations.mapcss

Last errors/warnings:
- W: No configuration settings found.  Using hardcoded default values for all pools.
- W: Failed to add ${HOME}/Documents/install_moje/OSM software/josm/data/validator/deprecated.mapcss to tag checker
- W: java.nio.file.NoSuchFileException: ${HOME}/Documents/install_moje/OSM software/josm/data/validator/deprecated.mapcss
- W: Failed to add ${HOME}/Documents/install_moje/OSM software/josm/data/validator/unnecessary.mapcss to tag checker
- W: java.nio.file.NoSuchFileException: ${HOME}/Documents/install_moje/OSM software/josm/data/validator/unnecessary.mapcss
- W: Failed to add ${HOME}/Documents/install_moje/OSM software/josm/data/validator/combinations.mapcss to tag checker
- W: java.nio.file.NoSuchFileException: ${HOME}/Documents/install_moje/OSM software/josm/data/validator/combinations.mapcss

[Don-vip]

immediate workaround: save osm file and reload it.

[mkoniecz]

"immediate workaround: save osm file and reload it." - it is necessary to do this before resolving conflicts

it gives me dialog forcing to select "reject conflicts and save" (not sure about effect, but invalid import seems to be gone as expected)

Saving after conflicts are resolved is not working (nothing to save).

[Don-vip]

no, after resolving. Just force the dialog, and you will find your changes in the .osm file. After reloading the file you can upload them.

[mkoniecz]

Turns out to work in both cases.

BTW, thanks for extremely quick help!

[Don-vip]

State of objects after conflict resolution:

Node: 6616317015
  State: deleted
  Data Set: dc2ffdd
  Edited at: 2019-10-07T10:43:12Z
  Edited by: rayleigh1 (6739817)
  Version: 2
  In changeset: 75369103
  Tags: 
    "Dzielnica"="BIELANY"
    "emergency"="fire_hydrant"
    "couplings:diameters"="75"
    "fire_hydrant:diameter"="80"
    "fire_hydrant:type"="underground"
    "fire_hydrant:coupling_type"="Storz"
  Coordinates: 52.2913919, 20.947742
  Coordinates (projected): 2331891.97270887, 6852985.307182958
  UTM Zone: 34N

No "modified" flag, so it is not considered as required to be uploaded.

After reload of the file:

Node: 6616317015
  State: deleted  modified
  Data Set: 24d5953b
  Edited at: 2019-10-07T10:43:12Z
  Edited by: rayleigh1 (6739817)
  Version: 2
  In changeset: 75369103
  Tags: 
    "Dzielnica"="BIELANY"
    "emergency"="fire_hydrant"
    "couplings:diameters"="75"
    "fire_hydrant:diameter"="80"
    "fire_hydrant:type"="underground"
    "fire_hydrant:coupling_type"="Storz"
  Coordinates: 52.2913919, 20.947742
  Coordinates (projected): 2331891.97270887, 6852985.307182958
  UTM Zone: 34N

the modified flag is here, allowing objects to be uploaded.

[Don-vip]

Hey did you delete the nodes? Please wait a few hours until I fix the bug.

[Don-vip]

Behaviour directly caused by r2624 which solved the inverse problem (#4088 / #4155)

[mkoniecz]

Hey did you delete the nodes?

Yes.

Please wait a few hours until I fix the bug.

Oops. Sorry. Is it "I wanted to test my fix" problem or "edit currently made may damage data" problem?

​https://www.openstreetmap.org/changeset/57269387 is the next invalid node import on my TODO list for elimination and it will also trigger conflict. This revert has no DWG blessing (I have not contacted them) but was discussed extensively and nothing appeared that would make keeping this data acceptable.

[Don-vip]

It is "I have a really good way to reproduce the bug that helps me to fix this bug faster". Can you please just keep a few nodes out of the revert? I don't need 9000 of them, but 15 would be really helpful.

[Don-vip]

In 15444/josm:

fix #18212, see #4088, see #4155 - don't override modified flag of deleted primitives after resolving a conflict

[mkoniecz]

​http://overpass-turbo.eu/s/MXk are remains that for some reason avoided deletion.

So far ones that I checked were part of way.

From what I remember I instructed conflict resolver after getting "part of way" during upload to keep them but delete tags. Possibly as an another effect of this bug tags were kept with tags unmodified.

[Don-vip]

Thanks. I just have released r15445 as new latest version. It contains fix for this problem. Can you please check it works for the last remaining nodes? I shouldn't need them anymore.

[mkoniecz]

Yes, it works great! Thanks for a quick fix!