Summary

  • OpenStreetMap 在 2009 年 4 月 17 日宣布，迁往 API 0.6 期间接口进入只读状态，有时甚至完全不可用。贡献者不能把新编辑写入数据库，在线编辑器 Potlatch 停用，其他编辑软件也须升级。
  • 新接口用变更集归拢相关修改，为公开编辑加入数字用户 ID，并通过对象版本号阻止过时写入。一次差异上传可作为原子操作处理；跨多次请求的整个变更集不是事务，也不能靠 API 一键回滚。

贡献者画好一条路，保存却走不通。OpenStreetMap 的 2009 年 4 月 17 日公告说，项目升级到 API 0.6 时，接口已切换为只读，有时可能完全不可用。地图修改无法写进数据库，网页编辑器 Potlatch 停用。公告预计在 20 日星期一某个时候完成，并提醒使用其他编辑器的人升级软件。这是施工时的预计时间，不是每条写入路径恢复的验收时刻。

项目为什么愿意让地图暂时停笔？0.5 到 0.6 的官方改动说明给出一部分答案。它把 0.6 的发布记为 4 月 20 日，并规定节点、路径或关系的每次修改都必须放进变更集。编辑者可以给这组工作写说明，也可以在多次 API 请求间保持同一变更集。过去分散在地图对象上的动作，开始有了可辨认的工作边界。

这个名字也容易让人想多。变更集可以跨请求，所以整个变更集并非一次数据库事务；官方说明明确说，API 不能将它整体回滚。单次差异上传则可以在一条请求内按原子操作处理。前者回答“哪些动作属于一次工作”，后者回答“一次提交是否一起成功”。把两者混为一谈，出错时就会以为有个根本不存在的总撤销键。

版本号改变了两个人同时改同一条街时的结果。新接口给每个地图对象一个版本；客户端保存时要带回自己读到的版本。服务器若已有更新版，就拒收旧版修改。于是编辑器必须告诉贡献者：你眼前的对象已经过时，先取回新的地图再处理冲突。这是一条写入规则，不只是历史页面更整齐。

用户归属也更稳固。旧接口返回的是可随时修改的显示名，改名本身没有历史。0.6 对公开编辑同时返回数字用户 ID。官方说明还划清旧记录的边界：此前匿名修改的用户 ID 不会凭升级突然显现。新系统能让之后的公开编辑更容易归到同一账户，无法倒填过去缺失的身份。

项目保存的迁移测试页面列出服务器之外的工作。团队开放测试 API，让编辑器和数据工具试新规则：能否创建变更集、遇到旧版本时能否给出清楚错误、Potlatch 和 JOSM 是否能保存、复制工具能否继续运转。某些旧版 JOSM 根本无法使用 0.6。中心数据库换代，边缘每支“画笔”都得重新合格。

机器也在搬家。OpenStreetMap Foundation 的 5 月 12 日董事会记录说，项目以 PostgreSQL 服务器替换原先的 MySQL 系统。部分迁移流程必须重跑，工作比原计划久；仍有后续修补、监测和补充磁盘的事要做。这份记录解释了工期延长，却没有给出各编辑接口精确的恢复时间。

更清楚的协作记录不是白来的。贡献者得先等，客户端作者得修工具，服务器得学会把相关改动归成一组、识别过时版本并附上更可靠的账户编号。地图恢复可写时，每次“保存”背后的规则已经换了。

原始记录