Nodes und Ways sind jetzt fertig. Fehlen nur noch die Relations.
Uptime bisher: 6 days 20 hours
Processing: Node(938392k) Way(79069k) Relation(9240)
Hier nochmal die Daten zum System, falls das später mal wen interessiert.
System: Foxconn Netbox nt-330i
CPU: Atom 330i Dual-Core
OS: Debian 64bit
HDD: 640GB
RAM: 2GB
File: planet-110119.osm.bz2
osm2pgsql: 0.70.5
Das ist ein Trugschluß: Die Nodes rauschen ziemlich schell durch, für die anderen braucht es halt. Da muß er schließlich auch die members speichern.
gruß,
ajoessen
Und nachher kommt osm2pgsql noch mit “processing ways” und “prcoessing relations”. Das kann dann auch noch mal ein paar Tage dauern.
Beim Import mit osm2pgsql gibt es übrigens sher viele Faktoren, die die Dauer bestimmen. So sollte man z.B. Postgres 8.3 nehmen, da diese für unsere Zwecke am schnellsten ist. Besonders wichtig ist die Festplattengeschwindigkeit; gut ist da ein RAID-Verbund oder SSD-Festplatte. Dann gibt es noch in Postgres etliche Einstellungen, wie Buffer, die enormen Einfluß auf die Geschwindigkeit haben können.
Christian
Hi,
ich hab mal mitgeschrieben, was die Produktionskette bei mir an Zeit verschlingt:
== NRW+Rheinland-Pfalz ==
aus germany.pbf ausschneiden:
de-osmpbf-nrwplus.bat
D:\Karten\OpenStreetMap\osmosis\bin\osmosis.bat --read-pbf D:\Karten\osm\Geofabrik\germany.osm.pbf --bb left=5.5 right=9.5 bottom=49.0 top=52.5 completeWays=true --write-xml nrwplus.osm.bz2
Temporäre Dateien werden im Verzeichnis
C:\Dokumente und Einstellungen<Benutzername>\Lokale Einstellungen\Temp
angelegt:
Knoten in afn… 729MB 20min
Wege in afw… 343MB 12min
Relationen in afr… 14MB 1min
Gesamtzeit etwa 3 Stunden, 348MB output
ohne completeWays=true werden keine temporären Dateien angelegt
einlesen mit osm2pgsql:
osm2pgsql --create --database osmdb --username osmuser --prefix planet -s --cache 1024 -S D:\Karten\OpenStreetMap\osm2pgsql\default.style --hstore D:\Karten\osm\osmosis\nrwplus.osm.bz2
17.952k Knoten in 23min
2.704k Wege in 69min
42k Relationen in 73min
981k pending ways in 45min
Index Ways 93min
Index relation 1min
Index point 5 min
Index line 18min
Index polygon 9 min
Index roads 1min
Insgesamt 5,5 Stunden
Rendern mit Mapnik:
minZoom = 8
maxZoom = 15
bbox = (5.8, 49.0,9.5,52.5)
zoom8: 15 Tiles in 11min
zoom9: 54 Tiles in 8min
zoom10: 204 Tiles in 21min
zoom11: 759 Tiles in 30min
zoom12: 2816 Tiles in 72min
zoom13: 10k Tiles in 148min
zoom14: 43k Tiles in 6Std
zoom15: 171k Tiles in 20,5Std
Ist nicht die Welt ;=)
aber trotzdem vielleicht als Vergleich interessant.
gruß,
ajoessen
Bei dir dürfte es “deutlich” schneller gehen, wenn du das packen der geschnittenen osm-Datei lassen würdest.
… dafür gehen dann einige GB an Plattenspeicher drauf. Davon hab ich mittlerweile weniger als Zeit 
Gruß,
ajoessen
Das parsen ist jetzt fertig, dauerte insgesamt 9,3 Tage 
Nun noch das Processing abwarten, dann isses geschafft.
So… Fertig 
osm2pgsql SVN version 0.70.5
Using projection SRS 900913 (Spherical Mercator)
Setting up table: planet_osm_point
NOTICE: table “planet_osm_point” does not exist, skipping
NOTICE: table “planet_osm_point_tmp” does not exist, skipping
Setting up table: planet_osm_line
NOTICE: table “planet_osm_line” does not exist, skipping
NOTICE: table “planet_osm_line_tmp” does not exist, skipping
Setting up table: planet_osm_polygon
NOTICE: table “planet_osm_polygon” does not exist, skipping
NOTICE: table “planet_osm_polygon_tmp” does not exist, skipping
Setting up table: planet_osm_roads
NOTICE: table “planet_osm_roads” does not exist, skipping
NOTICE: table “planet_osm_roads_tmp” does not exist, skipping
Mid: pgsql, scale=100, cache=800MB, maxblocks=102401*8192
Setting up table: planet_osm_nodes
NOTICE: table “planet_osm_nodes” does not exist, skipping
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index “planet_osm_nodes_pkey” for table “planet_osm_nodes”
Setting up table: planet_osm_ways
NOTICE: table “planet_osm_ways” does not exist, skipping
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index “planet_osm_ways_pkey” for table “planet_osm_ways”
Setting up table: planet_osm_rels
NOTICE: table “planet_osm_rels” does not exist, skipping
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index “planet_osm_rels_pkey” for table “planet_osm_rels”
Reading in file: planet-110119.osm.bz2
Unknown node type 8
Processing: Node(938392k) Way(79069k) Relation(84700)
Standard exception processing way_id 110802: TopologyException: side location conflict at -1.24357e+07 3.92347e+06
Standard exception processing way_id 110803: TopologyException: side location conflict at -1.24357e+07 3.92347e+06
Processing: Node(938392k) Way(79069k) Relation(832328) parse time: 803862s
Node stats: total(938392397), max(1109874459)
Way stats: total(79069515), max(95750825)
Relation stats: total(832328), max(1381935)
Going over pending ways
processing way (39822k)
Going over pending relations
node cache: stored: 104814039(11.17%), storage efficiency: 99.96%, hit rate: 10.96%
Committing transaction for planet_osm_polygon
Sorting data and creating indexes for planet_osm_polygon
Committing transaction for planet_osm_roads
Sorting data and creating indexes for planet_osm_roads
Committing transaction for planet_osm_line
Sorting data and creating indexes for planet_osm_line
Committing transaction for planet_osm_point
Sorting data and creating indexes for planet_osm_point
Stopping table: planet_osm_nodes
Stopping table: planet_osm_ways
Stopping table: planet_osm_rels
Building index on table: planet_osm_rels
Stopped table: planet_osm_nodes
Building index on table: planet_osm_ways
Stopped table: planet_osm_rels
Completed planet_osm_point
Completed planet_osm_roads
Completed planet_osm_polygon
Completed planet_osm_line
Stopped table: planet_osm_ways
You have new mail in /var/mail/asa
asa@srv-nt330i:~/osm$ uptime
20:33:33 up 18 days, 17:32, 3 users, load average: 0.48, 0.17, 0.12
asa@srv-nt330i:~/osm$
17 Tage 
Ich hatte kürzlich ein ähnliches Problem. Ich habe den Import einfach auf einer schnellen Maschine gemacht (82 Stunden @ 70 Watt = 5,75 kWh) und dann einfach die fertige Datenbank auf den langsameren Rechner kopiert! 17 Tage (408 Stunden) * 20 Watt = 8,2 kWh … also eigentlich null Ersparnis, wenn Du eh eine schnellere Kiste hast. Das ist wie der Umstieg auf LED-Leuchten, die sich erst nach 3-5 Jahren Betrieb wirklich rentieren.
ich hole den Thread nochmal hoch, da ich selbst gerade betroffen bin. Mittlerweile denke ich, dass es wohl einfacher wäre, wenn es neben pbf und osm auch regelmäßig (vielleicht monatlich), eine Postgres Datenbank zum Download geben würde…Seit 7 Tagen importiert mein Rechner jetzt schon Europa. Kann mir jemand sagen, wie lange das jetzt noch dauert?
postgres@SunCobalt:/home/thomas$ osm2pgsql -l -d osm -p osm -s -C 2500 /home/thomas/europe.osm.bz2
osm2pgsql SVN version 0.69-
Using projection SRS 4326 (Latlong)
Setting up table: osm_point
HINWEIS: Tabelle »osm_point« existiert nicht, wird übersprungen
HINWEIS: Tabelle »osm_point_tmp« existiert nicht, wird übersprungen
Setting up table: osm_line
HINWEIS: Tabelle »osm_line« existiert nicht, wird übersprungen
HINWEIS: Tabelle »osm_line_tmp« existiert nicht, wird übersprungen
Setting up table: osm_polygon
HINWEIS: Tabelle »osm_polygon« existiert nicht, wird übersprungen
HINWEIS: Tabelle »osm_polygon_tmp« existiert nicht, wird übersprungen
Setting up table: osm_roads
HINWEIS: Tabelle »osm_roads« existiert nicht, wird übersprungen
HINWEIS: Tabelle »osm_roads_tmp« existiert nicht, wird übersprungen
Mid: pgsql, scale=10000000, cache=2500MB, maxblocks=320001*8192
Setting up table: osm_nodes
HINWEIS: Tabelle »osm_nodes« existiert nicht, wird übersprungen
HINWEIS: CREATE TABLE / PRIMARY KEY erstellt implizit einen Index »osm_nodes_pkey« für Tabelle »osm_nodes«
Setting up table: osm_ways
HINWEIS: Tabelle »osm_ways« existiert nicht, wird übersprungen
HINWEIS: CREATE TABLE / PRIMARY KEY erstellt implizit einen Index »osm_ways_pkey« für Tabelle »osm_ways«
Setting up table: osm_rels
HINWEIS: Tabelle »osm_rels« existiert nicht, wird übersprungen
HINWEIS: CREATE TABLE / PRIMARY KEY erstellt implizit einen Index »osm_rels_pkey« für Tabelle »osm_rels«
Reading in file: /home/thomas/europe.osm.bz2
Processing: Node(486249k) Way(56274k) Relation(81k)
excepton caught processing way id=153858
Processing: Node(486249k) Way(56274k) Relation(670k)
excepton caught processing way id=1479960
Processing: Node(486249k) Way(56274k) Relation(707k)
Node stats: total(486249342), max(1264097878)
Way stats: total(56274965), max(110775389)
Relation stats: total(707514), max(1562185)
Going over pending ways
processing way (24369k)
-C2500
Du gehörst doch auch zu den OSM Spezialisten … warum versucht du mit so wenig RAM ganz Europa zu impotieren ?
Speicher ist doch nicht mehr teuer … 16 oder mehr GB sollte eigentlich für solche Datenmengen selbstverständlich sein. Knackpunkt beim Import ist ja die Tatsache, dass erst mal alle nodes gecached werden bevor dann die Ways und Relations berechnet werden. Wenn die gecachten Nodes alle in den Speicher passen, ist das ganze auch einigermassen schnell. Wenn Postgres aber auf die Festplatte zugreifen muss ist das um den Faktor 100 oder mehr langsamer. Irgendwo steht doch eine Übersicht wieviel Speicher für Europa oder das komplette Planet File notwendig sind damit alles im Speicher gehalten wird. 2,5GB sind da aber definitiv zu wenig.
In einem Vortrag ist die Optimierung der Render Toolchain sehr gut erklärt:
http://www.geofabrik.de/media/2010-07-10-rendering-toolchain-performance.pdf
Beim Planet import braucht man wohl etwa 48GB um alle Nodes im Speicher zu halten und dann geht der Import auch recht schnell (unter 5 Stunden). Wie groß ist Europa ? Etwa die Hälfte vom Planet File also wird man wohl knapp 24GB brauchen damit das ganze auch schnell geht …
Weil der Rechner der das importiert, nicht mehr hat, es sich auch nicht mehr einbauen lässt und sonst auch nicht mehr braucht. Nächsten Mal werde ich das auch auf einem anderen Rechner machen