[OSGeo-Discuss] Re: "git" like for geodata management [SEC=UNCLASSIFIED]

Peter Batty peter.batty at gmail.com
Fri Sep 24 03:08:55 PDT 2010


Hi,

Yes Smallworld did a lot of innovation in the area of version management and
long transactions some 20 years ago, I was quite involved in all that. The
technical paper you mention is at archive.org, a great resource for finding
web pages that have disappeared!
http://web.archive.org/web/20080519210011/http://cfis.savagexi.com/pages/technical_paper_4

This paper, which I was a co-author of, talks about long transactions as
well as query architectures:
http://web.archive.org/web/20070828091638/cfis.savagexi.com/pages/technical_paper_8

The whole list of Smallworld technical papers is at
http://web.archive.org/web/20080519210016/cfis.savagexi.com/pages/technical_papers

ESRI, Oracle and others adopted a number of the version management ideas
that Smallworld pioneered, but (IMHO) still don't have nearly as robust an
implementation as Smallworld does. If anyone has questions on this area, I'm
happy to try to answer them. If you're not familiar with Smallworld, there's
a bit more background on my blog at http://bit.ly/cDUid1

Cheers,
    Peter.

On Fri, Sep 24, 2010 at 3:55 AM, STEPHEN STANTON <sstanton at btinternet.com>wrote:

>
> I'm a bit surprised no-one mentions Smallworld. Weren't they at the
> forefront of version management almost 20 years ago?
>
> The following link to an interesting technical paper isn't currently
> working, but maybe it'll come back later:
> http://cfis.savagexi.com/pages/technical_paper_4
>
> Steve
>
> > On 09/24/2010 01:40 AM, Bruce Bannerman wrote:
> > > Ragi,
> > >
> > > I agree. I think that we have a way to go yet to have
> > something
> > > comparable to the ArcSDE / ArcGIS Multi-versioning and
> > version conflict
> > > detection functionality.
> > >
> > > The advantage that the ArcSDE solution has is that
> > edits are made
> > > directly within the database. This works well within
> > an Enterprise
> > > environment as described by Fabio earlier in this
> > thread.
> > >
> > > I may be wrong, but I think that git works on files,
> > but I haven’t used
> > > it myself. Can git detect changes to the spatial
> > representation of a
> > > feature within a binary file?
> > >
> > > Also, speaking as someone who implemented an
> > ArcSDE/ArcGIS
> > > Multi-versioned edit scenario several years ago, the
> > ESRI solution is
> > > far from perfect. It imposes very strict environment
> > management on the
> > > system managers, e.g.:
> > >
> > >     * All versions of the software
> > used (client and server) must be at
> > >       precisely the same
> > version, service pack and patch;
> > >     * The environment can only use
> > software that implements the
> > >       ArcObjects environment
> > (from experience, this rules out the use of
> > >       the ArcSDE Java and C
> > API’s);
> > >     * Editors must be well trained
> > and knowledgeable in using both
> > >       ArcGIS and
> > Multi-versioned processes;
> > >     * The Organisation needs to
> > think through their maintenance
> > >       processes to get best
> > advantage of the functionality; and
> > >     * It doesn’t remove the need
> > for data maintenance people to talk to
> > >       each other about work
> > that is going on, as the software cannot
> > >       resolve all conflicts.
> > For example, if two editors make changes to
> > >       the spatial
> > representation of a feature, which one is correct? The
> > >       software will detect
> > the conflict, but the editors (or their
> > >       managers) will need to
> > resolve the issue of which version of the
> > >       feature’s spatial
> > representation is correct.
> > >
> > >
> > >
> > > Bruce
>
>
> _______________________________________________
> Discuss mailing list
> Discuss at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20100924/4cfeddb1/attachment-0002.html>


More information about the Discuss mailing list