Summary

  • Am 17. April 2009 meldete OpenStreetMap seine API während der Umstellung auf 0.6 als schreibgeschützt, zeitweise sogar vollständig unerreichbar. Kartenkorrekturen ließen sich nicht speichern, Potlatch war abgeschaltet, andere Editoren mussten angepasst werden.
  • Die neue API ordnete Änderungen Changesets zu, prüfte Objektversionen und ergänzte numerische Nutzer-IDs für öffentliche Bearbeitungen. Ein einzelner Diff-Upload konnte atomar sein; ein ganzes Changeset über mehrere Anfragen hinweg war es nicht und ließ sich per API nicht als Einheit zurückrollen.

Die Karte brauchte Korrekturen, der Schreibweg war gesperrt. In einer Mitteilung vom 17. April 2009 erklärte OpenStreetMap seine API während der Migration auf 0.6 zum Nur-Lese-System. Zwischenzeitlich konnte sie ganz ausfallen. Beiträge gelangten nicht mehr in die Datenbank, und Potlatch, der Editor im Browser, war abgeschaltet. Die Arbeiten sollten voraussichtlich irgendwann am Montag, 20. April, enden. Andere Editoren brauchten anschließend ein Update. Diese Ankündigung nannte einen Plan, keinen überprüften Zeitpunkt für die Wiederaufnahme jeder Schreibfunktion.

Die projektseitige Aufstellung der Änderungen von 0.5 auf 0.6 datiert die neue Version auf den 20. April. Sie führte Changesets als Rahmen für jede Änderung an Knoten, Wegen und Relationen ein. Ein Changeset konnte eine erläuternde Bemerkung tragen und mehrere API-Aufrufe umfassen. Damit ließ sich eine Bearbeitung als zusammenhängende Arbeit erkennen, statt nur eine Reihe veränderter Objekte zu sehen.

Das Wort „Set“ versprach jedoch keine Sammelrücknahme. Die Spezifikation nennt das ganze Changeset ausdrücklich nicht atomar; die API konnte es nicht in einem Schritt zurückrollen. Ein Diff-Upload innerhalb einer einzigen Anfrage konnte atomar abgearbeitet werden. Das Changeset ordnet die Geschichte der Bearbeitung, der Upload bestimmt die Ausführung eines konkreten Pakets. Wer beide Ebenen verwechselt, plant die Fehlerbehebung mit einem Knopf, den das System nicht besitzt.

Auch die Version eines Kartenelements wurde zur Voraussetzung des Schreibens. Der Client erhielt eine Versionsnummer und musste sie bei der Änderung zurücksenden. Hatte inzwischen jemand anders eine neue Fassung gespeichert, wies der Server die alte Eingabe zurück. Zwei Leute konnten dieselbe Straße anfassen, doch der zweite speicherte nicht mehr unbemerkt über einen neueren Stand hinweg. Sein Editor musste den Konflikt erklären und die aktuellen Daten holen.

Zur besseren Zuordnung kam eine numerische Nutzerkennung. API 0.5 hatte einen Anzeigenamen zurückgegeben, der ohne Namenshistorie geändert werden konnte. Mit 0.6 erschien bei öffentlichen Bearbeitungen zusätzlich die Konto-ID. Früher anonym gespeicherte Änderungen erhielten dadurch keine nachträglich sichtbaren IDs. Die neue Kennung schärfte den künftigen Nachweis, sie füllte nicht die Lücken vergangener Datensätze.

Auf der erhaltenen Seite für Migrationstests taucht die übrige Arbeit auf. Test-APIs sollten zeigen, ob Editoren Changesets eröffneten, veraltete Versionen verständlich abwiesen und Datenwerkzeuge weiterhin liefen. Potlatch, JOSM und Replikationsprogramme standen auf den Prüflisten. Einige ältere JOSM-Versionen konnten mit 0.6 überhaupt nicht arbeiten. Ein Umbau im Zentrum griff bis in jedes Werkzeug hinein, mit dem Menschen die Karte zeichneten.

Das Protokoll der OpenStreetMap Foundation vom 12. Mai beschreibt die Hardwareseite. Ein PostgreSQL-Server löste das bisherige MySQL-System ab. Teile der Migration mussten erneut laufen, weshalb die Arbeiten länger dauerten als geplant; Nachbesserungen, Überwachung und weitere Festplatten blieben Thema. Der spätere Bericht zeigt den Mehraufwand, ohne jede einzelne Rückkehr der Bearbeitungswege zu datieren.

Die Karte gewann ein besser lesbares Gedächtnis, während ihre Zeichner vorübergehend nichts speichern konnten. Der Server lernte, Bearbeitungen zu gruppieren, alte Versionen abzuweisen und öffentliche Konten verlässlicher zuzuordnen. Danach mussten die Editoren, die ihn benutzten, dieselben Regeln sprechen.

Originalunterlagen