[josm-dev] BUG: 412 precondition failed

[Gabriel Ebner]

On Fri, Oct 12, 2007 at 07:45:43PM +0200, Igor Brejc wrote:
> I posted this on the JOSM wiki talk page and also added a TRAC ticket:
> 
> I'm using the latest jar file (v368) . When I try to upload the changes, 
> JOSM uploads updated and modified objects, but when it starts to send 
> info to server about deleted objects I get the following message box: 
> Error while parsing: An error occured: 412 precondition failed. This 
> happens every time I try to upload the info about the deleted objects.
> This was not happening to me in previous (API 0.4) versions of JOSM. 
> Just to be sure, I loaded a much bigger area, so the data I tried to 
> modify was not overlapping the loaded boundaries. Also, the data I'm 
> modifying has been freshly downloaded from the server, so there were no 
> conflicts with other users.
> If, after this error occurs, I save the data to file, then restart the 
> JOSM, load that file back into JOSM and try to upload the changes, the 
> same changeset is being uploaded to the server and the same error 
> occurs. I can send the example of the file.

The server returns 412 Precondition Failed when you want to delete something
that is still referenced, or create something that references something
deleted, etc.

Now say there are two nodes in the db:

  <node id="1" lat="..." lon="..." visible="1"/>
  <node id="2" lat="..." lon="..." visible="1"/>

And you create a way connecting these nodes:

  <way id="1" visible="1">
    <nd ref="1"/>
    <nd ref="2"/>
  </way>

But meanwhile someone runs the validator on that area, gets warnings about
unconnected & untagged nodes, and decides to delete these nodes:

  <node id="1" visible="0"/>
  <node id="2" visible="0"/>

If you upload your way then, the server will see that your new way points to
deleted nodes and sends a 412 Precondition Failed back.

Redownloading that area won't help as the server doesn't send deleted objects
back, and so JOSM is unable to figure out that these nodes would need to be
recreated.  (This is not a problem specific to 0.5, it happened to me in the
days of 0.4.)

  Gabriel.