Andrea, can we agree on 3 terms 1) Vertical Generalization Having multipe stuctural indentical features
2) Horizonalt Generalization Having mulitple geometry properties 3) Dynamic Generalization Delegating the work to a backend (Btw, we have to include generalization into jdbc-ng) As you pointed out, we will need some config file (I would prefer XML). Nevertheless I should be possible to read this config from anywhere else. This was my idea with a " "GeneralizationFinder". The default implementation should do the file stuff. To tell the truth, until know I spent most of my time in geotools, so I am completely new to the concept of the Catalog and the ResourcePool. The data store wrapper sounds good ,but first,we should make a data acess wrapper. I dont want to support modifications at this point in time. If we implement this wrapper class, is there a need for DataStore (DataAccess) and the correspoinding factory class ?. As you see, I am quite uncertain about the starting point, the creation of the wrapper object. Andrea Aime writes: > 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
