Adrian Custer wrote: > Hey all, > > Moving right along, I'm trying to outline the Data Storage system, that > is DataStore and its ilk. Could someone walk through the packages below > and answer my questions? [WARNING: For this work, my writeup will ignore > Catalog despite my recent emails on that subject.] > > org.geotools.data > => The javadoc example is sick: > line 1: new DataStore should give a dataStore > line 2: getSchema() is the method name > line last: spurious space in variable name > "bounds 2" > Bleck. > org.geotools.data.collection > *) How does this compare the memoryDataStore? > It should not directly compare, these implementations are available to those writing a datastore. > org.geotools.data.coverage.* > *) Grids are still accessed through the > GridCoverageExchange system? > We have no alternate API yet, simboss was trying to propose one. > org.geotools.data.crs > *) Is this really functional? It seems to be a mix of > deprecated referencing stuff and catalog stuff. > Think some of it was used by martins database implementations of crs authority. > *) Is the catalog stuff still relevant given the > existence of org.geotools.catalog? Can we remove the > deprecated CRS stuff? Can we remove the catalog stuff? > not sure what we are talking about here :-( > > org.geotools.data.directory* > *) Why is this in a plugin and not in geotools proper? > It seems to be similar to collection. > The plugin will be a datastore that serves up all the files in the directory. > org.geotools.data.jdbc* > > org.geotools.data.memory > > org.geotools.data.ows > *) Is this infrastructure for WMS and WFS, or is it > something else? > Yes. > *) Why is this here and not in a plugin? > WMS and WFS need a place to share information (this used to only be in WMS, but then WFS would not build whenever WMS failed) > *) How does this compare to the catalog based access? > It does not, these are utility classes for those implementing the client code. > > org.geotools.data.pickle > *) What's this, a sandwich topping? > Dead! > > org.geotools.data.property > *) And this, a real-estate venture? > It is the example datastore used by my datastore tutorial, and recently i was forced to use it as the only working datastore that could handle createSchema and multiple geometries. > > org.geotools.data.store > *) What's this about? > *) What is AbstractDataStore2? Can we deprecate one or > are both needed? > It is me trying to make a AbstractDataStore that will better support the way people actually use it, right now most implementations store a bunch of internal hashmaps based on a string (ie typename). > org.geotools.data.view > *) How does this compare to the use of the Query system > directly on a data store? > It is a read only "view" that end programmers do not have to know about, they can do their own "Query" against the view and not know the difference. At a technical level each request provided by a programmer is combined with the filter used to make the view resulting in a final query that is sent to the origional datastore.... the origional code here is from GeoServer.
Jody ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
