Full Planet Import mit Osmosis klappt nicht

Hallo,

ich versuche seit ca. 1 Woche, einen Full Planet Import mit Osmosis zu machen, bisher allerdings ohne Erfolg. Hier meine Systeminfos:

  • Core i7-4790
  • 32GB RAM
  • Seagate ST6000NM0024 Harddisk exclusiv für Postgres (keine SSD!)
  • Windows7 64bit
  • Postgres 9.4.1 (PostGIS 2.1.5)
  • Osmosis Version 0.43.1

Bisher hatte ich in meine DB nur kleinere Gebiete bis zur Größe von Deutschland importiert, das klappt gut. Den vollen Planeten bekomme ich nicht importiert, weil entweder

a) der Import ewig dauert. Ich benutze dazu den Dump Ansatz ohne “enableBboxBuilder=yes enableLinestringBuilder=yes”, d.h. diese Daten werden dann im pgsnapshot_load_0.6.sql SQL Skript durch die folgenden Statements berechnet:


-- Comment these out if the COPY files include bbox or linestring column values.
-- Update the bbox column of the way table.
UPDATE ways SET bbox = (
	SELECT ST_Envelope(ST_Collect(geom))
	FROM nodes JOIN way_nodes ON way_nodes.node_id = nodes.id
	WHERE way_nodes.way_id = ways.id
);
-- Update the linestring column of the way table.
UPDATE ways w SET linestring = (
	SELECT ST_MakeLine(c.geom) AS way_line FROM (
		SELECT n.geom AS geom
		FROM nodes n INNER JOIN way_nodes wn ON n.id = wn.node_id
		WHERE (wn.way_id = w.id) ORDER BY wn.sequence_id
	) c
);

Für Deutschland laufen beide UPDATEs in wenigen Stunden durch, beim vollen Planeten hab ich nach 5 Tagen abgebrochen.

b) der Import mit Out-of-Memory abbricht. Da das Erstellen der bbox und linestring Spalten durch Postgres nicht klappt, bleibt noch die Option, beides durch Osmosis schon in den Dump Files vorberechnen zu lassen. Das funktoniert aber auch nicht, weil mir der Speicher ausgeht.

In der Windows Console habe ich vor dem Aufruf von Osmosis den Java Heap hochgesetzt:


set JAVACMD_OPTIONS=-Xmx32G -XX:-UseGCOverheadLimit

Und bei Osmosis benutze ich im Vergleich zu (a) die folgenden Switches zusätzlich:


enableBboxBuilder=yes enableLinestringBuilder=yes nodeLocationStoreType=InMemory

Nach einiger Zeit kommt es dann zu folgendem Fehler (zum Zeitpunkt des Abbruchs hat “nodes.txt” eine Größe von ca. 232GB, “users.txt” ca. 5MB):


SEVERE: Thread for task 1-read-xml failed
java.lang.OutOfMemoryError: Java heap space
        at org.openstreetmap.osmosis.pgsnapshot.common.InMemoryNodeLocationStore.addLocation(InMemoryNodeLocationStore.java:132)

Hat jemand noch eine Idee, wie ich den Planeten importiert bekomme? Oder ist mein Hardware Equipment einfach zu schlecht? Das finde ich insofern verwunderlich, weil - wenn man diversen Postings glauben darf - vor 2 bis 3 Jahren noch 16GB RAM für den In-Memory Import Ansatz (b) ausreichend waren. Und jetzt krieg ichs nichtmal mit dem doppelten Speicher hin.

Grüße,
Pete.

Ich hab jetzt mal eine weitere Dump Generierung mit


nodeLocationStoreType=TempFile

gestartet. Hoffentlich läuft das in ein paar Tagen durch. Kann man für das TempFile einen Pfad angeben? Dann würde ich das File auf meine System-Partition (mit SSD) legen, da sind noch ca. 150GB frei.

Edit: ich seh gerade, das Node File liegt im \AppData\Local\Temp Folder meiner System-SSD. Damit hat sich diese Frage auch geklärt.

Grüße,
Pete.

hi,

der komplette OSMOSIS-Aufruf oder noch besser der gesamte Batch würde was bringen.

gruss
walter

Hallo walter,

der Aufruf von Osmosis ist genauso wie im Wiki beschrieben, d.h. unspektakulär:


7z.exe e -so C:\planet.osm\planet-141008.osm.bz2 | osmosis.bat --read-xml file=- --write-pgsql-dump directory=D:\dumps\planet_20141008 enableBboxBuilder=yes enableLinestringBuilder=yes nodeLocationStoreType=TempFile

Mit dem TempFile Ansatz hat die “nodes.txt” Datei im Moment schon 140GB und ich bin diesmal ganz zuversichtlich, dass die Dump Generierung durchläuft.

Danach lasse ich dann die Import Skripte loslaufen:


pgsnapshot_import_0.6_create.sql
pgsnapshot_import_0.6_action.sql
pgsnapshot_import_0.6_bbox.sql
pgsnapshot_import_0.6_linestring.sql
pgsnapshot_import_0.6_load.sql

Grüße,
Pete.

Jo, macht Sinn.

Und was kommt dann? was willst du eigentlich mit der DB anstellen? Und wie willst du die aktuell halten?

Gruss
walter

Danach importiere ich noch weitere Full Planet Datenbestände aus 2013 und 2012. Anschliessend mache ich dann Analysen, wie sich die OSM Coverage in den letzten Jahren entwickelt hat. Die Daten aktuell halten muss ich also nicht.

Grüße,
Pete.

ok, nix mit rendern, nix mit Diffs.

ja, dann sollte das hinhauen.

hast du mal an den Import/Auswertung der Full-History gedacht? Da sollte doch auch alles drinstehen, nur halt alles zusammen in einer DB. Hab aber selber keine Erfahrung damit.

Gruss
walter

Prinzipiell ja, allerdings will ich den jeweiligen Stand u.a. auch visualisieren. Deshalb arbeite ich lieber mit mehreren Importen.

Grüße,
Pete.

Also doch :wink:

Sorry, ich frage so hartnäckig, weil ich da vor 3 jahren mal mächtig auf die selbige gefallen bin, weil ich das unpassende SQL-Template genommen habe.

Darstellen wird dir dann schwer fallen, wenn du als Relationen erfasste Multipolygone darstellen willst.

Das wären:

  • sehr viele Landuses
  • viele Buildings
  • alle Grenzen
    und ähnliches. Alles was Flächen beschreibt und als MP erfasst ist.

In der Snapshot-DB und auch in der Simple hast du nur die einzelnen Ways, die zusammen den Rand der Fläche bilden, plus die Relation, die für den Zusammenhalt sorgt.
Brauchst du die Fläche als Objekt (z.B. um Größenänderungen zu finden oder zum Rendern), bist du fast aufgeschmissen.

ym2c
walter

Die OSM Darstellung hab ich bereits an den kleineren OSM Ausschnitten (bis hin zu Deutschland) ausprobiert. Ich fasse dazu mit ST_Collect() die einzelnen Multipolygon-Teile einer Relation zusammen. Das Rendern der Karte erfolgt dann mit OpenJUMP, da kann ich Layer definieren und jeweils per SQL Query die Daten ohne weitere Umwege direkt aus Postgres auslesen. Ohne die mächtigen PostGIS Funktionen wäre ich in der Tat augeschmissen.

Grüße,
Pete.