Summary

  • OpenStreetMapは2009年4月17日、APIを読み取り専用にしたと告知した。移行中は完全に使えない時間もあり得た。地図の変更は保存できず、オンライン編集ソフトPotlatchは停止した。
  • API 0.6では変更をchangesetに入れ、各地図要素の版を照合し、公開編集には数値のユーザーIDを付けた。一回の差分送信は原子的に処理できても、複数の送信にまたがるchangeset全体は一つのトランザクションではなく、APIからまとめて巻き戻すこともできなかった。

地図を直す人がいても、その修正を受け取る場所が止まっていた。2009年4月17日のOpenStreetMapの告知は、API 0.6への移行中、書き込みを止めて読み取り専用にしたと伝える。場合によってはAPI自体が使えなくなり、編集はデータベースに保存できない。Potlatchも停止した。作業終了は20日月曜日のどこかと見込まれ、ほかの編集ソフトには新APIへの更新が求められた。告知にあるのは見込みであり、全機能の復旧時刻ではない。

停止の向こうには、地図の変更を扱う新しい単位があった。API 0.5から0.6への変更記録は、0.6の公開日を4月20日と記し、ノード、ウェイ、リレーションの変更を必ずchangesetに収めるとした。一つのchangesetは複数のAPI呼び出しにまたがり、説明コメントも付けられる。個々の地物が変わった事実に加え、どの作業のまとまりに属したかが見えるようになった。

ただし、まとまりは「全部元に戻す」ボタンではない。公式の変更記録はchangeset全体を非原子的と明記し、APIで一括ロールバックできないと述べる。一回の差分アップロードなら、そのリクエスト内で原子的に処理できる。前者は作業の履歴を束ね、後者は一度の送信の成否をそろえる。地図を直す人には、その違いが失敗後の手順を左右した。

版番号は同じ道を二人が触った場合に効く。編集ソフトは地図要素を受け取ったときの版を保存時に送り返す。サーバーに新しい版があれば、古い版を前提とする書き込みは拒否される。編集者は新しい状態を取り直して衝突に対処しなければならない。履歴を整えるだけでなく、古い画面からの上書きを止める規則だった。

変更者の記録も変わった。旧APIが返した表示名は後から変更でき、改名の履歴も残らなかった。0.6は公開編集に数値のアカウントIDを添える。もっとも、以前の匿名編集に欠けていたIDが後から生まれるわけではない。新たな記録はこれからの公開編集の帰属を強くするもので、過去の空白を埋めるものではなかった。

残された移行テストのページには、中央のサーバー以外に必要だった仕事が並ぶ。試験用APIでchangesetの作成、古い版の拒否、PotlatchやJOSMの動作、データ複製ツールを確認する。古いJOSMの一部は0.6を使えない。地図を描く道具の作者も、保存先が変わった事実を自分のソフトで引き受ける必要があった。

機械の入れ替えも進んでいた。OpenStreetMap Foundationの5月12日の理事会議事録は、MySQLからPostgreSQLの新サーバーへ移ったと記す。移行工程の一部をやり直したため予定より長引き、残る修正や監視、追加ディスクの準備も続いていた。4月に示した完了予定が現場の実際を言い当てたわけではない。各編集経路がいつ復帰したかまで議事録は示していない。

地図の作業履歴は見やすくなった。その準備中は、作業そのものを保存できなかった。編集者は待ち、ツールの作者は直し、サーバーは古い版を拒むことを学んだ。共有の地図が自分の変更をより正確に記すには、いったん鉛筆を置く時間が必要だった。

原資料