First up this is a good idea; and smarter then a general purpose directory datastore (since we never got a vector and raster api the idea of configuring all the stuff in one directory is doomed to fail).
Some notes: - Can we merge the abstract directory datastore classes move it into the data module (rather than main) - property datastore tries to handle directory and file right now - shapefile factory has the responsibility of choosing between implementations currently; so asking it to handle directories is a good idea and helps the larger story - there may be some difficulty in allowing the shapefile datastore factory to recognize a directory intended for it; at worst you could employ something similar to "dbtype" (perhaps "filetype") - good idea on shapefile renderer unwrapping things So +1 There are a couple things to discuss; and if you are pressed for time we can return to these topics "later". One practical difficulty I can see is the common practice of grouping the same information at different scales into a single directory of shapefiles. Does this practice conflict with your idea or support it? This is kind of a case where the feature pregeneralisation datastore should be employed - resulting in a single entry. Some suggestions to shoot down: - naming convention for scales, or property file in the directory, allowing shapefiles of the same content at different scales to be sorted out And one technical glitch - the same issue that occured with the pregeneralisation datastore; the fact that directory datastore is managing its own internal datastore cache. I would hate to see duplication where the user has configured shapefile directory; and then and configured a few specific entries with some extra tweaks (say for charset). Some suggestions for you to shoot down: - Is there any way to feed it a Registery and have Directory DataStore use it for storage? If the value is null it can make its own registery to hold the contents. A couple of questions: - the file data store and file finder api was introduced for directory datastore; does it still earn its keep? - property datastore was recently modifed to sort things out when a file was provided (rather than a directory) can we refactor it to work in the same manner as "directorified" shapefile datastore? On Wed, Aug 4, 2010 at 6:18 AM, Andrea Aime <andrea.a...@gmail.com> wrote: > Hi, > this year the wms shootout requires playing with a ton > of shapefiles. Setting them up one by one is tedious. > However, using the directory data store has performance > and scalability implications. > > Instead of using my time setting up a lot of shapefiles > by hand I'd prefer to fix the directory store. > The plan is roughly to: > - make the directory data store factory an abstract > one > - move the module up in supported land, it is tested > and has been used for a while > - have the shapefile store depend on it and implement > a new factory that will deal with a directory of > files. Or even better, have the same factory we have > today be able to handle both single files and directories > (it would delegate to the directory store in that case) > - have the shapefile renderer know about the directory store > and unwrap the feature sources to get the native ones > where it can work its magic > > The abstract store would just get a delegate class whose > job in life is to find the files and create the single > file stores. That would be provided along with the > constructor parameters as the factory creates the > directory store. > > This basically speaks the end of a generic, all round > directory store. And it does because practical usage > showed it makes no sense: people normally want full > control over all the params of the native stores. > For shapefiles, people have already asked more than > once that the directory store allows to control memory > mapping and dbf encoding. > > One directory can have one dbf encoding, another > one a different one. > And a directory of, say, gml files, will have other > native params to be exposed (say, for example, whether > we want a persistent schema cache or some form of indexing) > > Opinions? Quickly please, the clock is ticking :-) > > Cheers > Andrea > > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. > > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
