Upload in JOSM bricht mit Fehlermeldung ab

Eberth · 2010-06-01T18:48:48.000Z

Bei einer Mapping-Aktion am vergangenen Wochenende hat ein Teilnehmer erfolglos versucht, in JOSM seine Daten hochzuladen. Der Upload-Vorgang bricht stets mit einer unverständlichen Fehlermeldung ab.
Ich habe die gezippte OSM-Datei (Untershausen.zip) unter http://openstreetmap.homepage.t-online.de/ zum Download bereitgestellt. Vielleicht findet jemand den Fehler in der Datei oder eine Möglichkeit, sie in die OSM-Datenbank hochzuladen. Wir sind für jeden Tipp dankbar.

Thomas

SunCobalt · 2010-06-01T18:55:36.000Z

Das hatte ich letzte Woche auch ab und zu. Da ich nicht wusste wie ich damit umgehen soll, habe ich es nochmal hochgeladen. Bei mir schien es so, als wenn nur der Änderungssatz nicht geschlossen wurde. Da hatte ich dann viel Spaß DupNodes und DupWay wieder zu löschen Ich dachte, das liegt an meiner Internetverbindung

Nightdive · 2010-06-01T19:41:06.000Z

Und wie lautet die Fehlermeldung ?
Es ist immer extrem nervig wenn Leute Fehler berichten aber nicht welchen Fehler.
Ich verstehe nicht wieso man solch wichtige Informationen weglässt.

chris66 · 2010-06-01T20:35:57.000Z

Also ich finde das die existierenden Serverdaten sauberer sind als die Daten in der OSM Datei.

Da gibt’s übereinanderliegende Wege, zickzack Grenzen etc.

Verbesserungsvorschlage:

das amenity=barbecue_place eventuell besser als tourism=picnic_site mappen.

Den Feldweg (track) von Unterhausen zum Parkplatz Grillhütte/Jugendhaus eventuell
als service oder unclassified mappen, sonst ist ja kein Routing dorthin möglich.

Chris

Ebbe73 · 2010-06-01T21:23:11.000Z

SunCobalt:

Das hatte ich letzte Woche auch ab und zu.

Ich auch, in den letzten zwei Wochen. Es fängt an bei sehr langen Download-Zeiten und -Hängern, sowohl beim Download von OSM-Daten als auch GPS-Rohdaten, und geht weiter bei extremen Upload-Zeiten, selbst bei Änderungen an nur zwei Punkten. Weiterhin kam es beim Beginn von Uploads einmal zu Benutzer-Authentifizierungsfehlern und mehrfach zu anderen Fehlermeldungen mit Bezug auf fehlerhafte, unvollständige oder unzureichende Antworten vom Server. Aber auch Sachen wie History-Abrufe z.B. aus dem Web-Browser schlugen (schlagen??) mal fehl und klappten (klappen??) in unveränderter Form und Größe kurze Zeit später wieder, wie auch vorher genanntes.

Daher ging/gehe ich von einer Überlastung der “verantwortlichen” OSM-Server aus, insbesondere weil Woodpeck/Frederik ja auch Probleme mit missbräuchlichen skriptbasierten Server-Massendownloads erwähnt hatte.

SunCobalt:

Bei mir schien es so, als wenn nur der Änderungssatz nicht geschlossen wurde. Da hatte ich dann viel Spaß DupNodes und DupWay wieder zu löschen.

Darauf bin ich zuerst auch mehrfach “hereingefallen” und hatte “Extra-Spaß”. Anscheinend ist der Upload wirklich schon lange abgeschlossen und nur das Schließen des Änderungssatzes verzögert sich “ewig” bis hin zu schätzungsweise 10 Minuten. Inzwischen zwinge ich mich zum Warten.

ajoessen · 2010-06-02T06:41:56.000Z

Ebbe73:

Darauf bin ich zuerst auch mehrfach “hereingefallen” und hatte “Extra-Spaß”. Anscheinend ist der Upload wirklich schon lange abgeschlossen und nur das Schließen des Änderungssatzes verzögert sich “ewig” bis hin zu schätzungsweise 10 Minuten. Inzwischen zwinge ich mich zum Warten.

Nach spätestens einer Stunde wird der Änderungsdatensatz serverseitig geschlossen. Man kann das Schliessen eigener Änderungssätze aber auch in Josm erzwingen (Datei/Offene Änderungssätze schliessen).

Wenn man viel geändert hat, kann man sicherheitshalber erst mal ne lokale Kopie erstellen, einen Filter modified anlegen mit Haken im ersten, zweiten und vierten Ankreuzfeld. Dann sieht man nur noch, was man geändert hat. Anschließend einen Teilbereich im Rechteck markieren und Datei/Auswahl hochladen.

Wenn alle Stricke reißen, kann man immer noch mit Datei/Daten aktualisieren einen Abgleich mit dem Server anstoßen.

Gruß,
ajoessen

Eberth · 2010-06-02T11:43:42.000Z

Vielen Dank für alle Antworten und Hilfen.
Wie chriss66 bemerkt hat, sind mittlerweile Daten auf dem Server. Die Mapper aus der Gruppe Daubach/Untershausen haben die Daten einfach noch einmal neu in JOSM eingegeben und dann hat der Upload auch funktioniert. Und diese neuen Daten sind in der Tat besser als die in der defekten OSM-Datei.

Thomas

amm · 2010-06-02T13:13:25.000Z

Es kommt immer mal wieder zu ueberlastung der “verantwortlichen” OSM-Server aus verschiedenen Gruenden, aber skript bassierte massendownloads sind haeufig eine der Gruende (bis sie von den Admins geblockt werden um das restliche System am laufen zu halten) . In den Graphen auf http://munin.openstreetmap.org/openstreetmap/puff.openstreetmap-lighttpd_queues.html kann man den derzeitigen Stand der Auslastung recht gut sehen. Die drei relevanten queues “api, bulkapi, und map” haben jeweils ca. Kapazitaet fuer 30 simulatante requests. Alles was darueber liegt muss in eine Warteschlange und kann dem zu Folge zu verzoegerungne fuehren. die API queue ist fuer kleine einzelne requests zustaendig, bulkapi fuer uploads und potlatch und map fuer das herunterladen der Daten in JOSM.

Ob es in den letzten paar Wochen irgendwelche Aenderungen in JOSM oder der API gab, die es verursacht das die Rueckmeldungen in JOSM nicht mehr immer korrekt ankommen kann ich nicht sagen, aber das sollte man im Auge behalten um zu sehen ob das irgendwie zu verbessern geht. Bei den history abrufen im Webbrowser, wurde aber ein timeout von 30 sekunden eingebaut um bei zu grossen abfragen nicht “unnoetig” resourcen zu beanspruchen.

Johannes69 · 2010-06-03T21:41:08.000Z

Nightdive:

Und wie lautet die Fehlermeldung ?
Es ist immer extrem nervig wenn Leute Fehler berichten aber nicht welchen Fehler.
Ich verstehe nicht wieso man solch wichtige Informationen weglässt.

Nervt mich auch

Hier die Fehlermeldung samt Stack Trace


POST http://www.openstreetmap.org/api/0.6/changeset/4896214/upload... org.openstreetmap.josm.io.OsmTransferException: java.io.IOException: Error writing to server

        at org.openstreetmap.josm.io.OsmApi.sendRequest(OsmApi.java:608)
        at org.openstreetmap.josm.io.OsmApi.sendRequest(OsmApi.java:476)
        at org.openstreetmap.josm.io.OsmApi.uploadDiff(OsmApi.java:426)
        at org.openstreetmap.josm.io.OsmServerWriter.uploadChangesAsDiffUpload(OsmServerWriter.java:123)
        at org.openstreetmap.josm.io.OsmServerWriter.uploadOsm(OsmServerWriter.java:199)
        at org.openstreetmap.josm.gui.io.UploadPrimitivesTask.realRun(UploadPrimitivesTask.java:237)
        at org.openstreetmap.josm.gui.PleaseWaitRunnable.doRealRun(PleaseWaitRunnable.java:83)
        at org.openstreetmap.josm.gui.PleaseWaitRunnable.run(PleaseWaitRunnable.java:129)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source) Caused by: java.io.IOException: Error writing to server
        at sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown Source)
        at sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown Source)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
        at java.net.HttpURLConnection.getResponseCode(Unknown Source)
        at java.net.HttpURLConnection.getResponseMessage(Unknown Source)
        at org.openstreetmap.josm.io.OsmApi.sendRequest(OsmApi.java:532)
        ... 10 more