Justin Deoliveira wrote: > Ok, I apologize for the assumption that this code came from udig. I saw > the use of generics and assumed. So now that I have more information, I > will do a method by method review. > Nope that was by way of making things clear when JPox-Spatial was implementing. > GeoResourceInfo getInfo(); > > Link to the catalog. Unfortunatley not everyone uses a catalog and the > catalog api has not yet been accepted in geotools. I guess it can be > ignored if you dont use it. > This data structure captures the information we need in order for renderer to function (ie get bounds), the other information would be used by a legend etc... > FilterCapabilities getFilterCapabilities(); > > I like this, definitley a missing link in the new api. > Or rather in the old api? > Collection /*<Content>*/ content(); > Collection /*<Content>*/ content(String query, String queryLanguage); > Collection /*<Content>*/ content(Filter filter); > > Cant seem to find reference to Content? These seem to map getFeatures(), > getFeatures(Filter).... Will the latter methods be deprecated? Or will > there be two sets of methods around? > Have a look in the StreamingRenderer, the patch should of been committed today (jesse and I reviewed last week). getFeatures etc will still be fine; they explicitly return a FeatureCollection rather then a Collection after all (if we but had Java5 type narrowing .... sigh). > Object /*Description*/ describe(); > > Seems to be an abstraction of getFeatureType(). > Indeed, although it could be Class, FeatureType, EClass etc as needed. Simboss what does GridCoverage have by way of description? > TypeName getName(); > > Something definitley missing from the current api, and something i have > desperatley wanted for some time, namespace qualified attribute names. > > void setTransaction(Transaction t); > > Cool, transactions moving up to FeatureSource level. > Part of separating out read from read-write; still want to be able to have read only access to content on a transaction. > I like the abstractions but this is completely new and different api. > And much of it overlaps with what is currently on FeatureSource / > FeatureStore. > By intention; now for the sanity check can we try making a class that implements both? It will pave the way for FeatureSource extending Source etc... We really want to be sure we did not overlap on any methods.
Thanks Justin, Jody > -Justin > > > Jody Garnett wrote: > >> Justin Deoliveira wrote: >> >>> Hi guys, >>> >>> I am looking over these interfaces and they seem to be an abstraction of >>> the datastore api. This is kind of out of left field if you ask me, >>> perhaps i missed discussion on the list about this. >>> >>> >> Happened over a couple of meetings; posted a wiki page asking for >> feedback etc... >> >>> I see links to the catalog api, but none to the datastore api. Is there >>> a link? I realize there is a need to be a bit more abstract to handle >>> things like coverages, but an entirely new api? >>> >>> >> This is where we were hoping for your comment Justin (well and simboss), >> you can make: >> - DataStore extends DataAccess >> - FeatureSource extends Source >> - FeatureStore extends Store >> >> Do you want to do that now or later? I cannot see any advantage to doing >> it now (other then sanity check) since the benefit is in terms of making >> use of TypeName etc... problems we noticed with the FM branch. >> >>> Hate to say it guys, but this smells oddly like udig just dumping >>> interfaces into geotools. With a lack of documentation as it is I hardly >>> think that we need three new interfaces in a core module like api. >>> >>> >> Has nothing to do with uDig; this is all about making sure we can run >> additional content (besides our broken feature model) through the system. >> >> Jody >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share your >> opinions on IT & business topics through brief surveys - and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> Geotools-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> >> !DSPAM:1004,457ddfbd176102095110867! >> >> > > > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
