[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