Wie lange dauert der Import eines Planetfiles mit osm2pgsql ?

monotar · 2011-01-28T19:48:14.000Z

Wuestenfuchs:

Das teil brauch halt nur 20W und kann wegen mir wochenlang durchlaufen.

dir ist schon bewusst, dass du einen 6-core auch wieder schneller ausschalten kannst, selbst wenn er mehr verbraucht?

chris66 · 2011-01-28T19:50:25.000Z

Wuestenfuchs:

Aktuell ist er bei:
Processing: Node(938392k) Way(44468k) Relation(0)

Ist das die Anzahl oder ID der importierten Objekte?

höchste Node ID zur Zeit ist ca. 1100 Mio.
höchste Way ID ca. 97 Mio.

Chris

Wuestenfuchs · 2011-01-28T19:55:02.000Z

monotar:

Wuestenfuchs:

Das teil brauch halt nur 20W und kann wegen mir wochenlang durchlaufen.

dir ist schon bewusst, dass du einen 6-core auch wieder schneller ausschalten kannst, selbst wenn er mehr verbraucht?

Ich kann den Import aber nicht mittendrin unterbrechen oder?

aighes · 2011-01-28T19:55:31.000Z

Nochmal die Frage:
Bist du denn sicher, dass du den ganzen Planeten brauchst? Bei Europa wären es noch ca. 1/3 der Daten, bei Deutschland noch weniger. Dann könnte man auch osmosis und das pbf-Format nutzen, was das ganze nochmal deutlich beschleunigen dürfte. pbf ist im vergleich zum xml-Format beim erzeugen von normalen Daten rund 7mal schneller, bei Datenbanken dürfte es ähnlich sein. Wenn du europa nutzen möchtest, musst du eine osmosis-Version ab heutigen Datum nutzen.

@chris: bei den nodes sind wir schon über der Milliarde. (höchste ID)

chris66 · 2011-01-28T19:57:00.000Z

aighes:

@chris: bei den nodes sind wir schon über der Milliarde. (höchste ID)

Ja, hatte ich oben schon korrigiert.
Bei den Ways ist er also ca. bei der Hälfte.

Chris

Wuestenfuchs · 2011-01-28T19:59:29.000Z

Ich bin auf dem Gebiet noch ziemlich neu,
mit osmosis habe ich Mapnik nicht zum laufen gebracht, das brauche ich aber da ich auf die OSM Daten eigene Objekte draufrendern möchte.

Ich brauche Europe, Californien und Philippinen, ok ich probier das ganze mal getrennt zu importieren.

Gruss

Wuestenfuchs · 2011-01-28T20:00:19.000Z

Ich lasse den Atom mal weiterwerkeln und starte mit dem 6core

aighes · 2011-01-28T20:05:46.000Z

chris66:

aighes:

@chris: bei den nodes sind wir schon über der Milliarde. (höchste ID)

Ja, hatte ich oben schon korrigiert.
Bei den Ways ist er also ca. bei der Hälfte.

Ja und bei den Nodes ist er durch…ich würde es nicht abbrechen…

efred · 2011-01-28T20:28:19.000Z

Wuestenfuchs:

Ich kann den Import aber nicht mittendrin unterbrechen oder?

geht schon. Du musst aber auf jedenfall wieder neu anfangen - das heisst, Du kannst nicht auf einem anderen Rechner dort weitermachen, wo Du jetzt aufhören würdest.

Wuestenfuchs:

Ich lasse den Atom mal weiterwerkeln und starte mit dem 6core

~~auch wenn der Atom schon 4 Tage lief, ich nehme jetzt mal schwer an, der 6core wird einiges früher fertig sein. (ich hoffe mal, der 6core hat mehr als nur 2 GB Ram)~~

Edit: ohhh hoppla… jetzt sehe ich erst das k bei den Zahlen… Sorry… Durchlaufen lassen, bloss nicht abbrechen… Das dauert nicht mehr allzulange…

Wuestenfuchs · 2011-01-29T22:10:08.000Z

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

ajoessen · 2011-01-31T07:43:44.000Z

efred:

Wuestenfuchs:

Ich kann den Import aber nicht mittendrin unterbrechen oder?

geht schon. Du musst aber auf jedenfall wieder neu anfangen - das heisst, Du kannst nicht auf einem anderen Rechner dort weitermachen, wo Du jetzt aufhören würdest.

Wuestenfuchs:

Ich lasse den Atom mal weiterwerkeln und starte mit dem 6core

~~auch wenn der Atom schon 4 Tage lief, ich nehme jetzt mal schwer an, der 6core wird einiges früher fertig sein. (ich hoffe mal, der 6core hat mehr als nur 2 GB Ram)~~

Edit: ohhh hoppla… jetzt sehe ich erst das k bei den Zahlen… Sorry… Durchlaufen lassen, bloss nicht abbrechen… Das dauert nicht mehr allzulange…

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

brogo · 2011-01-31T08:40:45.000Z

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

ajoessen · 2011-02-01T07:28:47.000Z

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

aighes · 2011-02-01T07:58:50.000Z

Bei dir dürfte es “deutlich” schneller gehen, wenn du das packen der geschnittenen osm-Datei lassen würdest.

ajoessen · 2011-02-01T08:13:58.000Z

aighes:

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

Wuestenfuchs · 2011-02-01T13:56:49.000Z

Das parsen ist jetzt fertig, dauerte insgesamt 9,3 Tage
Nun noch das Processing abwarten, dann isses geschafft.

Wuestenfuchs · 2011-02-10T19:34:38.000Z

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$

SunCobalt · 2011-02-10T20:37:42.000Z

17 Tage

TobWen · 2011-02-12T14:13:00.000Z

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.

SunCobalt · 2011-05-08T18:12:26.000Z

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)