[OSM-dev] osm2pgsql questions

Frank Broniewski brfr at metrico.lu
Wed Sep 30 10:27:32 BST 2009


Hello list,

I am a new osm2pgsql user and I want to set up a WMS server with osm data. So 
I loaded the planet.osm into my Postgis database and am applying the daily 
diffs since the creation date of the planet.osm.

Applying a daily diff takes several hours to complete (5~7) and one of my 
questions is if this is in the "standard" processing time or still ok. My 
server is an ubuntu 8.04 amd64 machine with 6GB RAM and two harddrives, one 
serves the diff files and the database is on the other. Processor is an AMD64 
5600+ Dualcore.

I ask this question mainly because I found some oddities when examining the 
diff process by osm2pgsql. Postgresql and Postgis are tuned according to the 
oms wiki and Postgresql manual ...
First is a number of postgresql processes which are idle in transaction, this 
usually means that there has been a transaction started with BEGIN but not 
commited. Right now I have 5 processes of this kind and nobody else except 
osm2pgsql is using the database right now. Maybe it is a flaw/problem in 
osm2pgsql?

At the start of the diff process I get errors in my postgresql log naming that 
some _tmp tables do not exist and cannot be dropped:

2009-09-30 08:44:16 CEST ERROR:  table "planet_osm_point_tmp" does not exist
2009-09-30 08:44:16 CEST STATEMENT:  DROP TABLE planet_osm_point_tmp;
2009-09-30 08:44:16 CEST ERROR:  table "planet_osm_line_tmp" does not exist
2009-09-30 08:44:16 CEST STATEMENT:  DROP TABLE planet_osm_line_tmp;
2009-09-30 08:44:16 CEST ERROR:  table "planet_osm_polygon_tmp" does not exist
2009-09-30 08:44:16 CEST STATEMENT:  DROP TABLE planet_osm_polygon_tmp;
2009-09-30 08:44:16 CEST ERROR:  table "planet_osm_roads_tmp" does not exist
2009-09-30 08:44:16 CEST STATEMENT:  DROP TABLE planet_osm_roads_tmp;

I suppose this is probably a leftover of an older version of osm2pgsql and it 
can be ignored but I am not so sure ...

osm2pgsql puts out some messages during import and I wonder what
storage efficiency: 11.34%, hit rate: 29.09%
mean. Maybe someone can shed some light onto this for me

Many thanks

Frank
-- 
Frank Broniewski

Metrico s.àr.l. ( http://www.metrico.lu )
36, rue des Romains 
L-5433 Niederdonven 
Luxembourg

Fon: +352 26 74 94 28 
Fax: +352 26 74 94 99




More information about the dev mailing list