Hi Andrea, Justin wants to try a slightly different plan for getting the FM branch sorted. He talked at me a bit about it on saturday - basically we have the FM model (the baby) and a bunch of QA fixes (the bathwater). Since the QA fixes are what is really taking so long ... he wants to try to take the builders over, have them work with the existing model. And then make the new model available step by step. I am still waiting for the exact plan :-)
I do understand the tradeoff, the QA fixes were a lot of what made FM branch so much more fun & sane. The feature model is kind of boring yes it lets us do more, but until I get it in the hands of Rob A (or get some time to work on a fun DataStore) it will not be much different. Jody > - 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. See above, basically I would like the DataStore implementors to explicitly say what they are doing with a dependency on either SimpleFeatureFactory or FeatureFactory. To answer your questions AbstractDataStore2. > - 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 I figure FeatureReader/FeatureWriter are at the same level as Attribute Readers ... aka *low*. They still serve a useful contract with AbstractDataStore (and thus have a place), but they should no longer be in the face of end users. To sum up they are part of the data module (to help implemenetors), but not part of the API module (focused on users). > - visitor -> aka reuse the same feature object instead of re-creating > it over and over right? Correct - *and* any other crazy thing you can think of like that caching simboss was talking about. > - "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? Sure - a DataStore implementor can define the class that they return for a FeatureCollection, and they can get very specific and optimized when needed. Filter is *just* data and always will be. An real example would be a FID Filter verses a ShapeFileFeatureCollection that remembered the exact file offsets. > - 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) Um check out WFS 1.1, yes we do get some join parameters - they do indeed use filter with a/x == b/y where a and b are the collections being joined. Really a case where we would need to split the Filter supplied in a Query up to capture these. As for inner, outer, right, left we can do what WFS does for a start. > - subCollection( Filter ) - used to temporary hold a Filter to > paramartize an operation like clear() > Ah hem, where clear() is really a datastore deletion? Indeed. > *) http://docs.codehaus.org/display/GEO/Feature+Model > - Hum, missing pictures here? Yeah, need to hunt down stable links - please look at the javadocs. > *) > 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?) Lets take this up after you find the pictures, the discussion linked to is outdated, and combined with Bryce's feedback produced a different picture with a lot less concessions to XML. You will find very little duplication - at Justin's insistence, get it right first - make it easy later. > - (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) Yeah, so featurecollection.close( iterator ) and featurecolleciton.purge() are the best we could do. > *) 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? It is not, it is one of the things we succeeded in doing, not sure I finished that section as I was not getting feedback - so I went to the GeoAPI list. > - 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? It is hard to figure out from there code, my best recollection is they have the api but do not use it. > - (Shapefile) "entry in shp file, using shx to find a row in dxf file" > Hum, dxf? Maybe you meant dbf? yep. > - (Geoapi 2.0) "FeatureType is mustable?" lol! spelling really should be a mutable art form. > 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... Thanks Andrea - and thanks for the careful reading. 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
