problem deleting multilevel relations

[aceman]

I had some problems uploading a changeset deleting multiple relations that were ordered in a tree.

I wanted to delete relation 1832956, that had relation 1832955 as a member which I wanted to delete too. 1832956 itself was a member of another relation, that was NOT to be deleted.

I deleted both 1832955 and 1832956 (the parent was loaded too) in one changeset and wanted to upload. I got the error:
SEVERE: org.openstreetmap.josm.io.OsmApiException: ResponseCode=412, Error Header=<Precondition failed: The relation 1832955 is used in relation 1832956.>
org.openstreetmap.josm.io.OsmApiException: ResponseCode=412, Error Header=<Precondition failed: The relation 1832955 is used in relation 1832956.>

The solution I came to was just delete 1832955, upload it, then delete 1832956 and upload again.

[GerdP]

Got a similar problem a few days ago. Someone created a multipolygon-rel containing a single node and another mp-rel containing only this rel. This happened a few times in a small area. I removed both rels and fixed a lot of other problems like unconnected roads and later got similar problems. I had to remove quite a lot of rels and update before OSM accepted the larger changeset.

[stoecker]

That issue should be reported to the OsmApi instead of JOSM. It's clearly an API error to reject a changeset which leaves a consistent state.

[aceman]

Or JOSM could reorder the deletion commands to the order the API would accept. I remember there was such an error in the past.

[stoecker]

Replying to aceman:

Or JOSM could reorder the deletion commands to the order the API would accept. I remember there was such an error in the past.

That's a workaround instead of a bugfix.

[bastiK]

Replying to aceman:

Or JOSM could reorder the deletion commands to the order the API would accept. I remember there was such an error in the past.

JOSM does so already (see class RelationUploadDependencyGraph). If it does so incorrectly, then this is a regression and must be fixed. If not, this is quite clearly an problem of the OSM API and probably a regression as well.

[bastiK]

In 13018/josm:

fixed #15374 - problem deleting multilevel relations

[bastiK]

Replying to bastiK:

JOSM does so already (see class RelationUploadDependencyGraph).

It did sort the deleted relations, but exactly the wrong way around.

[bastiK]

In 13020/josm:

see #15374 - update unit test

[bastiK]

This ticket is a duplicate of #9624, which was closed by [6776]. As can be seen from the unit test, it was never actually fixed. Just odd that the problem was not reported in the 4 years since then.

[GerdP]

Yes, sounds strange. Maybe the reason is that you typically don't have the situation that one wants to delete both the parent and child relation. In my case I assume that an unexperienced mapper pressed Ctrl+B (Create Mulitpolygon) multiple times.

[aceman]

I now again have a case of multiple relations to be deleted in real OSM data. Would you guys like to try the fix on it, or should I do it using latest JOSM?

[bastiK]

Please go ahead and let us know in case there are problems!

[aceman]

Unfortunately it still doesn't work.
Try to remove relations 7201335 (bus line ref=97), 7201336, 7201337 (their parent).
When uploading, I get server message that 7201335 is still referenced from 7201337. So it seems JOSM still tries to delete 7201335 before 7201337. Also notice 7201337 is a member of 3305365 from which it needs to be removed too.

Trying with JOSM 13115.

[bastiK]

Confirmed. It appears, the information about former members is currently cleared when a relation is deleted. This makes it impossible to trace the dependencies on upload.

[Zverikk]

The issue hasn't been solved, as it seems. A few hours ago another mapper from russia telegram said he's got conflicts after deleting two nested relations.

Is it hard to not delete member list until the changes are uploaded?

[aceman]

Yes, it still happens, deleting e.g. relations 6626784 and 6626785.

[GerdP]

My understanding is this:
We have relation 6626784 which has one node member node 4430295358.
We have relation 6626785 that has relation 6626784 as member.
All three objects should be deleted in one changeset.
What I see with r14564 is this order:
6626784 , 6626785 4430295358

I think the order of objects should be
6626785 , 6626784 , 4430295358
Is that right?

[GerdP]

Replying to bastiK:

Confirmed. It appears, the information about former members is currently cleared when a relation is deleted. This makes it impossible to trace the dependencies on upload.

Yes, we have to make sure that this information is stored somewhere so that we can sort the data.

[GerdP]

I see three different ways to handle this:

• Change the code so that we do not delete the members of a relation when the relation is deleted. This should allow us find the links between different relations.
• Try to upload and - in case of an "HTTP status code 412 (Precondition Failed)" analyse the information returned with it to get the order. This might require multiple trials in case of cyclic dependencies, so this looks like the wrong way.
• Use DownloadReferrersAction to get the parent relations of all relations which should be deleted BEFORE we upload and use the info for sorting in APIDataSet.RelationUploadDependencyGraph.computeUploadOrder()

At the moment, the DownloadReferrersAction option looks like the easiest solution for me, so I think I'll try to implement that during the next days.

[GerdP]

I changed my mind here. It seems easier to implement code that handles "HTTP status code 412 (Precondition Failed)". This should be used to add dependencies to the APIDataSet.RelationUploadDependencyGraph. I tried to code that but still got lost in complexity :(
Another alternative would be to add a modify statement for all relations that are to be deleted. The modify statement would remove all members so that the final remove doesn't cause trouble. If we would do this only when multiple relations are to be deleted the extra version should not do much harm, and it would be needed anyway in case of cyclic dependencies (like a member of b and b member of a). What do you think?