Summary

  • OpenStreetMap's 17 April 2009 notice put its editing API in read-only mode, sometimes unavailable, during migration to v0.6. Contributors could not save map edits, the Potlatch online editor was disabled, and external editing tools needed compatible versions.
  • The new API required each edit to belong to a changeset, added element-version checks and numeric user IDs for public edits, and enabled atomic diff uploads within one request. A changeset itself could span requests, was not atomic, and could not be rolled back through the API. Foundation minutes later described a longer-than-planned database migration from MySQL to PostgreSQL.

The map was still there; the save button had lost its destination. On 17 April 2009, OpenStreetMap announced that its API was read-only while the project moved to version 0.6, with periods of complete unavailability possible. Contributors could not save new edits to the database. Potlatch, the online editor, was disabled. The notice expected work to finish sometime on Monday, 20 April, and told users of other editing software to upgrade for the new API. A map made by its users had briefly stopped accepting the thing they came to give it.

That interruption bought a different shape for the record. The project's v0.5-to-v0.6 change document dates the v0.6 release to 20 April and says every modification of a node, way or relation had to sit inside a changeset. An editor could group related changes, add a human-readable comment, and keep a changeset open across multiple API calls. Instead of seeing isolated altered map objects, people could ask what work belonged together. The new record gave an edit a named context.

The same document draws a line that the label “changeset” can obscure. A whole changeset was not one database transaction. It could stretch across multiple requests, and the API could not roll it back as a unit. A single diff upload could be treated atomically within its request. Those are different promises. One tells the history of an editing session; the other controls whether a particular submitted chunk succeeds together. Confusing them would make the new record sound like an undo button it never was.

Version numbers changed the moment two editors reached for the same feature. API v0.6 returned a version for each map element, and a client updating that element had to submit the version it had seen. If the server held a newer version, it rejected the stale write. This was an operational rule, not just a tidier history page: an editor could no longer safely assume that the object on screen was still the one in the database.

Attribution changed too. Under v0.5, the API returned a user's display name, which could be changed without a name-change history. Version 0.6 included a numeric account ID alongside the displayed name for public edits. The project's document explicitly noted the boundary: IDs for earlier anonymous edits would not become visible by magic. The migration improved the identity attached to later public changes without reconstructing an earlier actor from a blank field.

The project's preserved migration-testing page shows what this meant outside the central database. Test servers were opened so editor and data-tool authors could try the new API. Volunteers were asked to check changeset creation, stale-version conflict messages, Potlatch behavior, JOSM versions and replication tools. Some older JOSM releases could not work with v0.6 at all. A central upgrade had made every editing client part of the cutover plan.

The physical migration was no small background detail. In OpenStreetMap Foundation board minutes from 12 May, Grant described replacing the MySQL-backed setup with a PostgreSQL server. The migration had taken longer than planned because some stages needed rerunning; a few fixes remained, and monitoring and additional disks were still being arranged. The April notice's expected finish was a plan. The May record tells us the work exceeded it, without giving a precise timestamp for the return of each editing route.

OpenStreetMap's new edit history came out of a very old trade: to change the machinery of collaboration, the project had to interrupt collaboration itself. The people holding the pencils waited while the server learned to remember groups of marks, reject stale ones and attach sturdier account identifiers. Then every editor had to learn the new rules of saving.

Original records