Revert/UX

From OpenStreetMap Wiki
Jump to navigation Jump to search

State of Current UX

How to test

Reverter plugin

Josm api06 settings.png

Setting JOSM to a test server for editing and reversion. This is from the Edit->Preferences menu. Note that you need to visit the web interface and register for a new account first.


Josm api06 changeset download.png

Using a URL pattern to download data for just a specific changeset from the OSM API. This is from the File->Download from OSM menu which presents a list of regexp-like matching URL patterns if you put in an unrecognised one. Note the 'download' needed at the end.

Josm api06 changeset optfail.png

If you select objects in a changeset you've just downloaded, you get more options in the reverter screen, but the UI still requires you to input a changeset ID which the client knows.

Josm api06 forth triangle josm delete.png

Here's the final stage, uploading the changes to OSM, they appear as a delete action, it's difficult to differentiate from the final screen, the right layer also needs to be selected in the pane across to the right.

Web view of changesets

Josm api06 forth triangle changeset.png

Here is the default web view of a changeset just created in JOSM. Note that it shows the bounding box, not the details of the specific changes contained (because there may be very many, stretching over a wide spatial area, though that wouldn't be an ideal edit as it's hard to inspect)

Josm api06 forth triangle.png

Clicking through to (in this case just one) way contained in the changeset we see the detailed outline, this is the Mysterious Forth Triangle

Revert scripts

Grab a copy for testing by doing this from a terminal:

$ svn co http://svn.openstreetmap.org/applications/utils/revert/

You'll need the right Revert_scripts#Configuration in a file named .osmtoolsrc which lives in your home directory, and by default you should be using http://api06.dev.openstreetmap.org/api as the value of apiurl for testing purposes. As above, you'll need to register your own account on that server first.

Create a changeset to delete using iD or JOSM editor, then attempt to revert with a basic call using the simple revert script:

$ perl revert.pl <changeset ID> <optional comment>

Out of the box, the script runs in 'dry run' mode. You get a very verbose output of the script's API actions and short snippets of XML being POSTed to delete nodes and ways and update changesets. Nothing will happen on the server side. You will see some perl warnings, but they are harmless. To kick the script out of dry run mode, add dryrun=0 to the .osmtoolsrc file.

Wishlist

I think there are several different sets of aims here. One is to provide a

  • Providing a mainstream-accessible interface for simple reverts
  • Providing a visualisation of complexity interface for complex reverts

One issue with the first point is how useful it will be in isolation. At the moment, reversion is only accessible to people with access to power tools. But a standalone service won't be discoverable by "normal" users of the web client editor. it risks remaining an eternal proof of concept.

One issue with the second point is that "power users" are able to get by okay with the existing tools. One gap that's been identified is in analysis of potential consequences and the impact of changes - see this prototype app for analysis of changesets http://fred.dev.openstreetmap.org/coolnamegoeshere/ This is a really interesting proof of concept but doesn't lead on to either a visualisation or a corresponding action.

However, something like it is needed in either the simple or complex case to identify "what impact your changes are going to have" both on existing data and *subsequently edited data*. This is critical, as later changes to an object which is then reverted will leave isolated nodes hanging around, and this can only really be identified and fixed up by manual inspection. IMO you need some kind of second phase spatial query afterwards, looking for disconnected nodes that were once part of the original, now reverted, edited object. The implications quickly get very complex, and there has to be a cutoff point where reversion is neither plausible or desirable.

One general idea is that reversion should happen quickly if it's going to happen at all. Another is that anyone should feel able / empowered to do it, along with the general community-wiki style principles of OSM as a whole. It bites that this part of functionality is only currently available to people who are confident in operating the "power tools".

Coolnamegoeshere 3.png

Coolnamegoeshere 6.png

See Also