JOSM unter OpenSuse 15.1 - Problem beim Runterladen von Daten

Ich kann beim Runterladen nicht beliebig raus-zoomen, der Ausschnitt zeigt horizontal maximal etwa 20-25 km

Kartendaten vom Server runterladen → OSM Daten laden - > interaktive Karte → OpenStreetMap Carto

Mit Luftbildern statt OpenStreetMap Carto geht es gut.

Kennt jemand das Problem?

Gruß
Toni

JOSM Version 15937 (neueste)

Java von Oracle
java version “1.8.0_241”
Java™ SE Runtime Environment (build 1.8.0_241-b07)
Java HotSpot™ 64-Bit Server VM (build 25.241-b07, mixed mode)

LIBXCB_ALLOW_SLOPPY_LOCK=1 java -Xms64M -Xmx2048M -XX:+UseParallelGC -XX:+UseAdaptiveSizePolicy -jar $HOME/bin/josm-latest.jar “$@”

osm carto sagst du? Dann https://forum.openstreetmap.org/viewtopic.php?id=68575

Was anderes: Relationsliste, irgendwas auswählen (z.B. Busrouten) Kontextmenü, “Download incomplete members”: Das hängt bei mir manchmal. (openSUSE 15.1/openjdk 11.0.6/josm 15915) Mehr oder minder verständlich, da das ja mehrere HTTP-Anfragen nach sich zieht, und da würde mich es nicht wundern, wenn irgendwo eine dumme Ratelimiting-Firewall mir den Tag zunicht macht. Pauschal gebe ich da erstmal dem vom ISP bereitgestellten CPE/Drecksrouter die Schuld, denn mit einer VPN-Verbindung klappt es.

Mmh, den Thread kenne ich, und ich hatte früher auch mal graue Kacheln in JOSM.

Hier liegt das Problem wohl woanders. Ich kann mit dem Mausrad scrollen soviel ich will, es geht einfach nicht weiter raus als die sichtbaren 20-25 km (links nach rechts) im Downloadfenster. Mit OSM unter Windows auf 'nem anderen Rechner geht’s problemlos.

Ich habe allerdings vor Kurzem von openjdk 11.0.6 auf Oracles Java™ SE Runtime Environment (build 1.8.0_241-b07) umgestellt. Glaube aber nicht, dass das damit zusammenhängt.

Ich habe allerdings noch ein anderes Problem, das bei allen Java -Programmen zuschlägt. Sie hängen beim Start manchmal 10-20 Sekunden.
JOSM hängt zudem häufig beim Schließen des Editfensters (Editierebene löschen).

Falls Du einen hochauflösenden Monitor hast, dann könnte es an der Java Version 1.8 liegen.

Die Version gibt es seit gestern … ist es seitdem? (Das Installationsdatum bekommt man mit “rpm -qi josm”)

Die neueste stabile Version ist aber 15927. Das hat mich gestern schon gewundert als bei mir die 15937 ankam…

Auf jeden Fall gibt es eine sonderbare Tempo-Abhängigkeit. In der Spec-Datei des Quell-RPMs steht

# JOSM requires only Java 8, but it is slow below java 11 on openSUSE
Requires:       java >= 11

Gestern war die neueste stabile Version 15927. Die tat/tut bei mir überhaupt nicht (Windows10, Oracle Java 8-241, Ubuntu 18.x, OpenJDK 11.x)
Heute wurde wohl josm-latest15937.jar zu josm-tested15937.jar, die bisher ohne Probleme läuft.

Na, eigentlich nicht 1980 * 1080 (oder so).

Nein, ich hatte die neuste Version (wie immer) händisch von josm.openstreeetmap.de runtergeladen - in der Annahme ich würde gefragt werden, ob es mit der neuesten Version immer noch auftritt :wink:

Also von Java 8 (von Oracle) zurück auf Java 11 (OpenJDK)?

Ich hab mit OpenJDK auch schon probleme gehabt… hab des jetzt so gelöst:

Von Oracle neues Java als tar.gz geholt, ausgepackt, und mit Skript… ./path/to/java -jar josm.jar :wink: ist zwar nicht toll aber funktioniert :sunglasses:

Nö, wollte ich damit nicht sagen. Aber wenn die bei Suse einen so erheblichen Zusammenhang zwischen der Java-Version und dem Tempo festgestellt haben, dann würde ich erstmal sagen “Die Java-Version ist nicht egal”. Vielleicht ist

also doch nicht so sicher …

na ja, so ohne Grund habe ich den Wechsel nicht gemacht.

Ich habe mal ‘strace’ genutzt und sehe beim Start von JOSM, dass der (sehr häufig) bei einem “futex(… FUTEX_WAIT, …)” hängt (2-20 Sekunden).

Ich nehme mal an, dass JOSM beim Schließen des Editierfensters und beim Beenden ebefalls am ‘futex’ hängt.

Ich habe auch mal /dev/random auf /dev/urandom umgebogen, kann aber keinen nachhaltigen Unterschied feststellen.
Wie erwähnt trifft das aber nicht nur auf JOSM zu, sondern auch auf andere Java-Programme.

Mein eigentliches Problem bleibt: im Downloadfenster kann ich nicht sehr weit raus-zoomen.

Beide Probleme existieren auch mit OpenJDK.

Das Warten beim “futex” ist praktisch immer OK. Es bedeutet in etwa “Warte bis ein anderer Prozess die Angelegenheit XY als erledigt meldet”. Das Problem liegt fast immer bei dem anderen (meldenden) Prozess. Mit dem Parameter “-f” beim strace bekommt man auch noch alle direkt oder indirekt gestarteten Tochter-Prozesse zu sehen. (Das wird aber ganz schnell sehr unübersichtlich.)

Danke, hab’s mal ausprobiert und es hat einige Versuche gebraucht, bis es auftrat.
Was komisch ist: PID war bei futex_wait_private und futex_wake_private immer die selbe

Es spielte sich (das eine Mal) ziemlich am Anfang ab: Socket einrichten, Resolver (DNS) abfragen, …

Tritt nicht mehr auf wenn ich JOSM “from scratch”, d.h. ohne config-Informationen aufrufe.

Liegt also womöglich an meinen preferences.xml, …?

Aber die (preferences.xml) mag ich nicht aufgeben.

Du kannst ja mal versuchen, nur die plugins wegzulassen.

java -jar josm-tested.jar --skip-plugins

Bei mir sind in 15.1 mit JOSM 15937 und openjdk 11.0.6 noch keine derartigen Probleme aufgetreten. Man kann beliebig rein und raus zoomen. An den preferences.xml habe ich allerdings auch noch nie manuelle Änderungen vorgenommen, ich arbeite vermutlich weitgehend mit Standard-Einstellungen. Die wenigen plugins, die ich nutze, scheinen ebenfalls nicht zu stören.

Danke für Eure Mühen und Vorschläge - hat alles nicht gefruchtet.

Ich hab’s einfach mal von scratch neu gemacht und die wenigen Änderungen (kein Gummiband, …) waren schnell eingetragen.

Vielleicht kannst Du ein JOSM Ticket aufmachen und die beiden preference.xml Varianten dranhängen? Sofern es wirklich nur davon abhängt…

Yep, ich habe mal die alte preferences.xml durch die neue ausgetauscht - und weg ist das Problem.

Werde dann mal ein Ticket aufmachen, danke für den Vorschlag.