Precondition failed: Node is still used by way

[Ldp]

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.

[stoecker]

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.

[Ldp]

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.

[Ldp]

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?

[Gubaer]

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

[Gubaer]

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.

[anonymous]

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.

[Ldp]

That was me in the previous comment.

[Ldp]

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.

[Ldp]

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.

[mjulius]

I believe this was fixed with r2933