Versioning WFS

Introduction

 The current User Manual section on Versioning is at: *6 Versioning*

This area represents the work done to implement 'versioning' in WFS, that is how to keep track of changes to data in GeoServer, leveraging the WFS-T standard. The current state is that a first working server version is complete. See the notes on Trying out the early WFS-V prototype, to download and set it up yourself, or visit http://sigma.openplans.org:8080/v-geoserver and walk through the demo requests to see it in action.

Next steps

Though we have a fully working server, there is still quite a lot of work to do. The versioning module is integrated with GeoServer trunk, and we should have some sort of release with GeoServer 1.6.0-beta1. We're working on implementing a client that offers access to the versioning operations. Currently OpenLayers is the leading candidate, though we hope to encourage many different implementations. Working with a client should help shape the protocol, refining it even more.

Past just establishing the basics, we hope to do a lot more work on more options like GeoRSS and email notifications about transactions and more granular security. We've got a new security framework on trunk, we just need to start exercising and integrating it more. We also want to make it easier for groups to select licenses, as well as explore advanced features like branches, and hooking up our validation engine.

Outline

The document is quite long, so it has been split into subpages:

A R&D notes page is available that stores notes about alternative ways we could implement versioning based on the feedback we gathered so far on WFS-V users

Added by Andrea Aime, last edited by Andrea Aime on Feb 15, 2010  (view change)

Comments ( Hide )

Andrea Aime says:

Here I've pasted two comments made by Jody Garnett in order to preserve them, since I want to dedicate a section of the document to those issues and remove the comments from the document itself.

Comment to implementation proposal:

The first conflict concerns the Feature Model used by WFS: the difference between identity and version is not apparent. The concept of feature id is intended to denote the real world contruct (and thus the feature id is the same regardless of version). For a given feature all data is intended to be recorded - I assumed this record would be matched with a timestamp, but it appears that branch is also needed for long transaction support.

It is attractive to do the "Version" column with value 0 being used to denote the current "head", it then being easy to select out the "current contents", and possible to cast back through time to find old values.

Comment to WFS-T extensions:

There are two choices for representing branches without breaking anything:

  • Make Branch an Attribute - so client code can perform sensible queries, you will need to provide the range as part of your DescribeFeatureType via a "choice" construct. May also consider using Timestamp to mark edits, rather then a Version number.
  • Make different WFS Servers for each branch - this is what I would call an "Oracle approach" where the fact that anything strange is going on is completly hidden from client code. With respect to keeping history you could also just ask users to model history themselves using their own timestamps as required.

In reality the combined approach is needed; setting up each branch as a seperate WFS entry point is very attractive, provides isolation and interoptability. Even with this approach we will need one WFS Entry point where branch information is available (as an attribute?) allowing client code to be written to resolve conflicts for a merge.

Nov 13, 2006 08:37 ( Permalink )
View • Attachments (4) • Info