> What I would like to do is this: Remove FeatureCollection from the > factory interface. If an Feature implementation happens to have a > "members" association it may very well decide to implement the > FeatureCollection interface as well in order to provide some nice > methods for java programs. The end result is similar to SimpleFeature - > because we know we have an association "members" some extra methods can > be provided. > Yeah, thats all i did was remove it from the factories.
> Andrea mentioned fixing up the Query interface to take Name, can we do a > sanity check on Query to make sure it agrees with this new feature model? Hmmm... not sure about this, Wont this kill the ability to use xpath? >> 1. The SimpleFeature interface now looks pretty much exactly like the >> geotools Feature interface >> > I would like to see the "geometry" methods be consistent with the > getAttribute()/getProperty()" > - getAttribute( Name ) > - getGeometryAttribute( Name ) > - getGeometryProperty( Name ) > - getProperty( Name ) Can you include return types of the methods please :) >> > We had considered getValue(Name) and getGeometryValue(Name) but that > would but the useful methods at the end ... >> And that is it. Let me know what you all think. Let the second round of >> review begin. >> > Fun ;-) Justin you better put a deadline on the second round of review. Ideally we can get everyones concerns addressed and out in the open by Friday... but that may be pushing it. > > Great work Justin, > Jody > > !DSPAM:4007,46e97e18154846491211187! > -- Justin Deoliveira The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
