> Happened over a couple of meetings; posted a wiki page asking for > feedback etc...Can we get a link to that wiki page? I still don't quite understand the justification for this new API? I like the theory of a super class to getting coverages and features, but it seems it'd be more appropriate to do that move when both are ready, instead of just throwing something out there and hope both implement it?
The only actual use case seems to be this jpox stuff? And it feels like it's just doing it to get out of some of the FeatureSource API stuff?
At the header I see:> The basic idea is to have simple, very general interface to access and > query data that is in some way or another spatially enabled.
But isn't the definition of a feature something that is spatially enabled? It seems like this is just to get out of the burden of describing the data structure of pojos that are made with jpox? If that's the only actual use case it seems a bit heavy to stick a whole new super class at the top of our api. And it also seems like one could make a pojo -> featureType translator. Paolo from Italy once made something that does that, see: http://geotools.codehaus.org/SIS+Meta+Infrastructure+current+software The third module - SISGTUtiles:
'These classes gives a mean to copy data from Features to Java classes and vice-versa,
using a mapping like this:
Feature("road_length") <-> Class.getRoadLength() / Class.setRoadLength()
The mapping can be automatic or you can specify an arbitrary one.
Using these classes you no longer have to use feature.getAttribute() or
feature.setAttribute() (look into the DataStoreMetaSpaceLoader).
At the moment the mechanism is very simple, but it can be expanded with
many more functionalities, like Collections/Lists, bytecode generation,
etc.'
It seems like having pojos be able to expose and describe themselves as features would be _far_ more powerful than just thinning out our api to only have to render them.
void setTransaction(Transaction t);
Cool, transactions moving up to FeatureSource level.
Wasn't the only point of the FeatureStore API to signal to clients that it could handle transactions? Are we deciding to break that?
And I also see in the class javadocs:* The <code>Source</code> interface provides access to the actual data either filtered/queried or not. Access
* is purely <strong>read-only</strong> with this interface. but transaction itself says:* Provides a transaction for commit/rollback control of this <code>Source</code>.
Why do we need commit/rollback on something that's strictly read-only? Chris
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:Happened over a couple of meetings; posted a wiki page asking for feedback etc...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.This is where we were hoping for your comment Justin (well and simboss), you can make: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?- DataStore extends DataAccess - FeatureSource extends Source - FeatureStore extends StoreDo 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.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.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.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
-- Chris Holmes The Open Planning Project http://topp.openplans.org
begin:vcard fn:Chris Holmes n:Holmes;Chris org:The Open Planning Project adr:;;377 Broadway, 11th Floor;New York;NY;10013;USA email;internet:[EMAIL PROTECTED] title:VP, Strategic Development x-mozilla-html:FALSE url:http://topp.openplans.org version:2.1 end:vcard
------------------------------------------------------------------------- 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
