[OSM-dev] Grumble, grumble

[Frederik Ramm]

Hi,

Maarten Deen wrote:
>> 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". 

No it doesn't; if you do a "map" query against the API, you will *not* 
receive deleted objects, and that's what JOSM does in step 4. It would 
not be feasible to query each object individually.

> 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 one thing that JOSM could do is compare the list of objects in 
memory with those returned by the "map" query and thus find out which 
ones are "missing" from the map query, then request those individually 
to confirm they are really "410 Gone".

>> 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?

The latter (it is exactly the way as used in 0.5). But it does not 
upload the changes in the order you made them, instead it first uploads 
all creations, then all modifications, then all deletions.

> I suppose doing it that way makes a changeset for every node?

No, it creates a changeset, uploads stuff, then closes it afterwards. 
Changesets do not have to be atomic.

Bye
Frederik