Time Out beim Download mit JOSM

Hier (Windows7, Provider: Telekom) keine Timeouts.

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 :slight_smile:

Moin,

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.

Steht auf Standardeinstellungen, bisher hatte ich noch nicht allzuintensiv nach deutschsprachiger Doku gesucht.

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).

Franz

Hallo,

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.

Gruß
Gino

Ich habe bei openstreetmap.org allerdings auch ständig Timeouts bzw. sehr lange Antwortzeiten.

Ich habe in den letzten Wochen auch sehr oft Timeouts beim Herunterladen von Daten. JOSM 9965 (oder Vorversionen) unter Ubuntu Linux

Gestern gab es unter Ubuntu 14.04 ein neues update.

gir1.2-webkit-3.0_2.4.10-0ubuntu0.14.04.1_amd64.deb

Ich hatte bis jetzt keinen Time Out mehr. Ich werde das mal weiter beobachten.

Aber gir hat doch nichts mit JOSM zu tun.

Hallo,

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.

Scheint bei mir auch das Problem gewesen zu sein. Läuft jetzt wieder deutlich flüssiger. Danke!

–ks

Vielen Dank, Jojo4u!!

Damit ist der Spaß an JOSM und OSM-Tagging wieder zurückgekehrt.

Gruß
Gino

Gibts eine Erklärung dafür? Weil zB. die IPv6-fähigen Server schwächer sind, oder zu wenige? So grundsätzlich gehen ja API-Abfragen auch mit IPv6, nur halt manchmal nicht und eigentlich muss man sich über jeden freuen, der das unterstütz, statt das auszuschalten…

Grüße
Max

Wireshark zeigt an dass Pakete rausgehen aber nichts zurückommt. Auch die ganzen Vorlagen laden in JOSM ja ohne Probleme. Beim Neustart meines Browser mit vielen angepinnten Seiten kommt 40% IPv6 raus. Daher sieht es eher nach einem OSM-Problem aus als nach Router/Provider.

Nun hat’s mich auch erwischt, vor ner Stunde gings noch, jetzt nur noch “Read Timed Out”.

Ja, etwa seit einer halben Stunde geht’s entweder gar nicht oder sehr langsam. Gleiches Problem wie schon heute Nachmittag.
(Edit: kaum nörgele ich, geht’s wieder einigermaßen)