osmosis bbox: Dauer & Fehlermeldung

Communities Deutschland (Germany)
1

Hallo,
da ich mich mit osmosis beschäfftigen muss, habe ich mal damit angefangen, meinen Ort bzw 2x2km aus dem Bundesland auszuschneiden.

osmosis --read-xml file=“baden-wuerttemberg.osm” --bb bottom=“48.6786468199982” top=“48.7146471800018” left=“9.67907404996259” right=“9.73358955003741” clipIncompleteEntities=true --write-xml file=“eislingen.osm”

Ist es normal, dass das Stunden dauert? Ich bekomme auch Fehlermeldungen, die mich bei Google nicht weiter bringen. Die folgende Fehlermeldung wiederholt sich. Nur die Größe wird langsam größer. Ehrlich gesagt weiß ich nicht, ob das überhaupt zu Erfolg führt, da aus verschiedenen Gründen die Berechnung nach 2-3 Stunden abgebrochen wurde.


GC Warning: Repeated allocation of very large block (appr. size 11583488):
        May lead to memory leak and poor performance.

Lt. Top rennt java mit 100% CPU Auslastung.

2

hi thomas,

eigentlich sollte der schon was schneller sein.

gib osmosis mal etwas mehr speicher (z.B. mit -Xmx512M) dort wo das programm aufgerufen wird - also im script/batch
hatte ich bei mir zwar nicht drin aber bei vielen java-programmen (z.b. josm) bringt das was.
lg
walter

p.s. für so einen kllitzekleinen ausschnitt würd ich mir die mühe aber nicht machen - höchstens zum üben.

3

und 100% cpu ist ok, der muß ja fürchterlich rechnen “isser drin oder nicht?”

4

so nach 4 Stunden hat er es geschaft, 2,5MB aus 1,5GB auszuschneiden. Der Speicher war nicht der limtierende Faktor. Der dümpelte so bei 8% rum. Blöd war nur, dass nur ein Prozessor genutzt wurde. Aber danke für den Tipp. Für andere Aufgaben wird Speicher wichtiger sein und ich habe das geändert.
War auch eher eine Übung und meine erste Aktion mit Osmosis. XAPI wäre wesentlich einfacher gewesen. Jetzt weiß ich, dass alles mit osmosis ewig dauert. Wie soll das nur mit noch größeren Datenmengen gehen. Das war ja nur ein Bundesland.

5

Hallo Thomas,
ich schneide mir aus dem Europa-Extract 9 Regionen in einem Durchgang aus. Das sind 90GB Daten und das dauert 1,5h mit langsamer, da sehr alter Festplatte. Da muss bei dir noch ein Flaschenhals im Weg sein.

6

Hallo Henning,

danke für die Info. So ein Vergleichswert hat mir bis jetzt gefehlt. Ich werde heute Nacht mal ein Linux Buch unter mein Kopfkissen legen und auf eine Eingebung hoffen. Im Ernst: Ich habe keine Idee woran das liegen könnte. Alles andere, Mapgen, WMS-Server, etc läuft bei mir ohne Probleme. Hast Du die osmosis Datei angepasst?

7

Lies mal unter http://wiki.openstreetmap.org/wiki/Osmosis/Examples nach. Ich schätze mal die Option enableDateParsing=no sollte mal etwas helfen. Die Geschwindigkeitsmessungen die ich mal gemacht habe, hab ich dort hinterlegt. Allerdings schneide ich aus dem bz2 komprimierten europafile aus…

Markus

PS: Die verwendete Javaversion ist eine einigermaßen aktuelle? Das hat bei mir anfangs Ärger gemacht …

8

hi, das mit dem java-stack/heap ist so ne sache. und wenn du 32 gb drin hättest, nimmt der trotzdem per default nur 32MB (oder 64?) und mehr nicht. und in diese 32 oder 64mb “quetscht” er alles rein was geht. der freie speicher des systems wird nicht genutzt :frowning:

9

Ne, ich nutze die aktuelle 0.37 (mit pbf-Support). Du musst halt den Speicher über die Kommandozeile ordentlich zuweisen, wie Walter schon geschrieben hat. Ich bleibe da 1gb unterhalb der RAM-Menge. Das nutzt er aber nur, wenn er es braucht. Sprich eine große Zahl ist nicht schädlich. Swap/Auslagerungsdatei ist bei mir grundsetzlich deaktiviert. Das bremst nur unnötig.

10

wo gebt ihr die -Xmx1048m an? In der …/osmosis Script-Datei selbst, habe ich verschieden Möglichkeiten versucht. Aber ich bekomme jedesmal ein Fehler. Vielleicht kann mir jemand die entsprechende Zeile kopieren. Direkt per Java kann ich osmosis nicht ansprechen, da ich die weiß, welche *.jar ich nehmen soll. Eine osmosis.jar finde ich nicht…vielleicht die osmosis-core-0.37.jar.
Vielen Dank

11

Unter Windows sieht das für Version 0.37 so aus:


java -Xmx7G -cp "D:\OpenStreetMap\mkgmap\bin\osmosis\lib\default\plexus-classworlds-2.2.2.jar" -Dapp.home="D:\OpenStreetMap\mkgmap\bin\osmosis" -Dclassworlds.conf="D:\OpenStreetMap\mkgmap\bin\osmosis\config\plexus.conf" org.codehaus.classworlds.Launcher --read-pbf baden_wuerttemberg.osm.pbf --tee outputCount=1 --bb bottom="48.6786468199982" top="48.7146471800018" left="9.67907404996259" right="9.73358955003741" --write-xml file="eislingen.osm" %*

Die Pfadangaben musst du halt anpassen. -Xmx7G entspricht 7GB, die er nutzen darf.

12

sollte es wohl sein. achtung: -Xmx1024M mit GROSSEM MMMM - sicher ist sicher
gruss
walter

13

Hallo,

ich nutze für meine Zuschneidungen folgenden Aufruf:
boundingbox.bat
D:\Karten\OpenStreetMap\osmosis\bin\osmosis.bat --read-xml D:\Karten\osm\Geofabrik\nordrhein-westfalen.osm --bb left=8.13 right=8.49 bottom=51.1 top=51.29 --write-xml Schmallenberg.osm

(alles in einer Zeile)
Und das läuft auch ohne Klimmzüge in annehmbarer Zeit durch.

Noch schneller wirds, wenn man die Daten aus seiner eigenen Datenbank fischt. Aber der Aufwand dafür ist dann etwas größer…

Gruß,
ajoessen

14

vielen Dank für die vielen Tipps. Ich habe das jetzt auch mal zu Fuss versucht. Mail schauen wie lange das jetzt dauert. Unter Linux sieht das jetzt so aus

nohup java -Xmx1024M -cp /home/thomas/mapgen/osmosis-0.37/lib/default/plexus-classworlds-2.2.2.jar -Dapp.home=/home/thomas/mapgen/osmosis-0.37 -Dclassworlds.conf=/home/thomas/mapgen/osmosis-0.37/config/plexus.conf org.codehaus.classworlds.Launcher --read-xml enableDateParsing=no file=“baden-wuerttemberg.osm” --bounding-box bottom=“48.6786468199982” top=“48.7146471800018” left=“9.67907404996259” right=“9.73358955003741” clipIncompleteEntities=true --write-xml file=“eislingen.osm” &

Wobei das nohup nur dafür sorgt, dass nach dem Abmelden vom ssh Terminal der Prozeß weiter ausgeführt wird.
Java Version ist 1.5.0., scheint nicht die allerneuste zu sein.

15

Kurzer test bei mir:
D:\Karten\OpenStreetMap\osmosis\bin\osmosis.bat --read-xml file=“baden-wuerttemberg.osm.bz2” --bb bottom=“48.6786468199982” top=“48.7146471800018” left=“9.67907404996259” right=“9.73358955003741” --write-xml file=“eislingen.osm”

läuft in 14 Minuten durch. Dabei hab ich mir nicht mal die Mühe gemacht, die Datei zu entpacken.
osmosis 0.36 unter Windows XP mit 512MB RAM

Gruß,
ajoessen

16

sieht eigentlich ganz gut aus.
bei mir rennt java version “1.6.0_18”
OpenJDK Runtime Environment (IcedTea6 1.8.1) (6b18-1.8.1-0ubuntu1)
OpenJDK 64-Bit Server VM (build 16.0-b13, mixed mode)
es gab da mal was mit sun-java versus open-java; aber wenn ich mich recht erinnere, sollte sun-java angeblich besser sein. inzwischen glaub ich aber nicht mehr dran.

auf 1.6 würd ich aber schon hochrüsten - unabhängig von dem problem
gruss
walter

17

werd ich wohl auch machen müssen. Von 14 Minuten (wie oben geschrieben) kann ich nur träumen. Der läuft jetzt schon wieder seit mehr als 3 Stunden :frowning:

18

Schraub mal die Kiste auf: der Hamster da drin ist wohl arbeitsunwillig :wink:

Oder schaff dir ein vernünftiges Betriebssystem von Bill Gates an!

Gruß,
ajoessen

19

unter 5 minuten bei mir: das muss an deiner kiste liegen, denn meine ist nicht die schnellste (1.2 GHz /2 GB Ram)
alte Platte? Kabel, Memory defekt???
gruss
walter

@ajoessen: schöner scherz,:wink:
die nächste Release von Windows soll endlich einen Konfigurator für die Farbe des “Blue-Screens” haben.

20

Wahnsinn!!!

Java 1.5.0 Dauer 4 Stunden 4 Minuten
Java 1.6.0 Dauer 1 Minute 6 Sekunden

Falls jemand das gleiche Problem hat, hier die Lösung.

Java Update:

sudo apt-get install sun-java6-bin sun-java6-jre

sudo update-alternatives --config java

dann “/usr/lib/jvm/java-6-sun/jre/bin/java” auswählen

@Hetzi. Danke für den Tipp