Morgen (11.7.) soll dann der Redaktions-/Putzbot seine Arbeit aufnehmen.
Geputzt wird dann vom Ablauf wie folgt:
1. Irland
2. Vereinigtes Königreich
3. Westeuropa
4. Nordamerika
5. Australien
6. Rest der Welt
Edit: Die Objekte/Changesets werden vom Bot in der Datenbank erst mal nur, über einen extra API-Redaktions-Erweiterung, als versteckt markiert, sind aber vorerst noch da.
Um Konflikte beim Bearbeiten zu reduzieren, wird (während der Bot in der entsprechenden Region läuft) empfohlen, die Änderungen möglichst oft und zeitnah hochzuladen.
wenn ich all die Infos richtig verstanden habe, ackert sich der Bot so nach und nach durch die ganze Live-DB und wird dafür einige Wochen brauchen.
Daraus folgere ich, dass ab sofort die Diff-Files aus UK “ein wenig größer” werden, da bei dieser Aktion ja auch Sachen angefasst werden, die sonst niemand ändert.
Mal sehen, ob mein Diff-Import auf Minutenbasis das verkraftet.
Wenigstens brauch ich dann keinen Full-Import mit den sauberen Lizendaten machen.
Walter, das wirst du ohnehin machen müssen. Deine DB ist nur cc-by-sa un die kannst du nicht umlizenzieren. Aber das hatten wir doch schon mal ausdiskutiert…
Ich versuche gerade herauszufinden, wie stark die Diffs (in Prozent) wachsen werden.
Ganz naiv:
Ca. 2% der Daten werden durch den Bot verändert oder gelöscht, dafür gebe ich ihm 3 Wochen.
Ca. 2% der Daten werden täglich durch normale Bearbeitungen erzeugt oder verändert.
Das bedeutet also, dass die Diffs um 1/21 (also ca. 5 Prozent) größer werden?
Ist das wirklich so wenig oder wo ist mein Fehler?
Sind meine Zahlen falsch, habe ich mich verrechnet oder habe ich da etwas völlig falsch verstanden?
jo, da war mal was. Diskutiert ja - ausdiskutiert, nicht unbedingt
werd ich wohl gelegendlich mal machen, aber nur damit anderer Schrott rauskommt. Allerdings sehe ich da für mich keine akuten Probleme, da ich derzeit eh nichts im Netz anbiete.
Im übrigen bin ich immer noch der Ansicht, dass eine DB, die nur ODBL-Daten enthält, “sauber” ist - egal auf welchem Weg das erreicht wurde.
schau’n mer mal, wie sich die Sache entwickelt und was dazu eventuell von unseren Lizenz-Gurus kommt.
Ich versuche mal eine Abschätzung; dabei addiere ich Knoten, Wege und Relationen vereinfachend ohne Gewichtung. OSM enthält etwa 1.5G Knoten, 140M Wege und ein paar Relationen, macht grob 1.6G Objekte. In einem zufällig herausgegriffenen day-replicate aus den letzten Tagen finden sich 1,7 M Objekte. Das ergibt eher 10^-3 oder 0,1 % pro Tag.
Ehrlich gesagt, mach ich mir nicht allzu viele Sorgen darüber. Meine Toolchain (osmosis → postgresql/snapshot) braucht zum Verarbeiten der Daten einer Stunde ca 10-15 Minuten.
D.h. erst wenn ca 3-4 mal mehr rüberkommt als jetzt, wird es bei mir eng.
kann man schön an den Zacken rechts sehen: Rechner um 14:00 an und dann die Daten von ca 9:00-14:00 Uhr in Stundenblöcken reingezogen. Nach ca 1H ist das Lag nur noch 2 Minuten. Dann geht übrigens die Last im Grundrauschen des Rechners unter.
In der mittleren “Steilkurve” geht das noch fixer, da er hier die nächtlichen Daten verarbeitet und Europa tief geschlafen hat.
Dauert wohl noch ein wenig, bis rund um die Welt gemappt wird.
@Oli-Wan das dürfte wohl eher hinkommen und wäre dann Faktor 2. Wobei das natürlich eher der Durchschnitt ist.
In einigen Regionen sind es deutlich weniger als 2% die gelöscht werden und wenn ich an Australien denke, dürften die Changefiles deutlich größer werden.
Wenn man meine obige Abschätzung zugrunde legt, ist ein Faktor 2 durchaus drin. Dabei ist noch zu beachten, daß die Laufzeit des Putzbots bisher nur eine wilde Schätzung ist, und sein Durchsatz je nach Region stark variieren könnte (je nachdem, ob die problematischen Bearbeitungen weitgehend isoliert oder mehr oder weniger stark mit anderen Beiträgen verflochten sind). Für Datenbanken, die beim Import schon nahe am Limit sind, könnte es durchaus knapp werden.
Nun, die Ansichten waren dargelegt, ohne daß einer den anderen überzeugen konnte. D.h. wir waren ungefähr an folgendem Punkt:
Das dürfte juristisch anders gesehen werden. Der lizenz- und urheberrechtliche Status eines Objekts ist (leider) keine Zustandsgröße. (Position B)
