Hi Chris you are running into a design principle I am trying to follow here: - access to the original format of the model (I assuming the FeatureSource subclass will step in with the FeatureType definition you are used to at a later point of time). This is the lesson I learned with all the metadata debate; proving a summary is fine but be sure to provide the original. Often GeoTools is not the source of a good model (indeed currently we cannot be); I expect the origional model to be a Class for jpox, but a next year I expect schema (hi justin!) or EClass (hi everyone else who does models).
There is no way JPox can communicate its model using our existing model (we are making use of a complex structure here, hence involvement with Justin concerning XPath etc..) The page is here: - http://docs.codehaus.org/display/GEOTOOLS/JPOX+Extension However this feedback was needed one month ago; we have stuck with our tinmeline outlined in the GTSteering document. These guys are in their last week working on documentation and tutorials etc... You are correct that Feature should be able to do what JPox does - but it does not right now. Fixing the Feature model would be far more powerful, and I think you will find this appearing (again) as focus of research in the next quarter of geotools development. Cheers, Jody > > 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: >>>> 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 > ------------------------------------------------------------------------- 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
