Sounds fine andrea; if possible I would like to use the data module (for something!) or kill it. I figure it is the same purpose as the jdbc module (helper classes, root implementations and so forth).
At least for the first cut do what we did with AbstractDatastore and rely on the test cases in shapefile datastore to cover the base class. You may want to teach the shapefile factory to do the actual creation (so you can reuse the param definition). It already has the task of select the best implementation based on parameters so it is a good fit. I know it is a bit rude making the factory smart (ie have logic) but it does beat people expecting to call DataStoreFinder and should be less work for you. Jody On Wed, Aug 4, 2010 at 8:25 PM, Andrea Aime <andrea.a...@gmail.com> wrote: > Jody Garnett ha scritto: >> >> 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) > > I was actually thinking to keep in in its own module and put it in > plugin. If I had to draw a parallel it would become like the jdbc > module, where you have a configurable store: instead of having > a dialect you'd have a delegate that decides which files to pick up > and how to create a store out of them (adding the extra params > specific for that store in the process, think of configuring a > directory of shapefiles that are all in the same charset, that > the user needs to configure). > >> - property datastore tries to handle directory and file right now > > Yep, I know. I would not try to touch it. > >> - 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 > > Cool. The only issue that came to mind after I wrote the mail > is that I have to keep backwards compatibility with the current > directory store for GS sake. > So I need to make a "Directory of shapefiles" factory too that > will respond to a directory url without any dbtype > >> - 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") > > Yeah, a filetype is a good idea, though I have to make it optional > for just the shape one for the backwards compatibility I was talking > about before. > >> - 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? > > Neither, it's orthogonal. If you are setting up a pregeneralized store > I expect the configuration of the latter to be explicit, since, well, > it already is (you have to roll a xml config file to use the pregeneralized > store). > >> 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 > > Nah, won't go for this one. The pregeneralized store already chose > its path. > >> 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). > > That is unavoidable, we don't have per feature type params. > >> 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. > > The pregeneralized store needed a registry because the xml config > file can point to anything, shapefiles, databases. > I don't have such problem, a file it's either in the dir and in the > expected format, or it's not. > >> A couple of questions: >> - the file data store and file finder api was introduced for directory >> datastore; does it still earn its keep? > > The current shapefile store does not use it at all. It does not earn > its keep imho, it also works against the dumbed down assumption > that a file url is all you need to create a store (shapefile experience > proves that is not true). > >> - 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? > > Sounds like a good idea. And also a nice way for you to verify how the > directory store api works. Want to take it once I made the necessary > modifications to the directory store? > > 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
