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.
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.
FilterCapabilities getFilterCapabilities();
I like this, definitley a missing link in the new 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?
Object /*Description*/ describe();
Seems to be an abstraction of getFeatureType().
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.
I like the abstractions but this is completely new and different api.
And much of it overlaps with what is currently on FeatureSource /
FeatureStore.
-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!
>
--
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
