Re: [OSM-dev] osm2pgsql - coordinates units
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?
Graham.
2010/1/2 Graham Jones
> Hi,
> I have a little Python application that populates a posgresql database
> using osm2pgsql, renders a map with mapnik and extracts information from the
> database to highlight points of interest.
> I am having a bit of trouble with working out what units the coordinates of
> nodes are in in the postgresql database and hope it is obvious to someone:
>
> I am using the -m option, which I think means it will use a spherical
> mercator projection ("+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0
> +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgri...@null +no_defs
> +over"). I am using the same projection in my Python code.
>
> What I find though is that when I use the mapnik.Projection() function to
> translate from lat/lon to spherical mercator y/x, my calculated values are a
> factor of 100 less than those in the postgresql database - If I just divide
> the postgresql database values by 100 and I plot them on my map they end up
> in the correct places.
>
> It looks to me as though osm2pgsql must be storing the x/y values as
> integers in units of centimetres, but I thought that it was supposed to be
> in units of metres.
>
> Is this the case, or have I got something wrong with my projections (If the
> answer is not obvious I will go and work out the maths myself to see what
> order of magnitude the xy values should be - I am not used to working in
> these coordinates).
>
> Thanks,
>
>
> Graham.
>
> --
> Dr. Graham Jones
> Hartlepool, UK
> email: grahamjones...@gmail.com
>
--
Dr. Graham Jones
Hartlepool, UK
email: grahamjones...@gmail.com
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql - coordinates units
2010/1/2 Graham Jones : > 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 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql - coordinates units
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 > 2010/1/2 Graham Jones : > > 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: grahamjones...@gmail.com ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
