[josm-dev] Problem with large changeset
Alan Mintz
Alan_Mintz+OSM at Earthlink.Net
Tue Jul 6 21:15:45 BST 2010
At 2010-07-06 04:14, Sebastian Klein wrote:
>Alan Mintz wrote:
>>At 2010-07-06 01:16, Sebastian Klein wrote:
>>>All this is only true if you upload in a single request. In chunked
>>>mode, this applies for each chunk separately.
>>> If you have a problem in a later chunk, it is usually a good idea to
>>> save the file anyway because JOSM has already processed the server
>>> responses from the successful chunks and remembers what has been
>>> uploaded so far.
>>I hadn't noticed that ability. The last time I looked, my only choice was
>>individual or all, and individual took way too long. I'll definitely to
>>do this for large changesets in the future. Perhaps JOSM should suggest
>>this by default when you try to upload more than x objects.
>
>It is not recommended for newby users: For referential integrity, JOSM
>first uploads all nodes, then all ways and finally all relations. If you
>encounter conflict in the second chunk and completely abort the editing
>session for some reason, then you leave quite a mess behind (useless cloud
>of nodes).
I had assumed the changeset was a single database transaction, and that
aborting one of the chunks would abort the whole thing. If not, I can see
that this presents its own set of issues.
>Now that I think about it, the upload order should be optimized:
> * first "singleton" nodes (POIs)
> * then for each way: all way nodes and then the way itself
> * then relations
>
>Another workaround if you expect conflicts:
>
>Filter for "modified" (inverted), then select small parts and do "upload
>selection". (Deleting objects might require a final "normal" upload.)
Nice. I didn't notice the "Upload selection". That could definitely be useful.
--
Alan Mintz <Alan_Mintz+OSM at Earthlink.net>
More information about the josm-dev
mailing list