[Fwd: Re: [OSGeodata] Re: [Geotools-devel] On the catalog tutorial]

[Jody Garnett]

Hi Jo & Adrian,
(Playing router for a couple of rounds, if only to show that the geodata 
list is not mythical)

> dear Jody, Adrian, thanks for this startling level of Java API detail. 
Sorry to throw you guys into the middle of it, I have pictures sitting here that need to go up on the web.
> On Sun, Sep 24, 2006 at 03:38:59PM -0700, Jody Garnett wrote:
> > Do we have a link?
> http://docs.codehaus.org/display/GEOTOOLS/CatalogAPI 
> http://geotools.codehaus.org/Catalog+Tutorial
>
> > Let me try an "intro"...
> Okay let me try to boil this down to novice level. 
>  
> GeoTools has a Catalog abstraction. This can point to a remote or local
> Service. A Service offers an interface through to GeoStuffOfSomeKind.
> This can be an OWS but also an SLD resource or some metadata service.
Actuallly the "point to" part is *always* a real resource (ie something that can be shown on a map).

A real CSW2.0 catalogue stores all kinds of things (like SLD and metadata), the GeoTools api lets you have
access to this stuff, but only with respect to something concrete and visible.  
> Inside Service you do the lifting (via GeoAPI?); model / protocol are
> abstracted away from the happy uDig user- CSW, OWSCat, OAI-PMH, you don't mind.
Indeed, if the casual java programmer has to know that stuff then we messed up.
> Then you have your own ServiceInfo/GeoResourceInfo internal model 
> which is a Dublin Core based reduced geometadata subset. 
Really we defined it the other way around:
1) we want to find stuff to show on the screen
2) what is it we want to search when we look for stuff to show on the screen
3) now that we have a list, lets steal names from DublinCore
> - How is the local catalog built? From usage? Can it be externalised?
>   E.g. posted to a remote indexing service? Would this be actually useful?
The local catalog is "just a tool" a programmer can use to manage their connections to geostuff, so
they build it via programming. We *do* externalize this for the uDig project (into XML right now), and
we do externalize it for the GeoServer project (into a series of directories with XML files). Setting them
up a small database instead would give both projects an excuse to collaborate.
> > Also used to go to other interfaces
> > - ServiceInfo (for dublin core metadata), morph to any metadata 
> > interface you got coded up
>
> http://udig.refractions.net/docs/api-geotools/org/geotools/catalog/defaults/DefaultGeoResourceInfo.html
>
> Okay this is becoming clearer. What I have been trying to implement on
> the server/broker side looks a lot like GeoResource, the OSGeo draft
> metadata model like GeoResourceInfo and what Tom wants for OWSCat more
> like ServiceInfo. It is great that you have all this going on the
> client side, I want to be able to syndicate it though.
Two sides of the same coin, we just get the fun of making it look easy.
> k thanks,
> jo
Cheers,
Jody