Hi Andrea, Glad to see some interest in FM. Jody will be able to better answer your questions but I thought I would throw my two cents in on a couple of things.
I think for now there wouldn't be any "data" support for complex content, just the model. Not until we rescue gabriels complex-features branch anyways. One of the problems with the datastores imho is that they rely heavily on base classes such as AbstractDataStore and JDBCDataStore to get out of doing work. Being the postgis module maintainer I can tell you this results in some pretty ugly "object-oriented" code. I think what is needed is a better internal api for datastores. I think what is meant by "FeatureCollections are magic optimized datastore specific..." is that now every datastore uses the same FeatureCollection implementation which is based on a number of layers of abstraction, AttributeIO, etc... The intention is that every datastore should be implementing its own FeatureCollection. For instance with postgis you could have a featureCollection directly backed onto a JDBC result set, instead of having to go through a number of other interfaces to get there. This would result in faster and easier to read code imho. -Justin Andrea Aime wrote: > Hi Jody, > I'm reading the FM docs available online to try and understand the next > storm that will hit geotools trunk. > > I'm writing down questions as I go, so sorry if the mail is not well > organised. > > *) http://docs.codehaus.org/display/GEOTOOLS/Feature+Model+Branch > - AbstractDataStore is focused on simple types. Ok, so what is focused on > complex ones? Most data stores do derive from AbstractDataStore and rely > on it to manage [boilerplate/generic non optimized] code. > - FeatureReader/FeatureWriter -> shall we remove them? Having reader, > iterator > and visitor would confuse quite a bit users... oh, somewhere we should > still have > attribute readers too :-p > - visitor -> aka reuse the same feature object instead of re-creating it > over and > over right? > - "FeatureCollections are magic optimized datastore specific pearls of > performance (so hold onto them rather then the generic Filter that > created them)" > care to explain the last part of the sentence? > - and soon /join( collection ): /well, I do hope we'll have some more > parameters to control > the type of join (inner, outer, right, left) and the join condition > (sounds like a filter here) > - subCollection( Filter ) - used to temporary hold a Filter to > paramartize an operation like clear() > Ah hem, where clear() is really a datastore deletion? > > > *) http://docs.codehaus.org/display/GEO/Feature+Model > - Hum, missing pictures here? > > > *) http://docs.codehaus.org/display/GEOTOOLS/Feature+Model+Design+Discussion > - (Feature Attribute Access Design). The Attribute interface is a little > scary, sure you > do want to keep a reference to the attribute name in the Attribute > class? That's supposed > to be just a value, the name is part of the metadata (that is, you're > violating the DRY principle > here?) > - (Feature model collection design, interface samples): why a > FeatureCollection should close > the iterator? Sholdn't it be better to have the close operation on > the iterator itself? (ok, this > requires an iterator subclass) > - btw, I agree child referencing its parent it's not a good idea (in my > opinion at least). If you > need to get to its parent, have a locator object that allows you to > traverse the containment > hierarchy the other way around (see Domain Driven Design too). > > *) http://docs.codehaus.org/display/GEOTOOLS/Evaulating+Modeling+Options > - hum, being an XML ignorant, why is XPath too difficult to implement on > the feature model? > - multiplicity: is it required by GML3 to have a variant schema, that > is, rows with more attributes? > (as opposed to one or more multi-valued attributes?) > - (Comparison) Degree seems to have both multiple inheritance and > name/index access. How is so? > - (Shapefile) "entry in shp file, using shx to find a row in dxf file" > Hum, dxf? Maybe you meant dbf? > - (Geoapi 2.0) "FeatureType is mustable?" lol! > > That's all folks. Sorry to read these one year late, but what can I do, > I have to attack the FM > branch somewhere, somehow... > > Cheers > Andrea > > > > > ------------------------------------------------------------------------- > 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,44d5e12e116934750375898! > -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
