Modify

Opened 6 years ago

Last modified 5 years 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 5 years ago.

Download all attachments as: .zip

Change History (23)

comment:1 by GerdP, 6 years ago

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 by Don-vip, 6 years ago

Keywords: relation upload added

comment:3 by stoecker, 6 years ago

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 by aceman, 6 years ago

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

in reply to:  4 comment:5 by stoecker, 6 years ago

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.

in reply to:  4 ; comment:6 by bastiK, 6 years ago

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 by bastiK, 6 years ago

Resolution: fixed
Status: newclosed

In 13018/josm:

fixed #15374 - problem deleting multilevel relations

in reply to:  6 comment:8 by bastiK, 6 years ago

Replying to bastiK:

JOSM does so already (see class RelationUploadDependencyGraph).

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

comment:9 by bastiK, 6 years ago

Milestone: 17.10

comment:10 by bastiK, 6 years ago

In 13020/josm:

see #15374 - update unit test

comment:11 by bastiK, 6 years ago

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 by GerdP, 6 years ago

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 by aceman, 6 years ago

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 by bastiK, 6 years ago

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

comment:15 by aceman, 6 years ago

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 by bastiK, 6 years ago

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 by Zverikk, 6 years ago

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 6 years ago by Zverikk (previous) (diff)

comment:18 by aceman, 5 years ago

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

comment:19 by GerdP, 5 years ago

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?

by GerdP, 5 years ago

Attachment: delrel2.osm added

in reply to:  16 comment:20 by GerdP, 5 years ago

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 by GerdP, 5 years ago

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 by GerdP, 5 years ago

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. Next status will be 'closed'.
to The owner will be changed from team to the specified user. Next status will be 'new'.
Next status will be 'needinfo'. The owner will be changed from team to aceman.
as duplicate The resolution will be set to duplicate. Next status will be 'closed'. 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.