JOSM: Connection Timeout bei Upload

Also als erstes würde ich mal deine Internetverbindung prüfen. WLAN UMTS etc. all das sind mögliche Störfaktoren.
Prüfen was hochgeladen ist kannst du eigentlich nicht. du kannst aber die runtergeladenen Daten aktualisieren. dann weist du wenigstens was oben ist. Doppelungen lassen sich so aber wahrscheinlich nicht vermeiden.

Die Internetanbindung ist durchgängig verkabelt, ich kann aber nicht prüfen, ob es zu der Zeit einen Ausfall gab.

Beim Aktualisieren der Daten erhielt ich die Fehlermeldung "In diesem Gebiet wurden keine Daten gefunden" - heisst das "nicht neues"?
Wenn bei den Daten jetzt was fehlt ist es nicht furchtbar schlimm - viel war es eh nicht.

Ich vermute, dass die falsche Zeitangabe im Changeset etwas damit zu tun hat, aber was?

Nachtrag: Ich glaube, dass Changeset ist vollständig - es ist also nichts verloren gegangen. Ich vermute allerdings, dass das Problem wieder auftreten würde, da ich eben auch wieder mit anderen Abfragen (z.B. Versionsgeschichte aufrufen, Objekt herunterladen) die Fehlermeldung "Connection timeout" erhalten habe, und dann möglicherweise nicht alles übertragen wird.

mfg~ray

Hatte gestern nachmittag auch ein paat time-outs beim hochladen mit JOSM, etwas später gings dann.

Von heute:

Laut "Platform Status" ist die API derzeit nur sporadisch erreichbar (Ursache wird aber nicht genannt - es haben wohl nur auch andere Nutzer solche Probleme beobachtet).

Mir ist eben wieder ein Änderungssatz "hängengeblieben", diesmal bei "Postprocessing uploaded data". Wie sich aus dem Text vermuten lässt, sind alle Objekte angekommen, aber JOSM mochte sich nicht normal beenden lassen. Da es wieder so ist, dass die Zeit unter "created_at" eine Stunde früher als tatsächlich ist und es bei "closed_at" stimmt, vermute ich, dass da ein Zusammenhang besteht. Bei vorherigen Änderungssätzen gab es keine Probleme, auch wenn es länger als eine Minute dauerte. Bei diesen sind die Zeitangaben ebenfalls um eine Stunde verschoben.
Können noch andere, die das Problem hatten verschobene Zeitangaben in den betroffenen Changesets feststellen?

rayquaza wrote:

Da es wieder so ist, dass die Zeit unter "created_at" eine Stunde früher als tatsächlich ist und es bei "closed_at" stimmt, vermute ich, dass da ein Zusammenhang besteht. Bei vorherigen Änderungssätzen gab es keine Probleme, auch wenn es länger als eine Minute dauerte. Bei diesen sind die Zeitangaben ebenfalls um eine Stunde verschoben.

Das ist kein Fehler. Der Server speichert Zeitangaben in UTC, vulgo MEZ-1. Änderungssätze werden eine Stunde nach dem letzten Befehl geschlossen; diese (in der Zukunft liegende) Schließungszeit wird vorgemerkt und mit jedem Befehl aktualisiert.

Bei Upload-Problemen solltest Du mal versuchen, Deine Änderungssätze in Paketen von <=100 Objekten hochzuladen statt in einem Stück. Das ist generell eine sinnvolle Einstellung.

Oli-Wan wrote:

Änderungssätze werden eine Stunde nach dem letzten Befehl geschlossen; diese (in der Zukunft liegende) Schließungszeit wird vorgemerkt und mit jedem Befehl aktualisiert.

Wenn ich die API nach meinen Changesets frage, wenn noch einer offen ist (=während des hochladens), erhalte ich für diesen Änderungssatz aber z.B.

<changeset␣id="14329510"␣user="rayquaza"␣uid="351324"␣created_at="2012-12-19T11:04:23Z"␣open="true">

statt

<changeset␣id="14319435"␣user="rayquaza"␣uid="351324"␣created_at="2012-12-18T14:55:01Z"␣closed_at="2012-12-18T14:55:21Z"␣open="false"␣min_lat="49.4040657"␣min_lon="8.6499149"␣max_lat="49.4100446"␣max_lon="8.6859832">

wenn alles gut geht oder

<changeset␣id="14320516"␣user="rayquaza"␣uid="351324"␣created_at="2012-12-18T16:39:43Z"␣closed_at="2012-12-18T17:40:31Z"␣open="false"␣min_lat="49.3629128"␣min_lon="8.6784539"␣max_lat="49.4056483"␣max_lon="8.6933039">

bei einem Fehler. Letztere Zeile stand bereits um etwa 16:40:30UTC - also zu früh - dort.

mfg~ray