seit einigen Tagen bekomme ich oft einen Timeout, wenn ich Daten in JOSM runterladen will.
Nach einigen Versuchen geht es dann wieder - aber es nervt ungemein.
Ich habe JOSM V9329
und Standard OSM Server URL verwenden eingestellt.
nein, das ist nicht dein persönliches Schicksal.
Ich habe seit ~ 2 Wochen das gleiche Problem und nach Lösungen gesucht, aber bisher erfolglos.
Habe schon die latest Josm-version versucht.
JOSM/1.5 (9881 de) Linux Ubuntu 14.04.4 LTS
Java version: 1.8.0_72-b15, Oracle Corporation, Java HotSpot™ 64-Bit Server VM
Identification: JOSM/1.5 (9900 de) Windows 10 64-Bit
Memory Usage: 703 MB / 910 MB (279 MB allocated, but free)
Java version: 1.8.0_71-b15, Oracle Corporation, Java HotSpot™ 64-Bit Server VM
continuosDownload
ADSL 50Mbit
Seit einigen Tagen dauert das Herunterladen von Daten viel länger als vorher, egal ob via Link/Remote, über Herunterladen oder beim Zoomen bzw. Verschieben des Ausschnitts.
Manchmal gibt es dann die Meldung
Der OSM-Server "api.openstreetmap.org" meldet eine fehlerhafte Anfrage.
Der angeforderte Bereich ist zu groß oder enthält zu viele Daten.
Gelegentlich hängt JOSM dann so, dass man nur noch den Prozess killen kann. Aber nicht erst seit dem Versionsupdate.
Also ich nutze Ubuntu 14.04.4, OpenJDK 1.7, über die offiziellen API Urls (kein Mirror) mit einer 16.000er Leitung und habe keine derartigen* Probleme
java version "1.7.0_95"
OpenJDK Runtime Environment (IcedTea 2.6.4) (7u95-2.6.4-0ubuntu0.14.04.1)
OpenJDK 64-Bit Server VM (build 24.95-b01, mixed mode)
Als ich JOSM das erste Mal mit 9900 gestartet habe, habe ich beim Start von JOSM, wenn es die Releaseinfoseite lädt einen Timeout zu josm.openstreetmap.de bekommen
hast Du Dich mal mit den Einstellungen des continuosDownload-Plugins beschäftigt?
Das continuosDownload-Plugin versucht halt, bei jedem Zoom die Daten des sichtbaren Bereichs nachzuladen - wenn man da nicht vorsichtig genug ist, ist die Fehlermeldung und das Verhalten kein Wunder.
Mir ist bei der JOSM-Version 9900 aufgefallen, dass das Hinein- und Herauszoomen schneller geht, als in den älteren Versionen - sich bei einer Stufe des Mausrades (Windows-Rechner) der Maßstabsbalken oben links um den Faktor 2 ändert und nicht um 1.4, wie bei den älteren Versionen. Das kann dazu führen, dass man bei gleicher Anzahl an Stufen wie früher beim herauszoomen doppelt so schnell an die Grenze kommt, bei der der Server die Herausgabe dieser zu großen Fläche verweigert.
Einstellen kann man die Anzahl an Mausrad-Stufen für einen Zoon um den Faktor 2 in den Anzeige-Einstellungen (F12, 1. Icon, 4. Reiter “Verhalten und Aussehen”. Dort kann man gleich unterhalb der Kästchen mit einigen Haken rechts von der Zeile “Vergrößerungsschritte um den doppelten Maßstab zu erhalten” mit den Auf/Ab-Pfeilen einen Wert Wählen. Dieser könnte durch die JOSM-Version 9900 als Default auf 1 gestellt worden sein (= Faktor 2 je Mausradstufe), wäre aber beim Verhalten der älteren JOSM Versionen auf 2 (= Faktor 1.4).
im Moment bin ich wieder völlig genervt.
dauernd bekomme ich diesen Timeout. Das war letztes Jahr nicht.
Also muss es doch einen Grund haben.
Hat den da niemand eine Idee.
Das angesprochene Plugin verwende ich nicht.
Grenzt meines Erachtens auch an Selbstmord, wenn bei jedem Zoom Daten herunter geladen werden.
habe häufig viele nicht heruntergeladene Kacheln seit ein paar Tagen. Insbesondere beim rein- und rauszoomen. Mittlerweile hilft nicht mal mehr der Menüpunkt “Fehlerkacheln nachladen”. Änderungen hochladen geht trotzdem.
Win 8.1
Java 1.8.0_73
JOSM 9979
Thoschi
12:00 → Problem behoben, hatte nicht gesehen, dass beim Update die Funktion “Kacheln automatisch nachladen” ausgeschaltet wurde.
So wie aussieht, ist der Time Out doch nur unter Ubuntu aufgetreten, unter Windows waren das ganz andere Probleme, wie etwa “Hinein- und Herauszoomen”, “continuosDownload”, oder ähnliches.
Vielleicht hat “gir1.2-webkit-3.0_2.4.10” irgend etwas mit der Internetverbindung zu tun, die unter JOSM oder auch Java nicht so gut lief. Ist halt eine Vermutung von mir, da es seit dem Update bis jetzt ohne große Probleme läuft.
Bei mir lag’s an der standardmäßigen Bevorzugung von ipv6. In den erweiterten Optionen habe ich prefer.ipv6=false gesetzt. Arch Linux, JRE 8u77, JOSM 10150, Unitymedia.
