Quoting Luca Sigfrido Percich <luca.percich@anonymised.com>:
Hi all,
well, about fun stuff... amongst the hundreds of things we have to do
with GeoServer / Geotools for having the Road Information System run,
this one of versioning is worth mentioning:
On 21 Jun 2005 at 15:25, Jody Garnett wrote:
> (hints don't cut it) (talk to Justin) - Versioning! I know dave is
> interested in the idea of Feature versions (or save points, or long
> term transaction support) (ask Dave, or Jody)
We were thinking about a "CVS model" for handling feature versioning:
- a feature repository (a DataStore) holds feature diffs, i.e. all
the changes are kept in storage, and from one version to the next I
can see if a feature has been edited, added, deleted or left
unchanged, who did the edit and when;
- A shared TAG database for tagging different featureTypes (a
"release version" of a road network means tagging arcs, nodes,
segmented attributes, related entities and so on);
- checkout in user sandboxes, perform edit, transactions, validation
in the sandbox (which behaves like an ordinary DataStore);
- "commit" from the sandbox to the repository;
- checkout from the repository to a "release" sandbox which might
have validations different from the editing sandboxes.
- ...
For a road network, we often need to insert road features BEFORE the
road is build on the real world; also we may want to produce
scenarios with different new road structures. As you know, inserting
new features in a line network would modify the network topology, so
doing this in a sandbox and committing the diffs later on seems to be
the right solution.
We were (of course!) thinking about incapsulating these behaviors in
-
let's say - a VersionedRepositoryDataStore which possess the
versioning logic and makes use of another DataStore as storage
(again, the idea of putting one datastore on the top of the other).
Then we might have a VersionedSandboxDataStore which has the
checkin/checkout logic, stores the versioning info ad might access to
another DataStore for actually storing features.
We're still thinking about this, but sooner or later we'll start
coding... it would be great working with a widely accepted framework,
or specification... any ideas?
I think we may be on our own on this one, which does make it a bit
exciting. I think CVS/SVN is a good model to follow though, if we are
to pick one. I was thinking that the global revision number of svn
might be a bit easier to handle, though I think it would require a
conceptual break from WFS's (extremely) vague feature versioning. Ok,
probably have some people saying 'huh?' right about now. WFS has about
half a paragraph on feature versioning, soley in the GetFeature
request, you can specify a FeatureVersion attribute, which seems to be
more like cvs style. I didn't find that it made a ton of sense, but
it's there, and at the very least we should try to support it.
I'd like to see most of this stuff at the WFS level, but obviously some
datastores are in order. Basically I think we should be able to handle
all the versioning transparently, throught a WFS-T request. We just
handle several datastore operations. Eventually it might be nice to
turn this into a spec, WFS-V or some such. But your version datastore
should be available through WFS. The cool thing about this is that you
could get the diffs of an area of the map by sending a getFeature
request on that bbox to the versioning datastore through WFS. But yes,
all this should be done in GeoTools, with GeoServer as just a thin
layer on top. I'd also like to see validation, and then yes, the
sandbox is a good idea - I was articulating it more as a 'peer review'
section, but I think it's the same idea - changes for someone else to
approve and commit. Another feature I think we'd like (we're basically
going for an open geodata collaborative platform - wiki for maps, easy
to use, but powerful enough to be 'real', do validation and peer review
and all) is the equivalent of JIRA's 'watching' - you could subscribe
to an area of the map that you knew about, and would be send updates
whenever someone edited that.
But yes, since we have no real spec, other than cvs and svn
inspirations, it would be good if we came up with some spec type
documents for this stuff, so others could follow our paths. It would
be neat if all WFS's started implementing a common versioning system.
best regards,
Chris
Sig
--
Luca Sigfrido Percich (luca.percich@anonymised.com)
Agenzia Milanese Mobilità e Ambiente s.r.l. (http://www.ama-mi.it)
Direzione Sistemi Informativi e Modellistica
Via Beccaria, 19 - 20122 Milano - tel. +39 02 884.67.262
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration
Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/
