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.
_______________________________________________
josm-dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/josm-dev
