This page last changed on Oct 10, 2007 by aaime.

Though the new Versioning WFS will do transparent versioning on all WFS-T transactions, there are several improvements that can be done to clients to take advantage of the new features to make them 'versioning aware'. Right now I can think of two main ways to do this, a more light weight web-based one to do edits, rollback vandalism, and online tracing of new features, and a heavier weight one that acts more like a subversion client, keeping a local copy of the data and checking it in when done.

Enhanced and New operations

Any version aware wfs-t client will need to implement a few new operations (GetDiff, GetLog, Rollback), as well as handle a bit more information for some of the standard operations. The full protocol can be seen at Versioning WFS - Extensions. That is the more definitive guide, this is just some thoughts on what a client will need to do.

  • GetLog - first version would be to just let a user specify a starting and ending version or time for a selected feature or for the current view area. These would just be fid and bbox filters, respectively. A more advanced client would allow a user to input an arbitrary filter that they want a log of (all roads of type 'highway' that have been changed in the past 5 days). Note that this operation is very similar to GetFeature, one can likely re-use code from that operation, just needs a UI way to let people select versions.
  • GetDiff - after a GetLog call, to see what edits have happened, one can drill down and see the specific changes. Right now the output is a WFS transaction, that can then be used to perform a rollback. The back end has a bit of work to make an output that is easier for a client to deal with, to display the results of a difference for the user. We are considering leveraging WMS plus versioning to display visual diffs.
  • Rollback - Takes a difference query just like getLog and getDiff, but passes it in to the Transaction. The UI should be about the same as for GetLog, select a feature or the current area, and eventually accept arbitrary filters.
  • Track version number of GetFeature, so it can be included in transactions to get proper error reporting if things have changed, so it doesn't overwrite changes.
  • Authentication - this is still under development, but clients will need to be able to log in and likely hold on to a cookie. This is initially just used for identification purposes on each commit, but could eventually grow to access control for certain actions.

UI rambles

Wikis are obviously our inspiration for this workflow, with some twists for maps.

Log, Diff, and Rollback all require to and from versions, and a filter (which can be simplified to a select feature, or the currently viewed area). In a version aware graphical editor, when a user hits 'edit' there should be an optional version window for the area/layer being edited. This will be a GetLog call for a bbox for the area, with a maxFeatures so it just shows X number of recent edits that fit in the window. If there is a longer history, it should have a 'more', which sends a GetLog starting at the last displayed revision, with a maxFeatures. When a feature is selected for editing a GetLog for that feature should be done, so the history is just that of the feature, not the whole viewing area.

The log list should have check boxes to compare versions, the date the change was made, who made the change, and their comment for the revision. Some of this information can be collapsed, but should be easily accessible. The check boxes to compare versions can be selected, and then a 'compare selected version' can be hit, which returns the results of the GetDiff operation (which is one of the main things to be fleshed out - how to show the diffs). By each version there should also be a 'restore this version' link. If this is done a confirmation message appears, along with a space to include a commit message. We may consider doing a GetFeature at the revision to be rolled back to, as a 'preview'?

The other small UI improvements include having users include a commit message for all their edits, and reporting errors if things are not up to date.

Visual diff

Anyone? Do two WMS requests and animate flipping between the two of them? Attributes can be handled in more normal wiki way...

Light-weight (web) client

So the light weight way of working things is focused on web based editing and updates, pretty much assuming good connections to the internet. For the most part zooming and panning will utilize the WMS, drilling down to an area to edit. This can be to add new features or edit existing ones, but either way you'll want to drill down. Then one can get the entire area down through WFS, or select a single feature to edit.

Once selection is made, the WFS GetFeature call goes out and the results are then rendered as vectors, along with a GetLog call on the edits done on the selection (as talked about in the UI rambles above). These can then be moved about, and attribute data can also be edited (ideally in a javascripty pop-up that displays the attributes and then you can double click to edit the values). GetDiff can be used to get more information. The edits are stored up (including rollback calls), and then there should be a 'save' button that creates the transaction. It should ask for a comment on the edit, and then send the response to the server.

Possible further improvements

  • Selection of features with arbitrary filters - can be looking at a wide area, run a filter, and then the client will zoom in to the bounds of that filter, highlighting the features (and indeed downloading them as WFS Vectors on top of the raster WMS canvas, to be edited).

JSON options?

This isn't completely off the table by any means, but there's no established WFS json bindings, so we're hesitant to be the first to define them when we're really focused on something else. But it's tempting. We may look in to simple marshalling from our objects, quick investigation shows http://jsontools.berlios.de/ and http://www.twolattes.com/code.php the latter requires java 1.5, not sure about the former.

Heavy-weight client

This scenario is more geared towards a desktop application. In this case the desktop GIS will function more like a subversion or cvs client. It downloads all the information and has a local copy of the area under interest. This could be the whole dataset, or it could just be the bounding box of a particular area, or just the highways, since that's all the user is interested in. The checkout can be constructed with a Filter, and the client then has a local copy.

To do this well the client will need to have an embedded spatial database, such as we're thinking with SpatialDBBox. It then completely caches its local copy. This makes the data very easy to work with, zooming in and out and making changes. It also saves lots of bandwidth in WFS in general, since one only hits the server the first time. After that the client should just download diffs. It could check the server to see if there are any new changes when it fires up, and maybe have an 'update' button. Then it would also check if things were up to date before attempting to make a commit. It's obviously going to have to store the commits to make, but WFS-T desktop clients do that now, more or less. But this should persist those changes to make even if the client shuts down.

The big win for this is really bandwidth, since it makes WFS much more usable. Current desktop WFS clients hit the server on every zoom, taking lots of bandwidth, processing power, and time. This gives them a local copy that will perform quite fast and not hit the server. It's like editing their own local data. But when they need to save it to the server, they easily can.

Of course this should also support rollbacks and getdiff and getlog. But those can all be network calls, since none of them are that intensive. SVN works this way as well, if you want to do svn blame or do a diff to versions long ago you have to call the server. But local diffs are available on the client, since it should have a list of changes to do, and the original versions. The UI should likely be the same as in the UI rambles above, be able to zoom to an area and get the log and the diffs as a sidebar of sorts, check out and edit attributes, and create edits and new features to commit.

This can also be used for editing in areas with low bandwidth or bad connections. The edits are saved up, and indeed the updates come down as just the updates.

Document generated by Confluence on May 14, 2014 23:00