OSM_Composer und Java Speicher

Hallo,
also ich nutze den OSM_Composer schon etwas länger.
Da ich ab und zu halt recht große Daten damit verarbeite hab ich jetzt meinem System etwas mehr RAM gegönnt, und auf 8GB aufgerüstet.
Aber warum nutzt das Progi nicht den Speicher. Ich hab unten unter Einstellungen “Speicher für Java Aufrufe” den Wert auf 6500 gestellt und trotzdem kommt das System nur auf 3500 Speicherauslastung.
Hab auch die start.bat 64bit angepasst und dort den Wert auch auf 6500 erhöht aber das gleiche, Speicherauslastung liegt nur bei max.50% und da hab ich noch ein zwei andere Programme mit offen.
Wo kann ich noch schrauben damit er beim rendern von Deutschland zB mehr Speicher nimmt und das nicht so lang dauert.
System i5-760 / 8GB RAM / 1GB Grafik / WIN7-64bit / Java_64
Gruß AlterSachse

  • Job öffnen
    1. Reiter “Parameter”
  • Composer Nodecache erhöhen, dann wird er gierig.

bye
Nop

Hallo Nop,
Danke für den Tipp, damit wird es deutlich besser.
Aber leider nur wenn ich bei “Region” Lokale OSM Datei komplett gewählt habe.
Wenn ich aber einen Ausschnitt aus einer Planet Datei (europe.osm.bz2) nehme passiert zum Anfang (wenn Osmosis läuft) nicht viel.
Anhang kleines Auslastung’s Bild

Kann man da noch was drehen das Osmosis mehr Speicher bekommt.
Gruß und schönes WE
AlterSachse

Nein, osmosis braucht nicht sonderlich viel Speicher. Problematisch ist bei osmosis eher CPU-Takt eines Cores und die HDD.

Eine drastische Beschleunigung würde hier das binäre Datenformat bringen. Dann musst du dies allerdings selber machen und dem Composer dann diese Datei als Datei geben. Wenn du genügend HDD-Platz hast empfiehlt es sich auch, die osm-Dateien nicht in eine bz2-Datei zu packen.

Hallo aighes;
na ja so mit selber machen scheitere ich meistens mit den bat Befehlen und so deshalb hab ich auch das Vorhaben mit Linux und Osmosis erst mal auf Eis gelegt.
Aber wenn ich Dich jetzt richtig verstehe wäre ein Entpacken der *.bz2 Datei besser und die Sache würde sich beschleunigen, das werde ich testen.
HDD ist kein Prob bei mir :wink:
Gruß und schönes WE
AlterSachse

Meine Erfahrung war bei den bz2-Dateien, dass es schneller geht, wenn man diese selber entpackt. Einfach weil osmosis nur einen Kern nutzt.

Am meisten “Gewinn” kannst du aber über das binäre Format machen. Da ist Faktor 6-7 realistisch. Vielleicht kommt ja irgendwann mal eine Unterstützung dieses Formates in den Composer.

Ich habe mir persönlich als Benchmark gesetzt: Sobald ein Monat ins Land geht, ohne daß über die Dev-Listen ein PBF-Problem oder ein PBF-Fix geht, dann sehe ich mir das mal näher an. Generell gefällt mir das Format aber für interne Dateien überhaupt nicht, da es nicht mal eben jedem Texteditor geöffnet, dursucht und debuggt werden kann. Da müßte der Geschwindigkeitsgewinn schon ganz enorm sein.

bye
Nop

Beim Zuschneiden mit bbox gehts schon ziemlich schnell ab mit pbf als input; allerdings gibts beim europe.pbf unter Windows noch Probleme, die bisher nur in irgendwelchen dev-Versionen behoben sind.

gruß,
ajoessen

Zur Geschwindigkeit: Ich schneide aus europe.osm.pbf Deutschland, Skandinavien, BeNeLux und den Alpenraum in 23min aus (pbf->pbf). Bei bz2 lag die Zeit bei >~2h (bz2->pbf).

Zum Format an sich. Prinzipiell hast du recht. Einfaches Debugging ist nicht möglich. Allerdings stellt sich die Frage, war es das denn vorher? Evtl. bei kleinen Regionen. Aber so eine ganze Composer-Kachel hatte bei mir auch mehrere 100mb. Das machen die normalen Texteditoren auch nicht mehr mit.

Wobei es mir egtl. mehr um den Schritt pbf → osmosis → xml → composer… ging, als um den kompetten Composer-Workflow.

@ajoessen:
Da kommt bald die 0.39, dann ist alles wieder iO

Hoffentlich kommen dann auch die cascadingRelations mit rein. Derzeit werden wieder alle Relationen beim bbox-Filter ausgegrenzt, die aus Relationen mit member-ID>ElternrelationsID bestehen.

Ob Frederik das dann auch bei den Geofabrik-Extrakten anwedet, ist nochmal ne andere Sache :frowning:

gruß,
ajoessen

Und das ist der Grund, warum ich mich mit dem Thema noch nicht beschäftige. Es ist irrelevant, wieviel schneller das Ausschneiden geht solange die Daten hinterher kaputt sind.

Wer unbedingt pbf möchte, kann den Osmosis-Schritt ja einfach von Hand und auf eigene Verantwortung durchführen. Aber ich werde nix in Composer einbauen wovon ich weiß daß es nicht zuverlässig funktioniert.

bye
Nop

HI,
also ich hab mir mal die europe.osm.pbf gezogen und dann mit osmosis 0,38 das Teil mit folgendem Befehl geschnitten.

Das ging ziemlich fix, die so erhaltene Datei hab ich dann durch den Map_Composer gejagt und musste feststellen das außer den Symbolen nichts da ist. Also es war nicht ein Weg geschweige den ein Poly vorhanden.
Liegt das nun an meiner *.bat mit der ich osmosis aufgerufen habe oder liegt das an der Sache an sich.
Gruß AlterSachse

Wie ich schon oben schrieb: mit dem europe.pbf gibts derzeit Probleme unter Windows, weil java mit den 4GB irgendwo nicht klar kommt. Nach einer bestimmten Anzahl nodes hört osmosis einfach auf, ohne Fehlermeldung. Mit 0.39 soll das behoben sein. Solange kannst du dir mit europe.osm.bz2-Extrakten behelfen.

gruß,
ajoessen

Hallo,
Danke für die Info dachte schon an der *.bat ist was falsch.
Da werde ich mal auf die 0,39 warten und neu probieren.
Gruß

Du musst einen der unteren (ab 25166) SNAPSHOTS von der Seite nehmen

Hallo,
ok das werde ich auch mal probieren.
Hab jetzt noch mal die europe.osm.bz2 genommen (gestern die war defekt) also musste ich heute noch mal die 7GB laden.
Aber das nun mit Erfolg, entpackt 90GB dann durch osmosis gezogen

Super, das dauerte ja nur 30min mit der gepackten Datei hab ich letztens 8h gebraucht.
Dann die Datei durch Map_Composer gejagt und endlich wieder super Dakota Karte gehabt.
Aber ich werde an der Sache mit der europe.osm.pbf dran bleiben und auch das probieren.
Gruß AlterSachse