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?