[OSM-dev] Grumble, grumble

Maarten Deen mdeen at xs4all.nl
Mon May 11 06:56:43 BST 2009

Frederik Ramm wrote:
> Hi,
> Ed Loach wrote:
>> I think, and I can't be certain, that I've lost a whole evening's
>> editing, just because one way I deleted in JOSM had already been
>> deleted by other means before I came to upload. Surely that shouldn't
>> be a problem that loses all the other changes which were unrelated?
> JOSM uses diff uploads, where either the whole upload works or the whole
> upload fails.
> What *should* happen in a case like yours:
> 1. you hit upload
> 2. upload fails, JOSM complains
> 3. if you try to exit JOSM, it should warn about unsaved changes
> 4. you must now do a download and resolve any conflicts
> 5. you hit upload again
> 6. it works
> Unfortunately, step "4" will not send you deleted objects, so JOSM has
> no way of knowing that the object has already been deleted. It could,

Yes it does. When you delete a node or way, you get a return with
"visible=false". JOSM can then take action and inform the user that it is
deleted and take action (either upload it as a new node or delete it in the
local dataset).

> however, better evaluate the return value of step "2" to at least find
> out that a certain way is giving trouble and maybe offer to leave that
> out of the upload or so.
> Currently the only way to deal with this situation is to save the file
> in JOSM and then manually remove the "action=delete" attribute from the
> way in question, before opening the file again and uploading it. There

That's not really an option if you don't know what the offending node/way is
and you've been editting for half an hour (meaning: lots of changes).

> is also a config option osm-server.atomic-upload=false that you can set
> to make JOSM upload each object individually, which in your case would
> have meant that some changes would at least have been stored.

Does it upload everyting except the deleted way, or does it upload its list of
changes and stops with an error when it gets to the deleted way and does not
get past that?
I suppose doing it that way makes a changeset for every node?

> I know this is very unsatisfactory and a fix is being worked on, but not
> ready yet.

Good to hear that. I've had this happen to me too, and boy, can one get pissed
if you have wasted half an hour.

A solution (following my first comment) could be to download all nodes and
ways that are in the local dataset and check which one has been deleted. This
can take some time, but will certainly be faster than having to do that by


More information about the dev mailing list