On 10-05-25 2:46 AM, Jody Garnett wrote: > On 25/05/2010, at 6:37 PM, Andrea Aime wrote: > >> Lost you there > > Implementation details - don't matter unless you review the code. >> >> Ah, so that you can pass down to a smarter collection the work of filtering. > > Actually I am constructing an in memory feature source / feature collection > combo. > >> I'm wondering where all this is heading though. > > Replacement for DefaultFeatureCollection and DataUtilities.source( collection > ) that is optimised for rendering. > >> 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). > > We lack a long term plan; Justin started one but got stuck. I don't mind > having a long term plan that combines featuresource/featurecollection into > one however.
Well the plan was to have a single feature collection. Make it a class rather than in interface if necessary. And the implementation would be strictly a wrapper around FeatureSource, essentially the way ContentFeatureCollection does it. Having multiple feature collection implementations was never something that worked robustly in my opinion and quite honestly has made the feature access api quite a mess. To me a feature collection should just be a convenience wrapper. Having a custom one for the purposes of rendering is a different story, don't know much about that use case. Anyways, eventually I would like to dust off this plan and resurrect the work since the experiment with ContentFeatureCollection has shown some good success imo. > >> 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 pper api >> (FeatureSource family) and don't get too much screwed the day we pull off >> feature collections. > > That is what I am up to. The lean feature collection was not viable as > written; I am actually going to try and write a > featuresource/featurecollection combo that uses a spatial index. > >> 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 > > Cool. I view a FeatureCollection as a "prepaired" statement that produces an > iterator as needed. > >>> MapLayer ends up using: >>> - DataUtilities.source( FeatureCollection<SimpleFeatureType, SimpleFeature> >>> collection ) >> Right, as I said, the less we use collections, the better > Yep. > >> 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 > > In this case I am trying to make a memory based feature source; so I need to > implement. > > I will try and get FEATURE_DETACHED right and we should be good to go after > that. > Jody > ------------------------------------------------------------------------------ > > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
