[Geotools-devel] On the catalog tutorial

Jody Garnett jgarnett at refractions.net
Sun Sep 24 18:38:59 EDT 2006


Adrian Custer wrote:
> Hey all,
>
> This email is an overview of the Catalog system with lots of questions.
>   
Hi Adrian,

Adrian: I am tagging the geodata list with this response as well (as 
there were some unanswered questions from the FOSS4G conference). I hope 
to write about these topics this week.
GeoData: uDig has a strong API used to wrap (and simplify) catalog 
services, these questions reflect the geotools back port that has been 
undertaken for a GeoServer WFS 1.1 project.
> The Catalog+Tutorial needs some love. It's almost a great resource but
> it needs some extra pointers and some reorganization.
Do we have a link?
> For example, it has no overall introduction (what i have added is incomplete/wrong).
>   
Let me try an "intro"...

The GeoTools catalog API provides access to resources listed by a 
"directory" service, usually made available as a web service. These 
remote catalogs may be usefully searched for content of interested.

We have also provided a default "local" implementation that may be used 
to manage resources used by *your* application. Most applications will 
make use of a single "local" catalog that can be used to manage 
connections to external resources. This represents a new "best practice" 
available for GeoTools 2.3, and should be used instead of holding your 
DataStore instances as a singleton as recommended for previous releases.

Relationship to the OGC CSW 2.0 specification: the GeoTools catalog 
strongly models the containment relationship between Service and 
GeoSpatial information. All other associations are handled "implicitly" 
when working with a reference to a geospatial resource.

Technical Details:
- GeoTools catalog API is centered around a single "view" of GeoSpatial 
information broken down by service. That is a GeoTools catalog contains 
references to services, which in turn list references to individual 
geospatial resources. A reference to a geospatial resource may be used 
to access a wide range of real content (from FeatureSource or 
GridCoverage to metadata and style information).
- The traditional CSW catalog does not have a central focus, although 
makes use of the following best practice: Both services and resources 
are listed but without a direct containment relationship between them. 
Containment is simply one of many "associations" that CSW has chosen to 
model separately.

> Also the "Implementing" section needs both an overview explaining the
> pieces which need to be built and a modification of the skeletons which,
> while they are great, need to be reorganized so we don't explain
> resolve( * ) before the pieces which the method requires.
>
>
>         The lines starting with a '*)' below are questions for someone
>         to answer; the rest is my understanding which may be wrong, in
>         which case hopefully someone will comment.
>
> *************************************************************************
>                    General Issues and Questions
>
>
> Creating each piece:
> -------------------
>         Catalog:
>                 - new DefaultCatalog()
>                 
>         ServiceFinder
>                 - new DefaultServiceFinder( myCatalog ) 
>                 *) new DefaultServiceFactory( myCatalog ) What's this?
>                 How is it different from DefaultServiceFinder? Is the
>                 finder to get the services originally and the factory to
>                 create the services from the catalog?
>   
Not quite sure, guessing that DefaultServiceFinder will create a Service 
handle for use with the indicated catalog. I am a little confused in that
each catalog implementation (ie Local, GeoConnectionsCanada, Google) 
needs to make use of *its* implementation of service and georesource
(operating as a light wrapper around the "records" obtained during a 
search).

Perhaps this is only support creation of Service handles that can be 
added to the local catalog.
>         Service:
>                 - via ServiceFinder.acquire(serviceURI)
>                 *) via the catalog? Does this require the use of
>                 Servicefactory.acquire(serviceURI) as in the Catalog
>                 +Tutorial (see below)? Is there another way?
>   
Service should be catalog implementation specific (see intro above), 
usually they wrap around information obtained from a search result.
ServiceFinder.aquire looks to be used only for creation of a new handle 
to add to the local catalog.

>         GeoResource
>                 - via ServiceFinder.acquire(resourceURI)
>                 *) via the catalog? Does this require the use of
>                 Servicefactory.acquire(resourceURI) as in the Catalog
>                 +Tutorial (see below)? Is there another way?
>   
Same deal, this GeoResource is a "handle" onto some search results, the 
handle is smart enough to answer a few questions:
- for web based searches the handle usually only knows how to get to the 
"metadata", including child layers for a WMS. You look at this metadata 
so you can see if you want to make the connection (by adding this 
resource to the local catalog)
- for local catalog (or local catalog searches) the handle is used to 
store connection information (so it can access the metadata and the 
connection)
>         *) Do we implicitly recommend that the user make a singleton
>         Catalog? 
>   
I would.
>         
>         *) We don't use FactoryFinder and Factories to create Catalog
>         and ServiceFinder this module. Why not? I imagined the general
>         idea for the Geotools library was always to use the
>         FactoryFinder/Factory to easily transition to a GeoAPI setup
>         where the user grabbed one FactoryFinder and could eventually
>         get everything from that (be it Geotools or GeoAPI).
>   
ServiceFinder should be at the same level as FactoryFinder - aka access 
to ServiceFactory so we can get a service handle created.
Catalog - should have a catalog finder that can be used to do a "query" 
against external catalogues.  For the "local" catalog that the
user uses as a singleton we have a bit of open question:
- just use the constructor? it is the users app and they probably need 
to take control?
- use another "finder"? So they can smoothly switch between an "in 
memory", "persisted to file", "geoserver data directory" or "local 
hibernate database" without skipping a beat?

Probably should just use the constructor for now? There are only two 
implementations (a in memory one in geotools, and a implementation 
backed on to the geoserver data directory).
For the other ones they only exist in uDig right now, and as with the 
rendering system there are conflicts involved in backporting (wider 
access == better debugging, inability to release == pain and suffering).
>         *) Are there other approaches to the creation of these objects?
>   
The Service/GeoResource objects are created as a way to make the results 
of a catalog query visible to normal programs.
> Populate the catalog:
> --------------------
>         - create the Catalog with new DefaultCatalog()
>   
To make things clear we should consider changing this to "LocalCatalog"
>         - create a ServiceFinder with new ServiceFinder(myCatalog)
>         - create a List of services with
>         ServiceFinder.acquire(serviceURI)
>   
Often a single open web service will support more then one service (WFS, 
WMS, etc...) hense the list.
>         - create a Service by getting the first element of the List
>                 *) might the List ever have more than one element?
>   
Yes, see above (happens with MapServer for example).
>         - add the service to the Catalog with Catalog.add(myService).
>
>
> Use:
> ---
>         Catalog
>                 - to search through the catalog services with .search()
>                 (see next)
>                 *) resolve( *) ? When would this be used?
>         
>         Service
>                 - to get a DataStore:
>                         e.g. myService.resolve(DataStore.class)
>   
Also used to go to other interfaces
- ServiceInfo (for dublin core metadata), morph to any metadata 
interface you got coded up
- Also OSSIM and GDAL ..
>         GeoResource
>                 - to get a FeatureSource/FeatureStore:
>                         e.g. myGeoResource.resolve(FeatureSource.class)
>                 - to get the Service parent and use that to get a
>                 DataStore.
>                         e.g. myService = myGeoResource.parent();
>                              myService.resolve(DataStore.class)
>         
>         *) Are those the general idea?
>   
Yes, but this is not specific to Feature access (or even GeoTools in the 
uDig case). You can:
- to get a GridCoverage
       e.g. myGeoResource.resolve( GridCoverage.class )
- to get at ISO metadata
       e.g. myGeoResource.resolve( Citation.class )
- to get at our normal dublin core reduced interface
       e.g. myGeoResource.resolve( GeoResourceInfo.class )

This is also where the *other* associations captured by the catalog come 
into play (ie beyond service and resource).
- to get at SLD
     e.g. myGeoResource.resolve( Style.class )
- to get at a legend icon
     e.g. myGeoResource.resolve( Icon.class )

This is really open ended, good examples of things that should be in a 
catalog are: category functions for splitting data set, stats breakdown 
of spatial information, legend icon, etc...
> Searching:
> ---------
>
> I presume searching is only on the resources obtainable from services
> contained in the Catalog. That is, search is not against any resources
> on the internet, nor against resources hard coded in the Geotools
> library's code, but against entries in the services which the user has
> added to their Catalog.
>   
That is fine, for the "local" catalog, but uDig has other 
implementations for the GeoConnections Discouvery portal and a database 
populated with a bunch of
google searches for capabilities files.
> *) Is that correct?
>   
Yes for the local catalog, but the application may have other catalogs 
representing remote services they wish to query.
> Search is presumably against the strings contained in the
> GetCapabilities documents, in the shapefiles or in the GML.
Search is against the information "shoe horned" into our dublin core 
based metadata lite classes ServiceInfo and GeoResourceInfo.
> *) Is there anywhere an indication of what is being searched within the
> different service types?
>   
uDig documentation provides this information, but it is recommended 
practice only, catalog implementations should do as good a job as possible.
> ************************************************************************
>                   Questions from the Catalog+Tutorial sections:
>   
Have not read the tutorial, need link :-)

Jody




More information about the Geodata mailing list