> it is _not_ a GML/WFS specific issue, but a General Feature Model one, > the one the Feature API is based on.
Hi Gabriel; we just have the ground work for this general feature model rolled out; and we focused on Feature and not FeatureCollection. As it stands the OGC GeneralFeature model that had these ideas about a "FeatureCollection" abstraction started to look redundant with Feature. We could model an OGC FeatureCollection as a normal Feature and be done with it. With respect to geotools FeatureCollection it really looks ready to be swallowed up by FeatureSource (we have two classes here that are to close for comfort). With this in mind try and relax a bit and discuss the feature model definition concepts; and be very careful about what is happening with the GeoTools FeatureCollections API. You may wish to review some of Justin's proposals on the topic to see the direction this API is heading in. > It just _happens_ that Ben is > facing this gap in our imnplementation due to his more complex use > case than the usual Right but we should be clear on: - yes it is a gap ... - is it a gap with the implementation of feature collection? - Or is it a gap with communication? ie Expecting FeatureCollection to take on this roll? We have not discussed how to bridge this gap yet - other than the rejection of both FeatureCollection extending Feature and FeatureCollection taking part in the general feature model (ie we know we can account for this use with a Feature and Association type). The consequences of this decision we have not yet explored. > - To make this change explicit, as part of the port from the old to > the new feature model, FeatureCollection.getSchema() should have been > _replaced_ by FeatureCollection.getContentDescriptor() or whatever it > may be called. This is a point where I would like clarification; I had thought that AssociationDescriptor was what should be used here (or is that only in the case where we are describing the relationship between a FeatureCollection and its members by having a FeatureType to describe the FeatureCollection?) > And note that this is such a need that if there's too much resistence > to add (or better replace) FC.getSchema by FC.getContentDescriptor, > Ben will still be able to do achieve his gloal by getting the > descriptor from the first feature instance in the collection.... but > we don't want to force him to that hack :) > > My 2c.- Thanks for your perspective Gabriel; this may be a case where Ben and yourself should have a breakout IRC session? Jody ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
