GeoServer : Versioning WFS - Client side thoughts
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.
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.
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.
Anyone? Do two WMS requests and animate flipping between the two of them? Attributes can be handled in more normal wiki way...
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.
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.
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|