[OSM-dev] Planet Dump Timings

Brett Henderson brett at bretth.com
Sun Sep 9 12:21:01 BST 2007

Hi All, thanks for the input.  Some comments (and further info) below.

Dave Stubbs wrote:
> On 09/09/07, *Sebastian Spaeth* <Sebastian at sspaeth.de 
> <mailto:Sebastian at sspaeth.de>> wrote:
>     On Sun, Sep 09, 2007 at 01:47:27AM +1000, Brett Henderson wrote:
>     > The rounding differences so far have always been when a 5 is
>     rounded one
>     > way or the other so I don't think this is a concern.
>     Given that the 7th decimal place is something like 1cm (or was it
>     1mm?) at the equator, I am not very concerned that this makes a
>     big difference. It's interesting though, that osmosis doesn't seem
>     to do proper rounding here. Do you use sprintf to output your values? 
> osmosis will probably be using some form of DecimalFormat to output 
> doubles. This uses half-even (unbiased) rounding. sprintf may or may 
> not use this depending on what system you're on. I'm guessing this 
> will represent the discrepancy.
Yes, it is using DecimalFormat.  I've included a couple of examples 
below.  Note that osmosis is rounding up in some cases and down in 
others so the half-even explanation makes sense.  Unless somebody 
screams I'll assume there's no problem here.

Node 107672
51.5110459 latitude is written by planet.rb.
51.5110458 latitude is written by osmosis.
51.51104585 latitude is displayed by MySQL Query Browser.

Node 140869
51.8383903 latitude is written by planet.rb.
51.8383904 latitude is written by osmosis.
51.83839035 latitude is displayed by MySQL Query Browser.

Node 301503
50.8304357 latitude is written by planet.rb.
50.8304358 latitude is written by osmosis.
50.83043575 latitude is written by MySQL Query Browser.
> It looks like the input string is not utf-8 to start with.
> ie: both the planet.rb and osmosis outputs are wrong.
> Is this running from the same system as the normal planet dump?
> I'm just wondering if the mysql connectors are in the wrong charset 
> mode, or else the data was imported badly in the first place.
> The correct output for the first letter should be 0xC3 0xA4 whatever.
These examples are from my local database which contains full production 
data for the node/segment/way tables (minus user information) as of a 
month or so ago.  But between the production dump and the import process 
something may have been broken.  I've just retrieved an area from the 
api containing the node, I'll import the resultant osm file into a new 
db and dump it again.  Hopefully that will resolve the issue.

More information about the dev mailing list