>> I had read the user guide. Good.
>> 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 .... I understand the difference; the idea was to point out how a DataStore implementation can manage "internal" datastores which it delegates work to. I had not reason to think you were restricted to file based data stores. >> 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. I am not sure about the single config url; you should get a mess of connection parameters to deal with. However you can always point your implementation at a property file that describes what you need. This is the way the image pyramid works. >> 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 understand you are looking for a way for GeoServer to "advertise" the ability to look up FeatureSource implementations into the geotools code base; so your geotools code can look up (or refer to) some of the other "live" connections/implementations. This was the point of the Repository interface; specifically for the validation code that had the same requirement. The Repository had a very poor naming convention "datastore:::typeName" as I recall. I do not think geoserver is currently implementing this api. >> I am looking for a way to integrate into geoserver without special coding. >> Any idea ? Three Ideas: a) patch up the Repository api to match what geoserver has on now; hopefully backing it onto that new catalog? This is a lot of work :-( May but be the easiest to understand at the end of the day. b) go for a single properties file that describes the connection parameters for several datastores; use a DataStoreFinder to create your own internal datastores; and spend your time ensuring that the same connection pool is used by both the geoserver PostGISDataStore entry; and your internal PostGISDataStore entry for the same content. c) treat this as a hard configuration problem in GeoServer; make the connection parameters for your datastore ask that the internal FeatureSource instances be passed in; and then teach the GeoServer configuration api how to look up a catalog reference; and process a catalog reference into a FeatureSource when creating your instance. Option (c) is pretty darn clean; and I am hard pressed to recommend anything else - even though I personally like (a). Jody ------------------------------------------------------------------------------ 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
