So looking down the pipe at a major api shift ( fm ), we are already planning for another ( data )? How do we sell this api change? From a client point of view I can see the advantage, but what does it buy others besides another layer of abstraction.
>From a GeoServer point of view the only gain I would see is if the grid coverage guys see this as a useful abstraction. I don't know enough about that part of the code base to comment really. Hopefully simboss can provide some feedback as well. -Justin Jody Garnett wrote: > 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 >>> >>> >>> >>> >> >> > > > ------------------------------------------------------------------------- > 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,457df9f0190156309890654! > -- Justin Deoliveira [EMAIL PROTECTED] The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- 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
