You might also consider importing with osm2pqsql with the -l flag (use lat/lon) that way your database will be in a EPSG:4326 official projection (which 900913 is not) and you will have an easier life if you want to convert between projections.
I am also a *fan* of using wgs84 in my postgis database when it comes to OSM data under the simple rule of fist that it is in my opinion best to keep data in the projection it was created with and for GPS this is always wgs84. For my national dutch data derived from official government bodies; my rule is "store it in EPSG:28992 (the official dutch projection) because that is the coordinate-system they survey in. Andy Allan wrote: > On Tue, Mar 16, 2010 at 7:19 AM, Torsten Mohr <[email protected]> wrote: > >> Hello, >> >> thanks a lot for your hint. >> >> >>> http://postgis.refractions.net/documentation/manual-svn/ST_X.html >>> http://postgis.refractions.net/documentation/manual-svn/ST_Y.html >>> >>> select st_X(st_transform(way,4326)), st_Y(st_transform(way,4326)) from >>> planet_osm_point where ... >>> >> I tried it like this: >> >> select st_X(st_transform(way,4326)), st_Y(st_transform(way,4326)) from >> planet_osm_point where name='Berlin' and place='city'; >> >> But this lead to this error: >> > > Try transforming via 3395, which always works for me. For reasons I've > never bothered investigating a direct transform from 900913->4326 > doesn't work, but 900913->3395->4326 does. > > e.g. st_X(st_transform(st_transform(way, 3395), 4326)) > > Cheers, > Andy > > _______________________________________________ > talk mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/talk > > _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
