Schiefgegander Edit

Prince Kassad wrote:

Ich befürchte, bei dem ganzen Spektakel ist einiges kaputtgegangen.

Wieso? beim ersten mal hat er das hochgeladen, was er im Speicher hatte (also die unfertigen Relationen) , dann hast du das Rel-Fenster geschlossen und er hat den Rest hinterhergeschickt. Etwa so als ob du den ersten Teil gestern und den Rest heute gemacht hättest.

Schau dir die 3 Rels (Südhessenroute, Stadtbus und Grüner Weg) halt mal an und sie ob die einigermaßen vernünftig sind.

der Grüne Weg war eh noch nicht geschlossen und die beiden anderen kann ich nicht beurteilen. Aber so wie ich es von Josm gewohnt bin, kriegt er das ganz gut auf die Reihe.

Don't panic
walter

Man muss das Fenster schließen? 😬

wambacher wrote:

Wieso? beim ersten mal hat er das hochgeladen, was er im Speicher hatte (also die unfertigen Relationen) , dann hast du das Rel-Fenster geschlossen und er hat den Rest hinterhergeschickt. Etwa so als ob du den ersten Teil gestern und den Rest heute gemacht hättest.

Passiert mir auch hin und wieder, daß ich das Relationsfenster vergesse zu schließen... Fenster schließen nochmal hochladen Fertig... bisher keine Probleme...

Sven

SammysHP wrote:

Man muss das Fenster schließen? 😬

Erst durch das Schließen des Relationsfensters werden die dort vorgenommenen Änderungen bestätigt und in die aktuelle Bearbeitung übernommen und sind auch erst ab da im Hauptfenster zu sehen.
Das Relationsfenster ist nicht-modal, d.h. man kann im Hauptfenster nebenher Aktionen durchführen (nicht nur Hochladen), was gelegentlich sogar zu Konfikten führen kann, die man erst auflösen muss.

War mir bislang noch nie bewusst aufgefallen. Wenn ich aber so darüber nachdenke, fällt mir ein, dass ich ja auch Objekte bei geöffnetem Relationsfenster auswähle um sie hinzuzufügen.

Was mich noch mehr nervt ist, dass alles kaputt ist wenn man während des Hochladens auf abbrechen klickt. Können uploads bei der OSM api nicht atomar sein?

slint wrote:

Was mich noch mehr nervt ist, dass alles kaputt ist wenn man während des Hochladens auf abbrechen klickt. Können uploads bei der OSM api nicht atomar sein?

Geht sogar mit den "erweiterten Einstellungen" im Hochlade-Fenster. Dort kann man "Jedes Objekt einzeln hochladen" wählen.
Erzeugt natürlich einen ziemlichen Overhead, ob der Nutzer (und der Server) damit glücklich werden, sei dahingestellt.
Ein Kompromiss wäre das Hochladen in mehreren Paketen oder noch besser, erst gar nicht soviel zusammen kommen lassen (läuft aber unter der Rubrik: Gute Vorsätze).

seichter wrote:

Geht sogar mit den "erweiterten Einstellungen" im Hochlade-Fenster. Dort kann man "Jedes Objekt einzeln hochladen" wählen.

Ich mein eher, dass der OSM server nix in die Datenbank übernimmt bevor Josm sagt, dass der upload fertig ist. Wenn man jetzt auf abbrechen klickt ist manches hochgeladen und manches nicht und teilweise in einem kaputten Zustand deswegen

slint wrote:

Ich mein eher, dass der OSM server nix in die Datenbank übernimmt bevor Josm sagt, dass der upload fertig ist. Wenn man jetzt auf abbrechen klickt ist manches hochgeladen und manches nicht und teilweise in einem kaputten Zustand deswegen

Full ACK, hat mich auch schon gebissen.

Verstehe eure Arbeitsweise nicht. Ich lade meine Änderungen hoch relativ häufig und achte VORHER auf Fehlermeldungen vom automatischen Validator.
Zudem mach ich keine Monsterupdates sondern lade alle paar Minuten alles hoch.

Daher habe ich keinerlei Veranlassung, meine Uploads zu unterbrechen. Sollte es aus technischen Gründen doch mal klemmen (kommt so 1x im Monat vor), speichere ich meine Änderungen lokal und warte bis das Problem (Api down/Inet down, ...) beseitigt ist. Dann starte ich den Update erneut.

Ok, wenn in der Zwischenzeit jemand da auch was geändert hat, gibt es Konflikte, aber das hat man ja im Griff. Im Zweifelsfall hat der Kollege recht.

Rein datenbanktechnisch könnte man auf dem API-Server den gesamten Update in eine Transaktion packen; einfach einen BEGIN...END-Block um die Statements und einen eventuellen Rollback einbauen und das wäre es dann. Ich glaube aber, dass die Entwickler genug Gründe hatten, das eben nicht so zu machen.

Gruss
walter

Ich habe gelernt, dass jeder Upload die Server belastet und man deswegen möglichst selten speichern soll. Deswegen kommen bei mir immer große Changesets mit bis zu 2.000 Objekten vor.

Prince Kassad wrote:

Ich habe gelernt, dass jeder Upload die Server belastet und man deswegen möglichst selten speichern soll. Deswegen kommen bei mir immer große Changesets mit bis zu 2.000 Objekten vor.

Das JOSM guide im Wiki sagt:

http://wiki.openstreetmap.org/wiki/JOSM/Basic_editing#Upload_data wrote:

It's a good idea to upload your editing work quite regularly.

What about conflicts? What if somebody else has been editing in the same area since the time when you downloaded? If you think there is a chance of this (e.g. if you downloaded several hours ago, or if you're editing close to somebody else at a mapping party) then it is good idea to do another download before doing an upload.

Ich mach auch eher kleine CS. 400 Objekte krieg ich aber auch oft, das sind ja 100 Häuser. Wenn dann noch ein detailliertes Landuse dazukommt, ist man da schnell. Aber über 1000 hatte ich noch nie, AFAIK.

1000-2000 hatte ich schon einige male nach 1-2h Arbeit.

Ich kümmere mich nicht um die Belastung, die sollte man ausbauen können. Eine Weisheit aus der Softwareentwicklung ist "Commit Often", das kann man mehrmals zum gleichen Changeset machen.

Prince Kassad wrote:

Ich habe gelernt, dass jeder Upload die Server belastet und man deswegen möglichst selten speichern soll. Deswegen kommen bei mir immer große Changesets mit bis zu 2.000 Objekten vor.

Es werden natürlich immer nur die Objekte hochgeladen, die geändert wurden. Und beim folgenden Upload halt nur die aktuell geänderten. Mag ja sein, dass da Doubletten dabei sind, aber das kann, soll und wird der "arme" Server schon verkraften.

Wer abends den "Upload des Tages" macht, ist selber schuld. 😉

Gruss
walter