Jody Garnett ha scritto: > Andrea had a good idea today (well most days). He points out that nobody > has implemented FeatureList properly yet ... and wonders if we can just > return a FeatureCollection. > > Thinking ... > > What do you guys think about making a SortedFeatureCollection -ie just > the assurance that the iterator is sorted in some fashion. Specifically > I am thinking of something like > (http://java.sun.com/j2se/1.4.2/docs/api/java/util/SortedMap.html) but > as an extention of FeatureCollection. > > interface SortedFeatureCollection extends FeatureCollection { > SortBy[] getOrder(); > SortedFeatureCollection subCollection( String fromId, String toId ); > } > > > I think this would be *way* easier to implemented then FeatureList - and > would be more correct. The difficulty with FeatureList takes several forms: > - By extending List<Feature> we are forced to make use of a new Abstract > Collection implementation - bleck more chance for mistakes > - By extending List<Feature> we are forced to not quite implement get( > int ) and set( int, Feature ) - while the idea is good for random > access, the set method would allow people to violate the sorting order - > basically it is a bad idea > > The downside is this - we have never gotten around to admitting that a > Feature should not be in a collection more than once. This is true in > modeling terms (ie what a feature collection means). I believe most of > our implementations treat their contents in this manner (using an > internal TreeMap sorted by FID for example). > > Regardless we should consider dropping FeatureList as I think it would > make Justin's work easier.
I agree on dropping FeatureList, not too sure we need a SortedFeatureCollection thought. I understand that it provides more metadata, yet it would add quite some burden on all datastores, since if you make up that one then FeatureSource.getFeatures(Query) where the query has an ordering set, would have to return a SortedFeatureCollection. Can we just drop FeatureList for the moment and eventually add back SortedFeatureCollection when there an explicit request for it, and resources to change all datastores? Dropping FeatureList is easy because nobody is really using it, you just remove it and the datastores stay untouched (and the FeatureCollection.sort(xxx) return type gets changed from FeatureList back to FeatureCollection). I'm convinced one should not need the extra metadata since he knows what ordering he asked for, moreover nothing prevents in memory implemetations to keep track of their sorting and avoid running a sorter for no reason if the data is already sorted as requested. What I mean is just that if you need data sorted on a certain field, you can just call sort again no? Cheers Andrea ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
