Christian Müller ha scritto: > 1) > Andrea, after the last messages I would propose: > Pass the resolution hint if you are sure that nothing bad can happen. > However you do it, I rely on getting the hint with feature types having one > geometry property with the same CRS. > > > 2) I did a quick implementation of GeneralizingFeatureSource which has a > constructor > > public GeneralizingFeatureSource(FeatureSource<SimpleFeatureType, > SimpleFeature> baseFeatureSource, > Map<Double,FeatureSource<SimpleFeatureType, > SimpleFeature>> genMap) > > Ok, if I have all feature sources and distances, life is easy. > > Some points where I need some help: > > a) > I think a better solution would be having the feature type names as > arguments for the constructor and addionally a datastore. This would avoid > creating unused FeatureSource objects. > > > b) I need some plugin mechanismn for a "GeneralizationFinder". We could > resolve this like the JDBC data store by specifing the classname of the JDBC > Driver class. A default implementation could read from an xml config file, I > need another implementation querying the database.
I still need to wrap my head around this, let's talk about it a bit more. Your specific use case assumes you have pre-generalized data available. I see this possible as either: - having multiple feature types available in a single data store that have the same structure, and whose geometry is generalized in a different view. Point in case, multiple shapefiles, multiple database tables or views - having a single feature type with multiple geometry columns, generalized in different ways (that's the way we did it for the sigma.openplans.org demo for example, and we used SLD to select the proper geometry at the proper scale) Now, where do we need this finder? And why do we need it in the first place? The most GeoServer compatible way I can think of is having a PyramidDataStore that takes as parameters a reference to another datastore and some configuration on how to merge the multiple ft/ multiple geom columns into one. This would not require any GeoServer change, thought it's probably going to require quite some fiddling with text files. Another way is to make jdbc-ng only handle this, and add an extra parameter pointing to a configuration file that specified the mapping. Yet another way, which would work only for the "single featuretype with multiple geom columns" would be to have the ResourcePool look for a generalizing feature source that can remap the feature type into one with a single geometry, and support the generalization hints. We could support the thing at the datastore level if we had a generalizing datastore wrapper, in this case we could add an extension point to the resource pool that looks for a generalizing wrapper for a given datastore. This is needed because if you have 5 resolutions, and thus 5 separate feature types, we still need to come out to the user and report only one merged feature type, and that requires wrapping the DataStore.getTypeNames method (which is used in the UI to allow you choose which feature types to add to GeoServer). The latter seems the cleanest way, thought it requires some core changes. Opinions? 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
