This page last changed on May 07, 2007 by cholmes.

WFS-T improvements needed (baseline)

  • Basic UI for attribute editing - need some way to edit the attributes of a feature. This should likely be linked to display of feature attributes, send a GetFeature for the selected feature or the currently viewed map, display those, and then make the value fields editable. After editing one should be able to hit 'save' and have those persisted to the server.
  • Nicer UI for attribute editing - Have the display of feature attribute appear as a pop-up on top of the feature, and then make the value fields editable with a double click or a small 'edit' button that changes them from fixed fields to editable fields.
  • UI for updating a geometry - All the examples only have inserting new geometries. We need to be able to let users edit an existing geometry. The work flow would be to select an area on the map (wms), which would then trigger a WFS GetFeature call, and the results of that would be editable geometries, with vertices one can drag to new positions, and with the ability to and update. Bonus for Google My Maps style ghost vertices.
  • XML Serialization on IE/Opera - The WFS-T stuff is unusable in IE or Opera, since they lack XML serialization. We may be able to help out on the server side with JSON translations of the WFS interfaces, but the desire is to make this interoperable. MapBuilder uses Sarissa, which is admittedly heavy-weight. But if it could load on demand only when a user goes in to 'edit mode' then it could perhaps work out well, since most users aren't editing. It also might not be hard to write a light-weight by hand? Or maybe there is an existing one that's not so heavy weight?
  • Composite Transactions - Right open layers seems to need a save for each layer. That is, if multiple layers are edited and then 'save' is hit, only one of the layers gets saved. It appears this may be a systematic lack, that it can't do multiple layers in one transaction. This probably isn't the biggest deal for a first crack demo, the UI can just orient people to editing one layer at a time. But it should be addressed.
  • Edits are lost when panning/zooming You are able to either edit or pan/zoom in the current UI (wfs-t.html demo). The moment you zoom in/out you loose everything that has been edited. At the very least there should be a dialog about your edits being lost when you zoom. Ideally it just works, so you can zoom in on current edits.

Versioning WFS improvements needed.

  • UI control for versioning - A set of buttons for the various operations and their workflow is needed. These would include a selection tool (to select which features to query for logs, diffs, edits, ect.), a button for GetLog of selected feature(s), and buttons for deleting, updating, and rolling back a feature.
  • GetLog operation - Requesting and processing a GetLog call is needed in the code. Read the full GetLog spec for more information on this operation. This is very similar to a GetFeature query, but does not have a propertyList, and does have an additional 'to' and 'from' for version (version numbers or time).
  • GetLog UI GetLog needs a way to select a to and from date or version number to request the log from. It should have a reasonable default, such as from the present all the way back, but with a maxFeatures of 10 or 30 or some such that is reasonable for displaying. The log should display the name of the person doing the commit, their commit comment, the revision number, and the date the revision was made. The bounding box is also part of the GetLog response, and perhaps when a certain log is selected the bounds can pop-up on the map? Right now the results are available as GML, and also as an HTML output. A JSON output should be relatively easy to do, if desired.
  • GetDiff operation - Requesting and processing a GetLog call is needed in the code. Read the full GetDiff spec for more information on this operation. It's just like a GetFeature, except it has a to/from in the query.
  • GetDiff UI - This should likely bootstrap off of the GetLog results. The results of a GetLog call will display a bunch of possible version numbers. Like wiki software we can then have radio buttons to compare different versions

    These can then be selected, as the to/from versions to send in the GetDiff request, and when 'compare selected versions' is hit it sends the call to the server. The results is somewhat of an open question, experimentation needs to be done with displaying diffs. But at the very least attribute changes should be displayed. The visual geometry diff will likely be a couple of WMS-SLD calls, which will display the results - possibly embedded in HTML, possibly to be made by the client.
  • Version Aware GetFeature - GetFeature requests should record the featureVersion attribute, which is essentially used as an 'up to date' check, as the transaction should commit with a version number. If the feature is out of date then the server will raise an error, and the client will need to do an update before checking in.
  • Version Aware Transactions - Transactions need a couple improvements. Updates and deletes should have a featureRevision field set, from a GetFeature call that was done to get the latest version. It should be able to deal with a proper error if there's a conflict, and ask the user if they want to update. The other general improvement needed is commit messages. These are done by overloading the 'handle' field of WFS Transactions. It should be able to take the commit message from the user.
  • Transaction UI improvements - All transactions should ask the user for a commit message, to enforce better information about what and why users changed things. This should be done on 'save'/'upload to server'/'commit' (whatever it is called), and included in the response.
  • Rollback operation - A new transaction sub-element, the 'rollback' is needed. A rollback is just like a delete, with a filter and a typename, but it should also have a 'rollbackTo' revision as an extra attribute. It specifies this with a 'difference query', which is used in getdiff and getlog as well. Note that in this version one can only specify the version to rollback to, there's no rollback from a previous point in time.
  • Rollback UI - This could piggy-back on to GetLog as well, where there is just an extra line for 'restore this version' past the log information, as in confluence:

    There also could be a Rollback control, a button that would just activate the GetLog view with the options to 'rollback'.
  • Authentication - All versioned transactions need to have an 'author', which means that any user editing should be logged in, at least in some way. Anonymous edits could be allowed, but even if they are we want to encourage people to log in. So the wfs-v client should be able to handle logging a user in, initially through http basic authentication (more are quite possible, indeed we can do anything that acegi can handle including openid soon!
  • Authentication UI improvements - At the very least needs a 'log-in' link, a 'you are logged in as ____', and a 'sign out if you are not user ____', as well as a dialog/page to log-in with.

diff.PNG (image/png)
diff2.PNG (image/png)
Document generated by Confluence on May 14, 2014 23:00