[josm-dev] Problem with large changeset

[Alan Mintz]

At 2010-07-06 01:16, Sebastian Klein wrote:
...
>The update of the data using the server response from the upload is 
>relatively straight forward. However if that answer got lost, best you can 
>do is download that area again to another file and compare. (As I said it 
>is all or nothing!) Another option is 'update' which does a semantic 
>comparison and tries to match your objects with the ones on the server. If 
>the object from update is not semantically equal to your local copy of the 
>object and that object has a lower version number *and* is modified, it 
>produces a conflict. It seems there is a problem with rounding/precision 
>somewhere so it produced a bogus conflict.

Exactly, AFAICT. It seems that the changeset was closed about an hour after 
opening, but JOSM never got the response with the new version numbers, IDs 
for new objects, etc. I've confirmed that the nodes are identical if I deal 
with the rounding issue, although there is more strangeness with rounding 
when the last two digits at decimal places are 45-54, but I think I 
understand why this is. These types of issues will always come up with 
floating-point values unless they are always passed in their entirety in 
native form, and all platforms and APIs use the same precision (which I why 
I almost always use exact scaled integers instead :) ). It may be possible 
to fix by making the API produce 7 decimal places, though there may still 
be the 45-54 problem if the internal precision is higher - I can't tell.


>  (But you said something about way conflicts, have you analysed these as 
> well?)

Not quite yet. The few I looked at were because the ways contained new 
nodes (with negative IDs) that had not been updated with the newly-assigned 
positive IDs. I'm hoping they are all this way.


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

--
Alan Mintz <Alan_Mintz+OSM at Earthlink.net>