[josm-dev] Problem with large changeset

[Sebastian Klein]

Alan Mintz wrote:
> If I bring up the history dialog for this node, it says that v2 was 
> edited in changeset 3504242, agreeing with the OSM file, but that it's 
> coordinates were 33.80988, -117.40063. It says that v3 was edited in 
> changeset 5131096 (the one in question) and the coordinates are 
> 33.809994 -117.40062 (which is the rounded version of those above). This 
> dialog should really show more decimal places.

Probably this is what happened: You downloaded v2 of the node, then 
changed its position/tags. Then it was uploaded successfully, but the 
final server response got lost somehow. This final answer includes the 
new version, timestamp, uid, ... of the changed objects. If you abort 
the upload process (or load the saved file from before the upload), JOSM 
does not know, it is already on the server and sticks to the old info. 
(If you abort upload before the last byte was sent, the sever will roll 
back the entire change, obviously the last byte had already been send in 
your case.)

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. (But 
you said something about way conflicts, have you analysed these as well?)

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.


Sebastian

> 
> So, it seems that in this case, my local OSM file has the correct 
> coordinates of the node for v3, but the wrong timestamp, uid, user, 
> version, and changeset. It seems that, when retrieving the node for 
> conflict resolution, the longitude (but not latitude) is getting rounded 
> to 6 decimal places (instead of 7), which then fails the comparison with 
> the local value. I don't know if this is the sole cause of its 
> appearance in the conflict list, or if this is because the local version 
> number was not updated with the new one after the upload.
> 
> If I retrieve all of these nodes and then compare the coordinates with 
> my local file, I should be able to confirm that they were correctly 
> uploaded. I'll look at the ways after that.