On Wed, Aug 10, 2011 at 8:59 AM, Walter Deane wrote:
> Oops again. Forgot to reply all. Been a good day.[?]
>
>Oops, It was suppose to be VersioningFeatureStore I got a bit
> overzealous in my deleting in the UML diagram. I am not familiar with the
> commit process other than what I have read
Oops again. Forgot to reply all. Been a good day.[?]
Oops, It was suppose to be VersioningFeatureStore I got a bit overzealous in
my deleting in the UML diagram. I am not familiar with the commit process
other than what I have read in the developer guide. I was really trying to
get guidance on mak
I have withdrawn the proposal; and started and RnD page covering current
research here:
- http://docs.codehaus.org/display/GEOTOOLS/VersioningDataStore+API
Jody
On Wed, Aug 10, 2011 at 4:48 PM, Mark Leslie wrote:
> I've been talking with Walter about this for a couple weeks, and I
> think it's
I've been talking with Walter about this for a couple weeks, and I
think it's just been a mis-communication that this has been directed
at core. While we are certainly looking to get this supported in core
eventually, I've been assuming basically the same process as you're
describing here. Having
I will hang out with Walter this afternoon and help set up an RnD page; and
perhaps after talking with gabriel set up an unsupported module. I suspect I
had a different impression of where postgis-versioned had gotten to with
respect to API. I understand the internals needed to be replaced; but was
Hi all,
While I don't have any direct interest in a versioned feature facility
at the moment, I'm concerned for the user experience with GeoTools: by
which I include reliability but also particularly the accessibility,
coherence and consistency of the library.
As such, I strongly support the deve
On Tue, Aug 9, 2011 at 3:49 PM, Andrea Aime
wrote:
> On Tue, Aug 9, 2011 at 3:09 PM, Jody Garnett wrote:
>> Andrea do you have another suggested way to work on this then? So far a
>> proposal is the only way we have to communicate. We are not going to start
>> implementing with out a direction.
>
On Tue, Aug 9, 2011 at 3:09 PM, Jody Garnett wrote:
> Andrea do you have another suggested way to work on this then? So far a
> proposal is the only way we have to communicate. We are not going to start
> implementing with out a direction.
Odd, current versioning and process both started with a m
Walter perhaps an RnD wiki page would be a more suitable venue for discussion
/ collaboration between modules.
I have a similar RnD page here for the process work:
- http://docs.codehaus.org/display/GEOTOOLS/Process+RnD
As you can see it is mostly my notes as I go through the steps of taking t
Andrea do you have another suggested way to work on this then? So far a
proposal is the only way we have to communicate. We are not going to start
implementing with out a direction.
--
Jody Garnett
On Tuesday, 9 August 2011 at 10:54 PM, Andrea Aime wrote:
> On Tue, Aug 9, 2011 at 3:06 AM,
On Tue, Aug 9, 2011 at 3:06 AM, Walter Deane wrote:
>
> I have put up a new UML that reflects Andrea's naming changes and Jody's
> request not to have a locking dependency.
>
> http://imgur.com/83RdW.png
Still not good imho.
VersioningFeature is similar to SimpleFeature, DecoratingFeature,
Result
I have put up a new UML that reflects Andrea's naming changes and Jody's
request not to have a locking dependency.
http://imgur.com/83RdW.png
--
uberSVN's rich system and user administration capabilities and model
configu
Hello Walter and welcome to the geotools dev list.
On Mon, Aug 8, 2011 at 3:33 AM, Walter Deane wrote:
> Hey gabriel,
>
> I had a discussion with you a week ago about your GeoGIT project. We have
> been having a discussion on the list about a proposal for a
> VersioningFeatureStore interface that
Hey gabriel,
I had a discussion with you a week ago about your GeoGIT project. We have
been having a discussion on the list about a proposal for a
VersioningFeatureStore interface that is related to your work on ArcSDE and
GeoGIT. I have made a UML diagram that I have referenced in that thread
htt
Oh - to answer your question; please email Gabriel directly and CC the devel
list.
--
Jody Garnett
On Monday, 8 August 2011 at 3:19 PM, Walter Deane wrote:
> Hey guys,
>
> Following Jody's earlier message asking for info on the arcsde versioned
> databases, Jody has asked me to probe the
Hey guys,
Following Jody's earlier message asking for info on the arcsde versioned
databases, Jody has asked me to probe the list a bit about some of the other
modules that could implement these interfaces and if the maintainers are
looking for more/different functionality. We were curious about t
Hey Andrea,
I only meant that you put a heap of effort into the whole postgis versioned
module. With this proposal, I wasn't trying to define the datastore interfaces
and everything else I was just adding in the FeatureStore interfaces for now.
I believe the datastore interface will talk a bot
On Thu, Aug 4, 2011 at 7:25 AM, Walter Deane wrote:
>
> I have submitted a proposal to include a FeatureVersioning and related
> interfaces to GeoTools.
>
> These are new api classes but are based heavily on previous work in the
> versioned postgis project.
>
> The current docs that this relates
On Fri, Aug 5, 2011 at 7:17 AM, Jody Garnett wrote:
> I was actually hoping for Gabriel's viewpoint as maintainer of ArcSDE
> which supports versioned tables (for the 3rd viewpoint).
>
> I don't really mind about the names; I think those other classes you
> mention are "internal" and the Feature
Hey Chris,
I had a bit of a chat to introduce myself to Gabriel last week. I wouldn't
mind getting his feedback and maybe a bit more info on how certain processes
will be handled. I've been doc writing for a few days so hopefully i will be
able to get back into his code for a closer look. I wouldn
I was actually hoping for Gabriel's viewpoint as maintainer of ArcSDE which
supports versioned tables (for the 3rd viewpoint).
I don't really mind about the names; I think those other classes you mention
are "internal" and the FeatureSource / FeatureStore interfaces are more common
(and thus
Thanks for the input Justin: This interface with walter is based on Andrea's
work - I was hoping to see it made available at the "table" level for ease
of use; rather than at the "database" level as was done previously.
Same methods differ pile; I did not want us to accidentally make your work
har
Thanks for mentioning our work Andrea, we're definitely in the midst
of it right now. And I totally agree that 3 implementations of the
interface would be ideal.
Walter, I'd love to get some collaboration going on this. This email
a month ago would have been totally awesome, as we're getting clo
On Thu, Aug 4, 2011 at 7:25 AM, Walter Deane wrote:
> I have submitted a proposal to include a FeatureVersioning and related
> interfaces to GeoTools.
>
> These are new api classes but are based heavily on previous work in the
> versioned postgis project.
>
> The current docs that this relates too
"versioning" in wfs 2.0 is pretty lame. Doesn't allow for diffs or anything.
Basically just feature versioned navigation. It all really boils down to the
ResourceId [1] element (equivalent to FeatureId) in filter 1.1. ResourceId
has a "rid" (same as "fid") plus other attributes like version, start/
I am not as familiar with the api's but it seems that the read and write
distinction is somewhat parallel to the featuresource featurestore combination.
I can see a reason to keep separate if we wanted to have a lightweight class
for reading that reads versions but can't edit. This could be use
On 4 August 2011 19:07, Jody Garnett wrote:
> For the FeatureDiff class; we already have a concept of that name in use
> (used to store the differences for a Transaction commit() method call).
> Could we call it a FeatureDelta?
FeatureRevision ? FeatureVersionDiff ? FeatureChange ?
Michael
--
The GeoTools Query param object is based on the WFS Query request. This object
did support the idea of Query.getVersion() in the past.
I think some of that idea may be on the table for WFS 2.0 but I would need to
check. Can you look at how how WFS 2.0 represents this (see Figure 8 WFS 2.0
Inte
Interesting; thanks for writing that up.
Would you like comments / discussion here on the email list or on GEOT-3770.
For the FeatureDiff class; we already have a concept of that name in use (used
to store the differences for a Transaction commit() method call). Could we call
it a FeatureDelt
I have submitted a proposal to include a FeatureVersioning and related
interfaces to GeoTools.
These are new api classes but are based heavily on previous work in the
versioned postgis project.
The current docs that this relates too are here:
http://docs.geotools.org/latest/userguide/library/dat
30 matches
Mail list logo
