ich habe nun erstmals unter Systemeinstellungen > Java > Java > Ansicht > Java Runtime Environment Einstellungen unter Runtime-Einstellungen den Parameter -Xmx1536m (1,5GB) zugewiesen. Wie groß sollte der Wert sein denn, exakt die 1GB/1024MB? Ich habe etwas beliebiges genommen, da ich nicht weiß, was ich brauche.
Noch kann ich nicht beurteilen, ob das was geholfen hatte.
Bleibt der Speicherplatz bei dieser Version von mir dauerhaft Java zugewiesen oder nur für die Zeit, wo JOSM (oder sonst ein Java Programm) läuft?
EDIT: ich habe nun die josm-tested.jar file downgeloaded und die liegt im Download-Ordner. Welchen Befehl muss ich genau eingeben, damit das Ding startet im Terminal? Ich habe mal in den Ordner gewechselt mit
cd downloads
bzw.
cd browser
und bin nun im Ordner, wo die Java-file liegt.
Was tippe ich nun genau weiter ein beim Mac?
Der Default ist unter Linux ~750 Mb, daher liegst du mit dem doppelten Wert ganz richtig.
Wird nur belegt, wenn Josm aktiv ist. Ich vermute, dass das eh nur der maximale Wert ist und der für Java notwendige Speicher dynamisch bis zum Maximum angelegt wird.
Suche mal nach einem File “josm”. steht bei mir (ubuntu) auf /usr/bin Das ist der Script, mit dem Josm aufgerufen wird.
Da steht (bei mir) u.A. JAVA_OPTS=“-Djosm.restart=true -Djava.net.useSystemProxies=true $JAVA_OPTS” drin. Also reicht es, die Environment-Variable JAVA_OPTS zu setzen.
Ich habe dafür (Ubuntu) /etc/default/josm geändert:
# Options to pass to java when starting JOSM.
# Uncomment the JAVA_OPTS lines to enable their use by /usr/bin/josm
# Increase usable memory
JAVA_OPTS="${JAVA_OPTS} -Xmx2048m"
# Enable OpenGL pipeline (2D graphic accelerators)
#JAVA_OPTS="${JAVA_OPTS} -Dsun.java2d.opengl=True"
Wie das beim Mac geht, weiss ich net. Knackpunkt ist aber, dass JAVA_OPTS “irgendwie” gesetzt wird, bevor Josm aufgerufen wird.
Auf jeden Fall ist das mMn der beste Weg, da die vom Josm-Team bevorzugte Methode verwendet wird.
Vor solchen Aktion erstelle ich vom JOSM Verzeichnis , Microsoft Windows PC AppData\Roaming oder
%APPDATA%\JOSM
ein Backup.
In der Praxis habe ich immer eine saubere Erst- Installation von JOSM (mit all meinen persönlichen Einstellungen) auf Vorrat, denn JOSM sammelt mit der Zeit alle möglichen temporären Daten, und wird daher bei Power Usern mit der Zeit langsamer. Muckt dann mal JOSM endgültig*, so benenne ich das aktuelle JOSM Verzeichnis %APPDATA%\JOSM in JOSM-Defekt um, und kopiere mein Vorrat Backup ein. So bleibt JOSM bei mir immer frisch und Jung.
Beim Mac funktioniert das genauso, ich habe aber gerade für OSX den JOSM Pfad nicht zur Hand.
*Beispiel für einen bei mir regelmäßig vorkommenden endgültige JOSM Defekt. Je Mausklick springt der Zeiger einen kleinen Ruck weiter, und zeichne hierbei einen Way auf den Bildschirm.
Hmmm, das könnte in der Tat ein Grund auch sein. Weil, ich hatte sonst bisher nie Probleme mit Java und meine beiden Mac’s haben jeweils 8-16GB RAM und ich hatte wirklich noch nie Probleme.
Wo kann ich temp. Dateien im JOSM löschen?
Naja, der vergrößerte Memory bewirkt “nur”, dass auch bei großen Datenmengen alles im Speicher steht. Und da wirst du einen Unterschied nur bemerken wenn du wirklich große Bereiche mit verschiedenen Speichergrößen lädst.
z.B. beim Scrolling oder Zoomen sollte das bemerkbar sein. Bei dem “Mausschieben” würde ich keine Änderung erhoffen, da ja der aktuelle Bereich (sichtbares Fenster?) sicher immer im Speicher sein wird.
Letztere Aussagen sind aber schon als spekulativ zu bewerten, weil gemessen hab ich das auch nicht. Nur die allgemeine Erfahrung, dass es dann flüssiger läuft.
JOSM hält (bis auf Hintergrundbilder) immer alle Daten im (Java-) Speicher. Es ist also immer eine gute Idee, für JOSM die Speicherobergrenze hoch anzusetzen, insbesondere, wenn der Rechner sonst nichts zu tun hat (ich verwende 5 GB). Ansonsten versucht die Garbage Collection permanent (und vergeblich) Speicher freizugeben bis irgendwann die Reißleine gezogen wird.
Bei mir wird JOSM deutlich langsamer, wenn ich z.B. eine 10 MB pbf (~135MB als xml) Datei lade. Sobald ich dann aber auf einen Bereich zoome, den man sinnvoll bearbeiten kann, geht es wieder flott. Eine Performance-Analyse[1] hat gezeigt, dass bei der Gesamtansicht die meiste Zeit für das Rendern der Objekte verbraucht wird, es wird wahrscheinlich jedes noch so kleine Detail gerendert. Wenn man reinzoomt, verringert sich die Annzahl der darzustellenden Objekte, damit geht es wieder flüssig. Ich habe keine Grafikkarte, daher macht die CPU alles, vielleicht ist das bei Rechnern mit GPU weniger drastisch.
Gerd
[1] Mit den Tools JMC (Java Mission Control) bzw. Visual VM
Gibt es denn (bisher) keinen Möglcihkeit, den temp. Speicher von JOSM zu löschen?
Ich habe dies auch als “Bug” an JOSM gemeldet. Auch andere User unter Windows z.B. haben von einem ähnlichen Problem dort berichtet.
Eine weitere Frage zu GPX-Spuren:
Kann man mit dem Plug-In GPX-Edit Teile eines GPX-Tracks übernehmen als Linie? Es ist nämlich oftmals so (beim Zeichnen von Pfaden und Wegen im Gelände), dass ich einen langen GPX-Track habe und Teile davon - wenn ich einen neuen Weg gefunden habe - in OSM übernehmen möchte. Hierbei wäre es hilfreich, wenn ich einfach Anfang-/Endpunkt anklicken könnte und diese Linie wird dann auf die Datenebene übernommen. Dzt. ist das ganze Prozedere sehr mühsam: GPX Track in Datenebene konvertieren > Datenebene vereinigen > Überschuss aller rauslöschen > Rest taggen wie erforderlich.
Weiß hier jemand Hilfe?
Von welchem temp. Speicher sprichst Du. Was soll darin gespeichert sein?
Für Hintergrundbilder gibt es einen Cache, den kann man über das Menu nach Rechts-Click auf den Hintergrund löschen.
Anosnten legt JOSM Sicherungen der Daten an, damit bei einem Programmabbruch weniger verloren geht. Siehe Einstellungen → Karten-Einstellungen->Reiter “Sicherungsdatei”
Soll das bedeuten, du übernimmst die in OSM-Daten konvertierten Tracks teilweise direkt in OSM? Mit alle technisch bedingten Abweichungen/Schwankungen/Spikes?
Finde ich nicht OK. Eine Generalisierung durch “Drübermalen” ist mMn wesentlich besser.
Ich arbeite in Josm mit Tracks folgendermaßen:
als GPX-Layer laden (rote Linien)
Datenlayer von OSM laden
Erfassen der Daten (z.B. neue Wege) wie üblich im OSM-Datenlayer
ggf GPX-Layer hochladen
Nur wenn ich den GPX-Track hochladen möchte und dort Stellen sind, die mir missfallen:
GPX-Layer zu Datenlayer konvertieren
Datenlayer (Aufpassen: ohne OSM-Daten!!!) bearbeiten (z.B. Start, Ende oder Spikes löschen)
Exakt, denn ich übernehme nur jene (Teile von) Wege(n), die am Luftbild nicht sichtbar sind (meist im Wald liegen). Ergo ist mit “drübermalen” nix, denn ich kann mich nur auf den Track verlassen. Warum also den GPX-Track abzeichnen, wenn er ja schon da ist? Es wird dadurch weder genauer noch sonst was, da - wie schon geschrieben - kein Weg zu sehen ist. Dass er durchaus ein paar Meter Abweichung haben kann, ist mir bewußt und muss ich in Kauf nehmen - ich habe keine andere Wahl.
Vergleiche ich jedoch regelmäßig Track und Luftbild, wo ein Weg zu sehen ist, beträgt diese Abweichung meist keine 2m und damit sehe ich diese als vernachlässigbar an. Mein Garmin Oregon 600 zeichnet schon sehr genau auf. Die Zeiten, wo die Tracks mehrere Meter vom realen Wert entfernt sind, sind ja schon länger passe.
Hast Du kein Werkzeug zum Vergleichen von Dateien? Zur Not sollte es ein diff geben.
Neben den Einstellungen, die Du schon genannt hast ist wohl alles im Bereich Kartenstile interessant.
Ich habe nun die ganzen Einstellungen im Expertenmodus exportiert in eine xml-File und ins andere Gerät eingespielt. Also von dem einem JOSM auf Mac A auf den JOSM in Mac B. Unverändert, keine Richtungspfeile. Ergo können es diese Einstellungen nicht gewesen sein.
Kartenstile sind die gleichen, die ich verwende: JOSM Standard Map und Neuer Grundstil
Ich habe eine weitere Frage zum Plug-In “Building-Tools”: kann man das default-mäßig so einstellen, dass die gezeichneten Gebäude mit building = residential getaggt werden, statt mit building = yes?
Danke vielmals. Ich bin mittlerweile voll auf den JOSM umgestiegen und arbeite doch intensiv damit. Um das Mapping zu beschleunigen und zugleich effektiver arbeiten zu können, sind solche Tipps hilfreich.
Das hilft in der Tat sehr, grad wenn man kontinuierlich gleichartige Gebäude mappt. Praktisch für den Anwender wäre nur, wenn man dies anderweitig switchen könnte, also während dem eigentlichen Arbeiten (ohne jedes mal den JOSM neu zu starten).
Die Zeiten, wo die Tracks mehrere Meter vom realen Wert entfernt sind, sind ja schon länger passe.