[OSM-dev] osm2pgsql - coordinates units

[Graham Jones]

Thanks Jon,
I thought it might be an efficiency thing, but wasn't sure when we are using
the postgis extensions anyway.  I didn't get that far through the osm2pgsql
source code to spot it!

Regards

Graham.

2010/1/2 Jon Burgess <jburgess777 at googlemail.com>

> 2010/1/2 Graham Jones <grahamjones139 at googlemail.com>:
> > I think I have found the problem - I was using planet_osm_nodes lat and
> lon
> > fields.  If I use the planet_osm_point way field, and extract the
> > coordinates using ST_X() and ST_Y() all of the numbers match up.
> >
> > You can see the factor of 100 difference if you do:
> >       select id,lat,lon,astext(way) from planet_osm_nodes,
> planet_osm_point
> > where id=osm_id and id=27496146;
> >
> > This gives:
> >    mapnik=# select id,lon,lat,astext(way) from planet_osm_nodes,
> > planet_osm_point where id=osm_id and id=27496146;
> >        id    |    lon    |    lat    |
> > astext
> >
> >
> ----------+-----------+-----------+-------------------------------------------
> >     27496146 | -13446488 | 730126793 | POINT(-134464.883471724
> > 7301267.93936479)
> >    (1 row)
> >
> >    mapnik=#
> >
> > Is this a bug in osm2pgsql, or a 'feature'?   Does anything use the
> lat/lon
> > fields?
>
> The factor of 100 is a feature and is setup at [1]. It allows
> osm2pgsql to store the position as a fixed point 32 it integer taking
> just 4 bytes, instead of the 8 bytes required for a double precision
> floating point value.
>
> osm2pgsql uses the lat/lon fields when looking up the node locations.
>
>
> 1:
> http://trac.openstreetmap.org/browser/applications/utils/export/osm2pgsql/middle-pgsql.c#L27
>
> --
>     Jon
>



-- 
Dr. Graham Jones
Hartlepool, UK
email: grahamjones139 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20100102/7e8ea690/attachment.html>