Opened 7 months ago
Last modified 5 months 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 (0)
Change History (17)
comment:1 Changed 7 months ago by
comment:2 Changed 7 months ago by
Keywords: | relation upload added |
---|
comment:3 Changed 7 months ago by
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 follow-ups: 5 6 Changed 7 months ago by
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 Changed 7 months ago by
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 follow-up: 8 Changed 7 months ago by
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:8 Changed 6 months ago by
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 6 months ago by
Milestone: | → 17.10 |
---|
comment:11 Changed 6 months ago by
comment:12 Changed 6 months ago by
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 6 months ago by
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:15 Changed 6 months ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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 6 months ago by
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 5 months ago by
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?
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.