[OSM-dev] Grumble, grumble
Frederik Ramm
frederik at remote.org
Mon May 11 08:02:38 BST 2009
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
More information about the dev
mailing list