Adrian Custer wrote: > Hey all, > > I'm working on the Catalog, among other things updating: > http://docs.codehaus.org/display/GEOTOOLS/Catalog+Tutorial > as a precursor to moving it into the user manual. > > 1) Could someone who knows the system, please re-read the introduction > of that page and make sure that what I have written is correct. > Offline right now - will check later. > 2) Why are the objects with the .reslove(*) method not called Resolver > objects? > Original was called "IResolve" (as in a "interface" that says "I resolve into XXX". Changed to Resolve for geotools naming conventions. > 3) While I can see how the following gets us the result, are we merely > being satisfied with getting "any source of shapefile data"? Are we > assuming there is only one and this is the way to get it? > > ShapefileDataStore shpDataStore = > handle.resolve(ShapefileDataStore.class,listener); > This is the a "high value" API (manage my connections for me), rather then DataStoreFactory which simply creates and then the application is responsible for not wasting resources. It is much nicer to write your code against the interfaces (unless you *need* to get shapefile specific methods like build index).
So I would rather see people do the following in an intro - there is no reason to see the word "shapefile". DataStore data = handle.resolve(DataStore.class, listener); > What if we have 3 different sources of shapefile data, do we then need > to use an URI/L reference? If so, what would the equivalent statement > be? > To produce that "handle" you gave the catalog a URI. You can check the URI yourself for the handle, or you can ask the handle for GeoResourceInfo (to let you choose between handles). > 4) What would the alternative be to the Catalog system. A program could > presumably maintain a list of URI representing the services it wants to > use. Often simple programs just keep the DataStore as a singleton, GeoServer did this but ran into problems on startup. These "catalog" interface simply operate as a "list" that knows a few more tricks: - can list GridCoverage stuff as well - can list things without "connecting" - so startup is faster - is open ended, we can have additional interfaces to the same content (simple example is URI to DataStore, ShapefileDataStore, ShapeGeoResourceInfo) > When the program needed data, it could then make sure the service > is still functional, query the service and get the data. Is this > correct? Correct. > Is Catalog merely the way that geotools has chosen to solve that problem or > is there more? There is some more, mainly in terms of "searching" and finding things in the list, and by extention allowing access to: - direct metadata about the service (ie name, location, person) - indirect metadata via "association" - let me be SPECIFIC: -- easy: need to pick up the shapefile.sld file via handle.resolve( Style.class, progress ) -- hard: need to pick up the wfs feature collection, via associated wms layer via wms getStlyes() SLD via handle.resolve( Style.class, progress ) > Does the Catalog system still essentially require applications to maintain a > list of URI > for the sources of data in which they are interested? > Yes, and then it adds a heck of a lot of benefit :-) the top two pragmatic ones are: - handle.resolve( GeoResourceInfo.class, progress ) - handle.resolve( Style.class, progress ) The top two crazy "discovery" ones are: - catalog.find( URI ) - catalog.search( String query, BoundBox bounds ) And then there is what people would like - that we can do after GeoTools 2.3: - catalog.query( Filter ) > thanks for your explanations, > Thanks for the questions, there is way too much thinking behind these interfaces that is not apparent on first blush. 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
