JOSM: kann keine Änderungen mehr hochladen!?

koppenho · 2010-12-20T12:38:01.000Z

Hallo *,

gestern habe ich im Verlauf des Tages mehrfach Änderungen mit JOSM zum OSM-Server hochgeladen.
Doch meine letzte Änderung von kurz vor Mitternacht… die werde ich nicht mehr los. Egal, wie oft ich es starte, ich schaffe es einfach nicht mehr die Änderungen hochzuladen.
Alles was ankommt sieht so aus:
Changeset 6715385
(nach jedem Hochladeversuch gibt’s eine neue Changset-Nummer).

Während das Changeset schon in dieser minimalen Form abrufbar ist, sagt mir JOSM:
58 Objekte hochladen…
Änderungsatz 6.715.385 erfolgreich geöffnet.

Nach langer Wartezeit sagt JOSM dann etwas von Versuch 2 von 5. Vor Versuch 3 von 5 fragt JOSM ob ich weiter die Änderungen hochladen will.

Was nun? Ich bin etwas ratlos.
Weiss jemand, woran das liegen könnte?

JOSM 3701 und 3732 machen da keinen Unterschied.

An meinem Proxy-Server scheint es nicht zu liegen, denn schließlich kommt ja eine Verbindung zustande (siehe Changeset 6715385
).

Windows Vista habe ich schon mehrfach neu gestartet. Das ist’s wohl auch nicht.

Mein Useraccount koppenho scheint auch in Ordnung - keine Sperre sichtbar.

Etwas irritiert mich im Changeset 6715385 die Angabe “Für dieses Changeset wurde kein Bereich gespeichert.”.
Ist das der Fehler? Wenn Ja, wodurch kann so etwas ausgelöst werden und wie behebe ich das Problem?

Kann das an meinen Änderungen liegen? 58 Objekte, aus meiner Sicht nichts ungewöhliches dabei.

Bin für jeden Tipp dankbar,

Andreas

SunCobalt · 2010-12-20T13:19:56.000Z

das hatte ich in den letzten Tagen auch einige Male. Nach ein wenig warten gings dann wieder. Du kannst JOSM mal über die Kommandozeile starten. Dann siehst Du ein wenig mehr von den Dingen, die da passieren oder auch nicht…inkl Fehlermeldungen bei Verbindungsabbrüchen

mdk · 2010-12-20T13:50:16.000Z

Ja, ist zur Zeit etwas ekelig. Aber man sollte immer schauen, ob das Changeset nicht doch auf dem Server gelandet ist. In letzter Zeit häufen sich doppelte/mehrfache uploads.
Ich habe beim Aufräumen (OSM Inspector - Routing - dublicate ways) einen Path mit über 250 Nodes gefunden, der unglaubliche 17(!) mal identisch hochgeladen wurde…

Grüsse

mdk

trekki · 2010-12-20T14:03:36.000Z

Gibt es für unterschiedliche Gebiete unterschiedliche Server? Ich habe selbst diese langen Übertragungszeiten bisher nur bei deutschen Daten gesehen. Insbesondere Dänemark wird in sehr akzeptabler Geschwindigkeit gespeichert.
-trekki

SunCobalt · 2010-12-20T14:25:43.000Z

ich kann auch gerade ein Changeset nicht hochladen

aighes · 2010-12-20T14:31:36.000Z

Bei mir läufts…aber ich mach jetzt mal Kaffeepause… also nur zu…

Es gibt nur 2 Server, die die API stemmen, wie die sichd ie Arbeit aufteilen weiß ich allerdings nicht, ich vermute mal, dass das nach Last geht.

EvanE · 2010-12-20T15:01:25.000Z

koppenho:

…

Etwas irritiert mich im Changeset 6715385 die Angabe “Für dieses Changeset wurde kein Bereich gespeichert.”.
Ist das der Fehler? Wenn Ja, wodurch kann so etwas ausgelöst werden und wie behebe ich das Problem?

Kann das an meinen Änderungen liegen? 58 Objekte, aus meiner Sicht nichts ungewöhliches dabei.

Hallo Andreas

Das passiert wenn ein Changeset geöffnet wird, jedoch keine Daten hochgeladen wurden.
Dann gibt es nichts anhand dessen man einen Bereich identifizieren könnte.

Sicher nicht das was du wolltest, aber wenn ein Upload nicht ging, durchaus normal.

Edbert (EvanE)

koppenho · 2010-12-20T15:48:18.000Z

Inzwischen konnte ich feststellen, dass meine Upload-Probleme von meinen Änderungen verursacht werden.
Wie das sein kann, konnte ich nicht ermitteln.
Einige haben mir berichtet, dass das an Objekten liegen könne, die in einer sehr großen Relation stecken. Der OSM-Server würde dafür z.T. sehr lange benötigen.
Das trifft hier nicht zu.
Ich habe eine einzelne modifizierte Node selektiert und “Datei->Auswahl hochladen” gestartet.
Das funktionierte für viele Nodes nicht. Warum ist mir rätselhaft.

Ich gebe an dieser Stelle auf. Ist mir zu zeitintensiv.
Mein Workaround sieht so aus:

reverter plugin installieren und die bereits hochgeladenen Teile zurücksetzen. Betrifft 4 Changesets bei denen tatsächlich etwas hochgeladen wurde. 2 davon kann ich lassen. Muss also nur 2 zurücksetzen.

alle Änderungen wegwerfen und nochmal anfangen.

Schrittweise heranpirschen: jede kleine Änderung sofort hochladen in der Hoffnung, dass ich so die Ursache besser erkennen kann.

Dank an alle, die mir Tipps gegeben haben.

EvanE · 2010-12-20T16:05:40.000Z

koppenho:

…
Mein Workaround sieht so aus:

…

Schrittweise heranpirschen: jede kleine Änderung sofort hochladen in der Hoffnung, dass ich so die Ursache besser erkennen kann.

Dank an alle, die mir Tipps gegeben haben.

Noch ein kleiner vielleicht unwichtiger Tipp:
Du kannst bei JOSM einstellen, ob er das Changeset noch dem Upload schliessen soll (also für jede Änderung ein eigenes Changeset erstellen soll) oder ob das Changeset geöffnet bleiben soll (also weitere Uploads in das gleiche Changeset gehen).

Letzteres mach Sinn, wenn die Änderungen im Grunde zusammen gehören.
Wie auch immer, es ist deine Sache wie du das handhabst.

Edbert (EvanE)

koppenho · 2010-12-20T16:12:51.000Z

EvanE:

Du kannst bei JOSM einstellen, ob er das Changeset noch dem Upload schliessen soll (also für jede Änderung ein eigenes Changeset erstellen soll) oder ob das Changeset geöffnet bleiben soll (also weitere Uploads in das gleiche Changeset gehen).

Letzteres mach Sinn, wenn die Änderungen im Grunde zusammen gehören.

Danke für den Tipp - werde ich ausprobieren.
Ich hatte bisher noch nicht verstanden, weshalb man überhaupt ein Changeset offen lassen soll… aber jetzt ist der Groschen gefallen.

Dieses Vorgehen erscheint mir sehr sinnvoll für größere Änderungen…

koppenho · 2010-12-20T20:52:48.000Z

koppenho:

EvanE:

Du kannst bei JOSM einstellen, ob er das Changeset noch dem Upload schliessen soll (also für jede Änderung ein eigenes Changeset erstellen soll) oder ob das Changeset geöffnet bleiben soll (also weitere Uploads in das gleiche Changeset gehen).

Letzteres mach Sinn, wenn die Änderungen im Grunde zusammen gehören.

Danke für den Tipp - werde ich ausprobieren.

Hat leider nicht funktioniert.
Die Ursache, weshalb ich keine Änderungen mehr hochladen kann, liegt an folgenden Nodes:
http://www.openstreetmap.org/browse/node/1013462815
http://www.openstreetmap.org/browse/node/1013462707
http://www.openstreetmap.org/browse/node/1013462778
http://www.openstreetmap.org/browse/node/1013462615
http://www.openstreetmap.org/browse/node/1013462735

Sie gehörten zu einer geschlossenen Fläche, die das Gebäude der Sparkasse darstellen sollte.
Wegen der schon berichteten Probleme mit den oben genannten nodes konnte ich die Erfassung des Gebäudes nicht korrigieren/verbessern. Änderungen an den nodes waren mir nicht möglich.

Daher habe ich beschlossen den dazugehörigen way
http://www.openstreetmap.org/browse/way/87158717
und alle seine Punkte zu löschen. Damit hatte ich leider nur einen Teilerfolg.
Mit den letzten 5 Punkten komme ich nicht weiter.

Was ist mit diesen nodes nur los?
Wie schafft man es “immutable nodes” zu setzen?
Weshalb kann ich diese Biester nicht löschen oder ändern (weder mit JOSM noch mit Potlatch)?
Datenbankfehler?

In der Mailingliste de-talk habe ich gefragt, ob jemand diese nodes für mich löschen kann.

SunCobalt · 2010-12-20T21:11:45.000Z

witzig. Ich kriege die auch nicht weg. Wenn Du es weißt, sagst Du dann woran es lag? Das interessiert mich auch

aighes · 2010-12-20T21:21:39.000Z

In der Tat…Potlatch löscht auch nicht…

BBO · 2010-12-20T21:23:17.000Z

Ich hatte auch keinen Erfolg…

koppenho · 2010-12-20T22:01:26.000Z

SunCobalt:

Wenn Du es weißt, sagst Du dann woran es lag? Das interessiert mich auch

Klar, mach’ ich.
Vorher muss ich aber noch jemand finden, der das Problem analysieren kann…

kellerma · 2010-12-20T22:45:29.000Z

Hi,

hab’ 2 gelöscht, die anderen nkbre & daswaldhorn.

Ciao,
Frank

EvanE · 2010-12-20T22:48:53.000Z

koppenho:

SunCobalt:

Wenn Du es weißt, sagst Du dann woran es lag? Das interessiert mich auch

Klar, mach’ ich.
Vorher muss ich aber noch jemand finden, der das Problem analysieren kann…

Nu sind sie weg.

Potlatch2 sagte:

Version mismatch
Version 1 soll gelöscht werden, Version 2 existiert aber bereits
Try to delete already deleted objekt (mehrfach)

Es bleibt seltsam. Aber wenigstens sind sie weg.

Edbert (EvanE)

kellerma · 2010-12-20T23:41:42.000Z

aighes:

Es gibt nur 2 Server, die die API stemmen, wie die sichd ie Arbeit aufteilen weiß ich allerdings nicht, ich vermute mal, dass das nach Last geht.

Mmh, puff+fuchur; schaut eher wie einfaches Round Robin DNS aus:

nslookup api.openstreetmap.org

Name: api.openstreetmap.org
Addresses: 128.40.168.105, 128.40.168.98

Ciao,
Frank

BBO · 2010-12-21T07:15:44.000Z

Die Lösung aus der ML:

Das war ein Bug im Backend. Da bleiben manchmal - sehr selten und unter
bislang ungeklaerten Umstaenden - Diff-Uploads haengen und blockieren
sich gegenseitig. Man sieht das an diesem Bild ganz gut:

http://munin.openstreetmap.org/openstreetmap/smaug.openstreetmap/postgres_locks_openstreetmap.html

Wenn so ein Request erstmal haengt, gibt er die Transaktions-Locks in
der Datenbank nicht frei, und alles, was eines von den in der
Transaktion veraenderten Objekten anfasst, bleibt dann auch ewig haengen
(und beansprucht zusaetzliche Locks - das ist der Berg auf dem Bild).

Wie man ebenfalls an dem Bild sieht, passiert das bloss alle paar Monate
mal. Aber wenn es passiert, dann muss ein Admin der Kiste einen Tritt
geben - wie jetzt gerade auf meine Nachfrage hin geschehen. Und
schwupps, waren die Nodes auch schon weg.

Bevor jemand aber jetzt in der Zukunft bei jedem Upload, der mal etwas
laenger dauert, so ein Lock-Problem vermutet - immer erst mal auf diese
Munin-Grafik schauen, bevor man Alarm schreit

Bye
Frederik

kellerma · 2010-12-21T09:42:09.000Z

Naja, die Buerde, die RRD-Graphen der locks der Datenbak zu beobachten, kann man kaum den mapper “von der Strasse” auferlegen.
Dies ist klar eine Aufgabe fuer Serveradmins. …

Ciao,
Frank