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