Re: [Geotools-devel] FeatureAccess proposal ready

> > > As for the no interfaces/generify debate, my generics abilities > > are probably lower than yours. Can anyone come up with a counter > > proposal using the hybrid approach so that we can have a look > > at it instead of talking about vapourware? > > gonna try to figure it out in real code the

Re: [Geotools-devel] FeatureAccess proposal ready

On Thursday 07 February 2008 03:35:11 pm Justin Deoliveira wrote: > > I see your point, we're on the same boat here. Ie just the place where > > our proposals join? > > So are you comfortable with org.geoapi.feature.FeatureCollection for the > > general case and org.geotools.feature.FeatureCollecti

Re: [Geotools-devel] FeatureAccess proposal ready

> I see your point, we're on the same boat here. Ie just the place where our > proposals join? > So are you comfortable with org.geoapi.feature.FeatureCollection for the > general case and org.geotools.feature.FeatureCollection for the simple > feature case? > once you're proposal goes ahead yo

Re: [Geotools-devel] FeatureAccess proposal ready

Hi Justin, On Thursday 07 February 2008 03:11:56 pm Justin Deoliveira wrote: > I just thought i would chime in again with my thoughts on7 > FeatureCollection. I am indifferent to having a new FeatureCollection > interface. My main concern is with the implementation of > FeatureCollection. As long

Re: [Geotools-devel] FeatureAccess proposal ready

I just thought i would chime in again with my thoughts on FeatureCollection. I am indifferent to having a new FeatureCollection interface. My main concern is with the implementation of FeatureCollection. As long as it is implemented *once*, and in terms of FeatureSource i am happy. Past that w

Re: [Geotools-devel] FeatureAccess proposal ready

Gabriel Roldán ha scritto: >> Hi, >> here is my feedback. >> >> FeatureAccess name must be killed, it's too easy to mistake it as part >> of the FeatureSource, FeatureSource, FeatureLocking familiy. >> ComplexDataStore may not sound nice, but it's at least consistent >> with the other names you're

Re: [Geotools-devel] FeatureAccess proposal ready

> Hi, > here is my feedback. > > FeatureAccess name must be killed, it's too easy to mistake it as part > of the FeatureSource, FeatureSource, FeatureLocking familiy. > ComplexDataStore may not sound nice, but it's at least consistent > with the other names you're coming up with. right. A couple op

Re: [Geotools-devel] FeatureAccess proposal ready

Gabriel Roldán ha scritto: > Hi all, > > the proposal to extend the geotools data access interfaces to allow working > with GeoAPI Feature and FeatureType as a superset of the current API based on > SimpleFeature and SimpleFeatureType is ready for your evaluation. > > The URL is >

Re: [Geotools-devel] FeatureAccess proposal ready

Justin Deoliveira wrote: > Good sum up of the tradeoffs Gabriel. I think you are right in that a > hybrid type hierarchy - parameterization might be the best way to go. > It can potentially save us some method overloading and additional > interfaces which is really my problem with it. I agree ab

Re: [Geotools-devel] FeatureAccess proposal ready

Good sum up of the tradeoffs Gabriel. I think you are right in that a hybrid type hierarchy - parameterization might be the best way to go. It can potentially save us some method overloading and additional interfaces which is really my problem with it. > 1) Introducing generics and the required

Re: [Geotools-devel] FeatureAccess proposal ready

Thanks Gabriel - that is a great post. > 3)Introducing a type hierarchy with parametrized types for method parameters > may well worth a try, as it would cover all the use cases with no > overloading. > I have not tried writing this one up yet; should we try and see if the result is Okay? > F

Re: [Geotools-devel] FeatureAccess proposal ready

Sorry I am under the assumtion here that CommonSuperClassThing is the templated DataStore ... - and that DataStore is a subclass with all the blanks filled in so that SimpleFeature / SimpleFeatureType client code does not break - ComplexDataStore is a similar thing with the blanks filled in for

Re: [Geotools-devel] FeatureAccess proposal ready

On Thursday 07 February 2008 01:15:52 am Justin Deoliveira wrote: > > When I introduce generics to this picture I end up with more classes? We > > best get specific... > > - CommonSuperClassThing > > - ComplexDataStore extends CommonSuperClassThing > > - DataStore extends CommonSuperClassThing > >

Re: [Geotools-devel] FeatureAccess proposal ready

> When I introduce generics to this picture I end up with more classes? We > best get specific... > - CommonSuperClassThing > - ComplexDataStore extends CommonSuperClassThing > - DataStore extends CommonSuperClassThing Why do we have to add new classes? The only reason I would see is for conveni

Re: [Geotools-devel] FeatureAccess proposal ready

> > When I introduce generics to this picture I end up with more classes? We > best get specific... > - CommonSuperClassThing > - ComplexDataStore extends CommonSuperClassThing > - DataStore extends CommonSuperClassThing The real problem with that approach is there's a fundamental story we cannot

Re: [Geotools-devel] FeatureAccess proposal ready

Justin Deoliveira wrote: >> There were two hesitations: >> - when Gabriel started generics were not needed; where he ended up it >> looks like they may be required > I dont understand what this means. It means he was only focused on: FeatureAccess.getSchema(): FeatureType DataStore.getSchema(): Si

Re: [Geotools-devel] FeatureAccess proposal ready

>> > Sorry, but a deadline is no excuse to crap all over the api. I would > rather if people have these sorts of deadlines they hack outside of > public api. And for deadlines I assume you mean gabriel and the wfs > datastore for the fgdc project. One of the main reasons topp applied for > fun

Re: [Geotools-devel] FeatureAccess proposal ready

My problem with idea is that getURI doesn't do much. An extra couple methods are too hard to implement... So I think it gives some decent metadata with out too much cost. Otherwise all we'll ever get it the URI and that's one step from useless. Keywords, etc... are quite handy if you:

Re: [Geotools-devel] FeatureAccess proposal ready

Jody Garnett wrote: > Justin Deoliveira wrote: > Nope it was my responsibility and I carefully updated the javadocs; if > that was not good enough I need to hear about it. You were correct that > the interfaces were not clear; please review what is there now (rather > than the way things were ye

Re: [Geotools-devel] FeatureAccess proposal ready

Justin Deoliveira wrote: >> You did not vote; hence the +0. > Because I gave negative feedback expecting the proposal to be > reworked. Apparently i dont understand the process. It is the > responsibility of the person who gives feedback to update the > proposal? That does not work for me. Nope

Re: [Geotools-devel] FeatureAccess proposal ready

Jody Garnett wrote: > Justin Deoliveira wrote: >> Here is my feedback: >> >> * getInfo() >> > Already done. It was ServiceInfo and ResourceInfo. Proposal page > explains we are not talking about catalog here. Yeah, but you took the catalog interfaces and put them on the datastore api. Just bec

Re: [Geotools-devel] FeatureAccess proposal ready

Bad idea for you Gabriel just remove the word Complex - FeatureReader extends Reader - DataStore extends Data - FeatureSource extends Source - FeatureStore extends Store - FeatureLocking extends Locking You are correct that naming is the hardest part. > Indeed that was my first intention but go

Re: [Geotools-devel] FeatureAccess proposal ready

Justin Deoliveira wrote: >> hmmm.. I'm not even pmc, but as it got 3 positives and no negatives I guess >> that's why it went forward... still, feel free to ask who you need to ask >> about that, I was told what I've been doing with WFS client code where >> duplicating that proposal work (that i

Re: [Geotools-devel] FeatureAccess proposal ready

Justin Deoliveira wrote: > Here is my feedback: > > * getInfo() > Already done. It was ServiceInfo and ResourceInfo. Proposal page explains we are not talking about catalog here. > I dont know why my vote says +0... i remember having serious > reservations on this one. Perhaps it is because i

Re: [Geotools-devel] FeatureAccess proposal ready

> * FeatureAccess > > I dont know how I feel about a new interface. I think we may want to > consider a different solution with generics. Not that I love generics > but in this case they may better apply. I assume gabriel has thought > about this route? Indeed that was my first intention but got s

Re: [Geotools-devel] FeatureAccess proposal ready

> > hmmm.. I'm not even pmc, but as it got 3 positives and no negatives I guess > that's why it went forward... still, feel free to ask who you need to ask > about that, I was told what I've been doing with WFS client code where > duplicating that proposal work (that is, providing information t

Re: [Geotools-devel] FeatureAccess proposal ready

On Wednesday 06 February 2008 08:18:41 pm Justin Deoliveira wrote: > Gabriel Roldán wrote: > > Thanks for the feedback, > > > > though I'm not sure why you're complaining about getInfo() as it has > > nothing to do with this proposal? > > like it is a past proposal you can make your voice sound for

Re: [Geotools-devel] FeatureAccess proposal ready

Gabriel Roldán wrote: > Thanks for the feedback, > > though I'm not sure why you're complaining about getInfo() as it has nothing > to do with this proposal? > like it is a past proposal you can make your voice sound for that one.. > See the before/after pictures, getInfo() is in the before bec

Re: [Geotools-devel] FeatureAccess proposal ready

Thanks for the feedback, though I'm not sure why you're complaining about getInfo() as it has nothing to do with this proposal? like it is a past proposal you can make your voice sound for that one.. See the before/after pictures, getInfo() is in the before becuase it is in the api before the in

Re: [Geotools-devel] FeatureAccess proposal ready

Here is my feedback: * getInfo() I guess this is a little off topic of this proposal and related to the last. But I was surprised when i saw it go through today. I remember having voiced feedback about those interfaces not being fine tuned enough. All those attributes: schema, publisher, title

[Geotools-devel] FeatureAccess proposal ready

Hi all, the proposal to extend the geotools data access interfaces to allow working with GeoAPI Feature and FeatureType as a superset of the current API based on SimpleFeature and SimpleFeatureType is ready for your evaluation. The URL is