Opened 15 years ago

Closed 14 years ago

#3761 closed enhancement (fixed)

Precondition failed: Node is still used by way

Reported by: Ldp Owned by: team
Priority: normal Milestone:
Component: Core Version: latest
Keywords: Cc:


When you delete a way outside your downloaded area, it can happen that a node in that way is still in use:

Uploading to the server failed because your current
dataset violates a precondition.
The error message is:
ResponseCode=412, Error Header=<Precondition failed: Node {node_id} is still used by way {way_id}.>

Resolving this is harder than it might be. First off: you can not select the node id for copy/paste purposes, so you have to copy it by hand. Then, since the node is set to action='delete' in the dataset, searching for id:nnn gives no results.

The way I currently solve it is by saving to .osm, editing that to remove the action='delete' for that node, reloading in JOSM, and then trying the upload again. Repeat if more conflicts arise. (And yes, I know what I'm doing. These are boundaries ways which someone joined to regular ways)

A semi-automated way to resolve this would be to ask the user "Undelete node and try upload again? {Yes/No}". Being able to copy/paste the number, and being able to find where a deleted object used to be on the map through the Search function would also help if one wants to manually resolve this.

Attachments (0)

Change History (10)

comment:1 by stoecker, 15 years ago

Why do you delete nodes outside of downloaded area? Download a larger area and you wont have conflicts. We wont support such dangerous behaviour.

The proper solution to solve that conflict is to download a a larger area as well and fix the resulting conflict.

comment:2 by Ldp, 15 years ago

I would gladly download a larger area, if it were anywhere close to easy. I'm currently working with administrative boundaries, which can be tens of kilometers long and pretty windy, and people sometimes connect that to a regular road. Downloading a large bbox is not feasible, both from an API standpoint (large requests, slow) and from a JOSM standpoint (huge dataset in memory, very slow to work with). Downloading dozens of smaller areas along the way is also very tedious, so much so that I avoid doing that.

Which is why I brought up the second point in the ticket: if JOSM can give me a clue where the deleted node actually *was* on the map, I can download that particular area and resolve it.

comment:3 by Ldp, 15 years ago

Actually, thinking about this some more, and I notice a bit of counter-intuitive thinking on your part. Let's go back to the basics and ask actually why it is dangerous to delete a way which goes outside your downloaded area? Right, it's because we can get this exact 412 Precondition failed back from the API.

So what is one then supposed to do: download from the API so the whole way is in the downloaded area, and then still delete the way. That leaves the node which is still in use in another way on the map, and we can upload without conflicts.

In which way does that differ from JOSM 'undeleting' said node upon getting the 412 Precondition failed?

comment:4 by Gubaer, 15 years ago

(In [2303]) see #3761: Precondition failed: Node is still used by way
Also added help for this use case, see help

comment:5 by Gubaer, 15 years ago

Resolution: fixed
Status: newclosed

This error from the OSM server now triggers a special error handling routine in JOSM.

  • the error message for the user is improved
  • now it is possible to automatically download all remaining parent ways of the deleted node. Usually, JOSM will automatically remove the deleted node from the downloaded parent ways which is consistent with the current merge rules in JOSM.

comment:6 by anonymous, 15 years ago

Excellent, and I'll check this out. Explicit handling in an editor is so much better than a generic popup that you have to handle in inventive ways.

Still would like to make a case for the other option: leave the deleted node (remove the delete action) from all parent ways except the way I removed explicitly.

comment:7 by Ldp, 15 years ago

That was me in the previous comment.

comment:8 by Ldp, 15 years ago

Resolution: fixed
Status: closedreopened

Alright, I hit this case during actual editing, in real data, and I think JOSM's automatic conflict resolution is wrong.

1) Imported a section of an administrative boundary as gpx, and converted to a way.
2) Loaded 2 small areas from API at the end points of that imported way, and connected the way to neighbouring boundary ways.
3) Deleted the earlier administrative boundary (way 27964021) that was superseded by my new data.
4) Uploaded data.
5) 'Node 310280780 still in use in way 28252476' and I selected the button to prepare conflict resolution.
6) JOSM now automatically removed node 310280780 from way 28252476, in the process 'cutting a corner' out of the way. Way 28252476 is now no longer where it used to be at that spot.

The right thing to do is to keep the other parent ways of the deleted node intact, by actually NOT deleting the node and mangling other parent ways. Same as I've been doing manually by removing action='delete' from the nodes involved.

comment:9 by Ldp, 15 years ago

And same as what happens when you actually do download from API along the way you want to delete. In that case, the node is not deleted either.

comment:10 by mjulius, 14 years ago

Resolution: fixed
Status: reopenedclosed

I believe this was fixed with r2933

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.