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
