I had read the user guide. The principle is the same as the directory data store but the the requirements are more complex.
1) Need to specify the generalization distance for each set of precalculated geometries. 2) No restriction to file based data stores, reading from any data store should be possible and so on .... The geotools implementation does not make me a headache, I can offer a lot of creation variants and delegate some stuff to the application. Geoserver is the challenge. The geoserver admin interface offers me the possibility of one config url. Within this configuration I find the names of data stores and I have to rely that I find these data stores in the geoserver catalog. So far, so good. But how should I code that ?. The Catalog is defined in a geoserver package, and I am still in geotools. I am looking for a way to integrate into geoserver without special coding. Any idea ? Jody Garnett writes: > Hi Christian; please view geotools as the data access layer. > Organizing the live connections (ie datastores) into a catalog or > registery is something each application can figure out on its own; > even if they just use a singleton. > > Here is the user guide on the subject: > - > http://docs.codehaus.org/display/GEOTDOC/Managing+DataStores+using+Repository+or+Catalog > > > So any questions about catalog will need to be directed to the > application you are working within. > > However I do have a suggestion; can you present a single datastore > that makes use of several "internal" datastores to do the work? This > way you can register your single datastore in the geoserver catalog > and it will never know the difference. > > This is the approach taken by the geotools directory datastore; and > you may find it useful. Your datastore would probably only serve a > single featureSource; but would dynamically choose which internal > datasoure to retrieve a feature collection from based on the hint you > mention above. > > Cheers. > Jody > > On Tue, Apr 7, 2009 at 10:34 PM, Christian Müller > <[email protected]> wrote: >> >> Hi Andrea >> >> At the moment I try to implement an universal DataStore supporting >> Hints.GEOMETRY_DISTANCE. >> The configuration is read from an XML file (Default Implementation) >> >> Each pregeneralized feature type (or vector pyramid) has the following >> properties >> >> 1) distance >> 2) name of the geometry property >> 3) name of feature type where the pregeneralized geoms are stored >> 4) name of the datastore (e. g. for shape files, each feature typ has its >> own datastore) >> >> The problem at the moment is how to find a path from a datastore name to a >> datastore object. >> >> For geoserver, I assume the Catalog>>getDataStoreByName(String name) is my >> friend. >> >> For geotools, I did not find anything comparable except the >> FeatureSourceRepository, Clients must create a proper >> FeatureSourceRepository object and initialize the new DataStore object. >> >> And finally, if I this is correct, I have to implement a plugin mechanism >> for finding data stores. >> (I have no idea how UDig works, I assume a catalog approach) >> >> christian >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> High Quality Requirements in a Collaborative Environment. >> Download a free trial of Rational Requirements Composer Now! >> http://p.sf.net/sfu/www-ibm-com >> _______________________________________________ >> Geotools-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
