Modify

Opened 17 months ago

Last modified 6 weeks ago

#15374 reopened defect

problem deleting multilevel relations

Reported by: aceman Owned by: team
Priority: normal Milestone: 17.10
Component: Core Version: latest
Keywords: relation upload Cc:

Description

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.

Attachments (1)

delrel2.osm (20.7 KB) - added by GerdP 2 months ago.

Download all attachments as: .zip

Change History (23)

comment:1 Changed 17 months ago by 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.

comment:2 Changed 17 months ago by Don-vip

Keywords: relation upload added

comment:3 Changed 17 months ago by 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.

comment:4 Changed 17 months ago by 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.

comment:5 in reply to:  4 Changed 17 months ago by 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.

comment:6 in reply to:  4 ; Changed 17 months ago by 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.

comment:7 Changed 16 months ago by bastiK

Resolution: fixed
Status: newclosed

In 13018/josm:

fixed #15374 - problem deleting multilevel relations

comment:8 in reply to:  6 Changed 16 months ago by bastiK

Replying to bastiK:

JOSM does so already (see class RelationUploadDependencyGraph).

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

comment:9 Changed 16 months ago by bastiK

Milestone: 17.10

comment:10 Changed 16 months ago by bastiK

In 13020/josm:

see #15374 - update unit test

comment:11 Changed 16 months ago by 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.

comment:12 Changed 16 months ago by 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.

comment:13 Changed 16 months ago by 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?

comment:14 Changed 15 months ago by bastiK

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

comment:15 Changed 15 months ago by aceman

Resolution: fixed
Status: closedreopened

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.

comment:16 Changed 15 months ago by 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.

comment:17 Changed 15 months ago by 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?

Last edited 15 months ago by Zverikk (previous) (diff)

comment:18 Changed 3 months ago by aceman

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

comment:19 Changed 2 months ago by 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?

Changed 2 months ago by GerdP

Attachment: delrel2.osm added

comment:20 in reply to:  16 Changed 2 months ago by 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.

comment:21 Changed 2 months ago by 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.

comment:22 Changed 6 weeks ago by 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?

Modify Ticket

Change Properties
Set your email in Preferences
Action
as reopened The owner will remain team.
as The resolution will be set.
to The owner will be changed from team to the specified user.
The owner will change to aceman
as duplicate The resolution will be set to duplicate.The specified ticket will be cross-referenced with this ticket

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.