JOSM instellingen om snelheid van imagery verbeteren

Communities Nederland (Netherlands)
,
1

Afgelopen week was ik het zat :slight_smile: Ik liep tegen twee problemen aan met JOSM op Windows:

  • Netwerkfout bij opstarten
  • Trage laadtijden voor lagen/imagery, ondanks krachtige hardware

Vervolgens heb ik GPT5 dit probleem voorgelegd en een screenshot gedeeld van mijn system information (voor zowel mijn werk als privé laptop) en het system report vanuit JOSM.

Hier is wat werkte:

:white_check_mark: 1. Netwerkfout oplossen

  • Voeg JOSM.exe toe aan Windows Defender Firewall → Toegestane apps.
  • Daarna werkte de verbinding zonder proxy-instellingen.

:white_check_mark: 2. Meer geheugen toewijzen

  • Open:
%LOCALAPPDATA%\JOSM\app\JOSM.cfg
  • Voeg onder [JavaOptions] toe:
java-options=-Xms1024m
java-options=-Xmx4096m

(Op Ă©Ă©n systeem heb ik 32GB RAM en gebruik ik 8192m)

:white_check_mark: 3. Sneller imagery laden

  • Cache vergroten: Voorkeuren → Beeldmateriaal → Cache → 4096 MB of 8192 MB.
  • Parallelle downloads:
    Voorkeuren → Geavanceerd:
imagery.tms.parallel-threads = 6 (of 8)
  • Map Paint cache:
mappaint.cache.size = 256

:white_check_mark: 4. Optioneel: Automatisch High Performance energieplan

Maak een .bat:

1 powercfg /setactive <HighPerf-GUID>
2 start "" /wait "C:\Users\<jij>\AppData\Local\JOSM\JOSM.exe"
3 powercfg /setactive <Balanced-GUID>

GUID’s opvragen met:

powercfg /list

:white_check_mark: 5. Geavanceerde JVM-opties (snellere Garbage Collection)

:gear: Waarom GC-tuning JOSM helpt

Verschillende GC-algoritmes maken een afweging tussen snelheid en pauzetijden:

  • Standaard GC: werkt prima, maar bij grote geheugens (bijv. 8 GB) kan JOSM merkbare korte haperingen van een paar tienden van een seconde krijgen wanneer het geheugen wordt opgeschoond.
  • G1GC (Garbage First GC):
    • Ontworpen voor grote heaps (meerdere GB’s).
    • Verdeelt het geheugen in regio’s en ruimt die stapsgewijs op.
    • Resultaat: in plaats van lange pauzes krijg je veel kleine, snelle opruimmomenten → JOSM blijft vlot reageren.

:compass: In de praktijk bij JOSM

  • Wanneer je een grote OSM-extract laadt (bijvoorbeeld een hele provincie), maakt JOSM miljoenen Java-objecten aan.
  • Zonder afgestemde GC zie je af en toe bevriezingen van 1–2 seconden bij zoomen of verschuiven.
  • Met G1GC + pauzetarget worden die haperingen teruggebracht tot nauwelijks merkbare korte schokjes.

(Nu laat ik geen hele provincies in; maar wel een hele wijk)

:white_check_mark: Kortom: GC-tuning maakt JOSM soepeler en responsiever, vooral wanneer je met grote datasets werkt.

Voeg toe in JOSM.cfg:

java-options=-XX:+UseG1GC
java-options=-XX:MaxGCPauseMillis=100
java-options=-XX:+UseStringDeduplication
java-options=-XX:+ParallelRefProcEnabled

:white_check_mark: 6. GPU-versnelling (optioneel)

Test OpenGL:

java-options=-Dsun.java2d.opengl=true

Als instabiel → terugzetten naar false.

Resultaat:
:check_mark: Geen netwerkfouten
:check_mark: Snellere imagery
:check_mark: JOSM blijft soepel, zelfs met meerdere lagen en stijlen

1 Like
2

Overigens werkt de OpenGL setting voor mij niet; dus die heb ik weer weggehaald.

3

Heel goed. Heb ze allemaal in de JOSM.cfg gezet, de Xmx naar 8192m gewijzigd, Zag laatst in Task Manager dat JOSM 5.2GB in gebruik had waar het voorheen bij 4.2GB begon vast te lopen (voor je tweaks hierboven). Na eerste herstart liep alles goed tot ik het Urban Eye 3D paneel lanceerde. Vanaf dat alles langzamer dan een slak, dus die OpenGL heb ik ook op false gezet waarna het UE3D paneel weer normaal snel werkt.

(Heb al sinds een paar stabiele versies een ‘Connect Time Out’ bij het eerste lading van de Imagery set [7 lagen]. Dat is eenmalig. Had gehoopt dat met deze tweaks dit ook zou verdwijnen, maar nee)

1 Like
4

Die timeout herken ik niet; je zou de exacte foutmelding eens aan GPT kunnen voorleggen inc. jouw status report en system information.

5

Frappééérend, dacht de heer van stand. Als expirement de computer aan de 5G hotspot van de tablet gehangen daar de vaste lijn nog steeds op koper zit met een kilometers lange draad naar de dichtsbijzijnde FTTC met op goede dagen 17MB volgens Speedtest. JOSM geherstart en geen timeout bericht. (dus kon geen snapshot van het exacte bericht maken wat het doel was) Terug naar koper
 geen bericht \o/.Beetje gemapped, upload. Dataset gesaved, geherstart, geen timeout \o/. Misschien is JOSM een beetje langzaam van begrip, maar weg is het, wie weet door die config kunsten bijles. We houden ze erin.

:crossed_fingers::crossed_fingers::crossed_fingers:

1 Like
6

Hallucineren is niet vreemd voor een AI en beide genoemende voorkeuren kan ik niet vinden in mijn josm settings.

Behalve -Xms2048M -Xmx8192M gebruik ik:

-XX:+UseParallelGC -XX:+UseAdaptiveSizePolicy

7

Misschien de onderste van imagery settings
 zag die 6 als waarde staan dus dat liet ik zo.

image
image448×477 17.1 KB

8

Max. zoom level 24

1 Like
9

No deze twee items invoegen wilde JOSM geheel niet meer starten, niets zichtbaar in TaskManager wat er gaande was. De comp is van 2012, weliswaar met 16GB en een 2018 display kaart maar daarmee is het wel gedaan.

10

Je kunt hem toevoegen aan de Advanced Preferences (expert mode aanzetten)

image
image1450×661 35.1 KB

11

Dit is wat GPT5 er van vindt en ik zal ze eens proberen:
Yes — those are good choices for JOSM on your setup (Java 21, 12 GB RAM).
They make the Java Garbage Collector (GC) more efficient, especially when editing large areas or using heavy imagery.

How they work:

  • UseParallelGC → Enables the parallel garbage collector, which reclaims memory using multiple CPU cores.
    → Reduces lag spikes when JOSM cleans up memory.
  • UseAdaptiveSizePolicy → Lets Java dynamically tune heap and cache sizes to keep GC efficient.

En dit is de recommendation voor de imagery settings:

:white_check_mark: Recommended optimised values:

  • WMS simultaneous connections: keep 3–4.
  • TMS total concurrent downloads: 8–12 instead of 25.
    → You’ll notice less CPU/network stutter, especially when panning fast or loading large imagery.
  • Per-host limit: 4–6 is fine.
12

Bij mij werkt het gewoon nog:

image
image231×419 8.64 KB

En het eerste wat met de nieuwe settings opvalt is dat BGT Standaard niet meer elke keer opnieuw laad op het moment dat ik het beeld verschuif! Fijn!!

13

Bedankt voor dit onderzoek. Had gisteren nog de JAVA update installer gestart die meteen een nieuwe versie ophaalde, maar dat was slechts een kleine . versie update.

image

Vanmorgen die 2 regels opnieuw erin gezet en weer totaal niets zichtbaar, zelfs niet voor een moment in TM observerende met de processes van I en J in beeld.

Toen alleen java-options=-XX:+UseAdaptiveSizePolicy erin laten staan, weer gestart en dat werkte. Daarna met alleen java-options=-XX:+UseParallelGC, helemaal niets, dus het lijkt erop dat die garbage cleaning optie niet welbekomen is. Alle systeem drivers zijn up to date, dus weet het niet waaraan het kan liggen. Windows 10 staat in het extended support programma (werd voor niets aangeboden omdat X Y Z van toepassing was), dus houdt het nog een jaar of langer. Boots nog steeds zeer snel.

14

Ik zie dat jij nog op Java 8 zit. JOSM adviseert inmiddels Java 11+ en de door JOSM geadviseerde Java JDK “Azul Zulu” zit inmiddels op 21.44.17

Zie: Java 8, 11, 17, 21, 25 Download for Linux, Windows and macOS

image

Misschien eens proberen om alle ‘oude’ Java te verwijderen en dan de laatste JDK van Azul Zulu te instaleren?

15

Het verband tussen de versie wat in de Add Programs van Windows staat en wat JOSM zelf aangeeft (JAVA 21.0.8) ) heb ik niet begrepen maar weet dat er al langer 1 installatie is (was 3) en die staat in het about scherm

image
image903×391 48.5 KB

PS Gebruikte voorheen OpenWebStart die JAVA automatish uptodate hield maar die is kaput sinds op een bepaald moment iets niet meer gepurged kon worden wat opstarten blokkerde, dus zit sinds dien weer op de directe JOSM uitgave.

16

Ah.. ik gebruik de windows installer van JOSM; en begreep altijd dat daar Java niet in mee komt.
Hoe ik dit interpreteer, is dat JOSM is gebouwd met Java 21.0.8 JDK; maar dit staat los van de java die op je systeem draait.

Maar dat kan ik mis hebben natuurlijk :stuck_out_tongue:

17

Dat behoeft verder doorzoeken, naar die Java Azul Zulu (en dat Zulu komt me heel bekend voor
 dat zag ik in de TM als JOSM met OWS opgestart werd)

Wordt vervolgd.

Edit: Een grijs gebied
 er zijn installatie videos en allemaal op W11. Vond wel een 21.44.17 .msi bestand dus op de Azul site. Ga die uitproberen, voorzichtig want wil geen dependencies opblazen.

18

Als ik op Java 8 zou draaien, dan ‘zou’ de boel niet kunnen werken


image
image1113×204 6.66 KB

Bij de artificiële inseminatie afdeling weten ze te vertellen dat er een configuration tab in het About scherm moet zijn waar de java referenties staan
 is er niet, wel installation details met

image

Geen java home ingesteld, maar na zoeken werd beweerd dat deze niet ingesteld wordt.

De disk doorgezocht en de werkelijke java.exe versie gevonden met die ook in die Add Progams staat, ja 8.0.46, en toch weer een tweede installatie met 17.0.8.0, dus welke gebruikt JOSM nu met die ‘no home’ instelling?

Die 8.0.46 gedeinstalleerd en gekeken of JOSM nog wilde starten
 en dat gaat onverstoorbaar verder, ergo gebruikt blijkbaar 17. Die beide Java versies staan in subs van .\java\bin, nu dus alleen die 17.0.8. Ga die opgehaalde Azul Zulu 21.44 nog installeren en kijk wat dat oplevert.

Tot zover.

Edit: Dingen die ik allemaal niet wilde weten
 Zulu geinstalleerd zonder die 17.0.8 van het systeem te halen. Zag dat er een variabele bijgesteld werd en nu wijst het systeem dus naar die Zulu in het zoekpad, notabene als allereerste in een oneindig lange regel

image
image1854×168 3.78 KB

Dus nu testen of die Garbage Cleaner wel werkt.

Edit2: Nee, Java 8 eraf, Java17 eraf, Azul/Java 21.44 erop, maar met java-options=-XX:+UseParallelGC wil JOSM absoluut niets meer van zich laten zien. Heb er een apostrophe voorgezet in de .cfg met een comment erachter zodat ik weet waarom die regel uit staat.

Heel bedankt voor de hulp (en Firefox startte ook weer netjes op en de JOSM is nog nooit zo snel geladen als nu, maar veel sneller was het al sinds de Windows 10 Insider October preview installatie van 3e week September)

19

Interessant draadje op StackOverflow

waaruit

The parallel scavenge collector (Enabled using -XX:UseParallelGC). This is like the previous parallel copying collector, but the algorithm is tuned for gigabyte heaps (over 10GB) on multi-CPU machines. This collection algorithm is designed to maximize throughput while minimizing pauses. It has an optional adaptive tuning policy which will automatically resize heap spaces. If you use this collector, you can only use the the original mark-sweep collector in the old generation (i.e. the newer old generation concurrent collector cannot work with this young generation collector).

Mijn comp is single CPU, 8 thread,

20

I asked GPT5 to analyse the stackoverflow discussion; here is the outcome:

:brain: 1. Background: What These Flags Actually Do

Both flags relate to Java’s Garbage Collector (GC) — the part of the JVM that automatically frees up unused memory.
The names can be confusing because they come from older Java versions.

Flag Collector Type Targets Description
-XX:+UseParallelGC Parallel (Throughput) Collector Whole heap Multi-threaded GC designed for throughput, not low pause. Uses all cores in both “young” and “old” generations.
-XX:+UseParNewGC Parallel New Collector Young generation only Used with the Concurrent Mark Sweep (CMS) collector for old generation. It speeds up young-gen cleanup while CMS handles long-lived objects.

:gear: 2. Historical Context

  • In Java 8 and older, these were two distinct tunable choices.
    You could combine ParNew + CMS, or use the all-Parallel collector.
  • In Java 9+ (including your Java 21 LTS), the Parallel GC became the default and the old CMS (UseParNewGC) was deprecated and removed.

:backhand_index_pointing_right: Therefore:
:white_check_mark: -XX:+UseParallelGC is modern, supported, and default.
:warning: -XX:+UseParNewGC is obsolete and ignored in Java 14+ (will cause an “unrecognized VM option” or crash).

:puzzle_piece: 3. Why SekeRob’s JOSM Didn’t Start

SekeRob’s issue likely comes from one of the following:

  1. Older JRE — e.g. Java 8 or 11, where UseParallelGC interacts differently with CMS or adaptive policies.
  2. Manual GC tuning conflict — e.g. another -XX:+UseG1GC or similar flag already defined.
  3. JOSM launcher incompatibility — some builds wrap the JVM and reject unsupported flags.

In those cases, the JVM refuses to start with an “unrecognized VM option” or a GC mismatch error.

For your Java 21 Azul LTS build, UseParallelGC is supported and stable.

:balance_scale: 4. Comparing the Two (Technically)

Feature UseParallelGC UseParNewGC
Available in Java 21? :white_check_mark: Yes (default) :cross_mark: No (removed)
Optimized for large heaps (>10 GB) :white_check_mark: Yes :warning: No
Optimized for multi-core CPUs :white_check_mark: Yes :white_check_mark: Yes (but old CMS)
Pause behavior Slightly longer pauses, higher throughput Shorter pauses, but lower throughput
Best for Batch workloads, heavy rendering, large imagery (JOSM fits) Latency-sensitive servers
Stability Very high Deprecated, unsupported
Adaptive tuning Works with -XX:+UseAdaptiveSizePolicy Not compatible

:puzzle_piece: 5. For Your Machine

You’re on:

  • Windows 11 64-bit
  • Java 21.0.8 Azul (LTS)
  • 12 GB RAM, multi-core CPU (≄8 threads)

:white_check_mark: The Parallel GC is exactly tuned for this setup.
It will use all cores for cleaning, minimize total pause time, and work well with your 4 GB heap.
Your tasks (rendering imagery, processing large OSM data) benefit from throughput more than ultra-low latency.

So:

-XX:+UseParallelGC
-XX:+UseAdaptiveSizePolicy

is the best combination.

:puzzle_piece: 6. For SekeRob (Single CPU / 8 Threads)

For a single physical CPU (8 logical threads via Hyper-Threading), the Parallel GC may not show much benefit, and sometimes even slower startup due to thread overhead.

In that case, a lighter GC like G1GC can be better.

:white_check_mark: Recommended alternative for him:

-XX:+UseG1GC

This is Java’s current “general-purpose” GC — lower pauses, adaptive, and safe across all JVMs since Java 11.

:compass: 7. Recommendation Summary

Use Case Java Version Recommended GC Notes
Modern (Java 17–21), multi-core, large imagery work (you) :white_check_mark: -XX:+UseParallelGC -XX:+UseAdaptiveSizePolicy Best throughput
Older Java (8–11) or single-core setups (SekeRob) :gear: -XX:+UseG1GC More balanced, safer
Low-latency or background editing (light maps) :gear: -XX:+UseG1GC Slightly lower total throughput, smoother UI
Legacy (CMS-based) :cross_mark: -XX:+UseParNewGC Deprecated, avoid