Jody Garnett ha scritto: > HI Andrea: > > I have been finally responding to a long standing wish/issue on the user list > .... a replacement for DefaultFeatureCollection. > > I have done two implements: > - TreeSetFeatureCollection (a straight up copy of DefaultFeatrueCollection so > we can preserve it for test cases) > - ListFeatureCollection - starting from the lean feature collection in > https://jira.codehaus.org/browse/GEOT-3091 and then mostly ignore it > > Then I created CollectionFeatureSource: > - using the same kind of design as ContentFeatureSource (could not use it > directly since it is defined "downstream, along the way I query processing > code and added to DataUtilities for reuse).
Lost you there > - CollectionFeatureSource wraps around an existing SimpleFeatureCollection > - goes through all the feature collection wrappers needed to process a Query > (including sorting) > - ending in a wrapper that will call back to the containing > CollectionFeatureSource for subCollection( Filter ) and sort( SoryBy ) Ah, so that you can pass down to a smarter collection the work of filtering. I'm wondering where all this is heading though. Like, collection usage in GeoTools should be discouraged, otherwise we may have a hard time ripping it off the code base in the future (which I think it's the long term plan). The thing about having a fast collection was for users that want to store feature in memory. So I welcome a lean feature collection. I think it would be better to have an equivalent in memroy feature store though, so that people are somewhat forced to use the proper api (FeatureSource family) and don't get too much screwed the day we pull off feature collections. > And next I will go in and try and make one using a SpatialIndex for storage. > > So here is what I want to ask you - what is the renderer doing :-) The renderer is sort of ahead of times already, the usage of collections is at the minimum terms, trades Featuresource and iterators, passing through the collection only as a middle man > MapLayer ends up using: > - DataUtilities.source( FeatureCollection<SimpleFeatureType, SimpleFeature> > collection ) Right, as I said, the less we use collections, the better > Right now this has been implemented as: > > CollectionDataStore store = new CollectionDataStore(collection); > return store.getFeatureSource(store.getTypeNames()[0]); > > And I have been experimenting with: > > SimpleFeatureCollection simpleFeatureCollection = simple( collection ); > CollectionFeatureSource source = new > CollectionFeatureSource(simpleFeatureCollection); > > So can you describe what happens next? > - How is FEATURE_DETACHED used? Hints are another good reason for not using collections. Collections have no hints advertisement abilities, and the renderer uses them. Anyways, that hint in particular lets the renderer know it can modify geometries in place without cloning them. Normally that hint is true, but for example the caching source does not clone the features. Given the choice of cloning the entire feature or just the geometry, it's better to just clone the geometry, and that's what the renderer will do when that hint is not advertised in the feature source. > - What should I try and optimise? Pass down all hints as possible. Which really means, reduce to the bare bones the usage of collections and try hard to use sources instead Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
