[josm-dev] Problem with large changeset

[Alan Mintz]

At 2010-07-05 17:34, Alan Mintz wrote:
>...
>One of the nodes involved is id 54530540. When I bring up the conflict 
>resolution dialog for this node, it says
>
>33.8099363, -117.4006172 My version coordinates
>33.8099363, -117.4006170 Their version coordinates
>
>http://www.openstreetmap.org/browse/node/54530540 says the longitude is 
>...6172
>
>The OSM file says -117.40061723423347 (which rounds to ...6172)
>The XML is   <node id='54530540' action='modify' 
>timestamp='2009-12-31T22:49:06Z' uid='147510' user='woodpeck_fixbot' 
>visible='true' version='2' changeset='3504242' lat='33.80993633282254' 
>lon='-117.40061723423347' />
>
>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.
>
>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.

This rounding appears to occur in JOSM at some point. Retrieving the XML 
for the node from the api with 
http://www.openstreetmap.org/api/0.6/node/54530540 , I get -117.4006172 (7 
decimal places). When you retrieve the area with JOSM and then write to a 
local file, the longitude in the file is -117.400617 (6 decimal places).

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