Change rollback

From OpenStreetMap Wiki
Jump to navigation Jump to search

Change rollback is a way of responding to vandalism and to 'mistakes' (which are not considered vandalism but which can be responded to with the same tools) to an older version of the data. This is also known as reverting.

Undoing deletions

See Undoing deletions for the special case of just deletions.

Use editors to rollback a small number of nodes and ways


JOSM has 'undo' functionality which allows work to be reverted to an older state, but can only go as far back as the point at which the data was downloaded into the program.

JOSM has an Undelete plugin that can be used to undelete deleted relations, ways, and nodes. This replaces a manual way.

If you already uploaded your changes, the Reverter plugin can be used to roll back a changeset. Please be careful though - it's possible to damage other mappers' work if a revert is attempted the wrong way (and make a subsequent revert more difficult). If in doubt, ask for help in a contact channel (like IRC, the "help" site, or mailing list).

Potlatch 1

You can also use Potlatch 1 to revert to an earlier version of a way, or to undelete deleted ways. See Potlatch 1/Primer#Undoing mistakes.

Via its special/own database API Potlatch 1 can show all previously deleted ways on its map (even if the object ID is previously unknown): Zoom in as much as possible and hit the button "u" to query the server for deleted ways in the current area. Of course you could use Potlatch 1 only for this discovery of the IDs and undelete/revert with another tool. See other ways to find the id of a deleted node

Potlatch 1 has been removed from the edit tab, but you can still access it on the OpenStreetMap website with an 'editor=potlatch' URL parameter. First click the dropdown to open the area in Potlatch 2, and then remove the "2" from the url.

Use revert scripts to rollback entire changesets

A changeset is a group of edits made within a certain time by one user. It makes it easy to identify and deal with a problematic set of changes (such as a large-scale movement of nodes and ways or vandalism). Revert scripts use changesets in order to identify the changes to be reverted. However, changesets are not automatically revertable. Nor are all traces of the reverted changes removed from the database. Instead, the revert script will produce the same result as if someone examined the reverted changesets and manually changed all of the changed items back to the state in which they had been before.

Revert scripts are available to undo entire changesets, but should only be used if you know what you are doing. In fact most people should seek help or ask the authors of the script to run them in a particular area. These scripts do not have safety nets. Be sure that you feel confident to fix anything you might break. Never do this unless you are absolutely sure that the edit in question is either malicious or accidental. When in doubt, discuss things on the mailing list before you act.

A quick note about clean and dirty reverts

A clean revert can be executed when none of the objects in the changeset have been changed in the mean time. In this case the revert will not have any side effects. A dirty revert happens if some of the data to be reverted has been changed in the mean time.

Currently the revert script doesn't revert dirty objects by default (but this is switchable inside the script). See the Original Changesets and Reverts Proposal 2008#Reverts and Revert scripts for more information. The JOSM reverter plugin handles dirty reverts interactively, which is effective but can be very time consuming.

Reverting data that has been subsequently edited by other mappers is inherently a difficult problem and requires careful analysis of what those subsequent mappers have done. Were they just trying to "fix" broken data (for example, making connections in OSM between imaginary roads and real ones) or were they adding new on-the-ground features that OSM doesn't want to lose?

See also