GSIP 9 - New Catalog

Overview

Replacing the existing GeoServer catalog with one which can provide more functionality and better scale.

Proposed By

Justin Deoliveira

Proposal Type

Core Module Change

Assigned to release

To be determined

State

Being discussed.

Links

JIRA task:

Email discussion:

Other wiki discussions:

[GEOTOOLS:Catalog Improvements]
http://udig.refractions.net/confluence/display/DEV/1+GIS+Platform
http://udig.refractions.net/confluence/display/DEV/2+Catalog
http://udig.refractions.net/confluence/display/DEV/3+Tracking+Changes

Voting History

Motivations

Integration

Recently there have been people with requirements in which a more advanced catalog implementation would be useful. Jody is specing out a project in which an organization has there own raster storage system. What would be ideal is that they could slot into our catalog without the rest of the server knowing about it. With the current system this could be tricky and potentially a lot of work.

Lazy Resource Loading

GeoServer could potentially be used to deploy hundreds or even thousands of datasets. In such a system being able to lazily connect to and load resources is crucial. With the current system all the information about a particular resource is loaded on container startup.

Remote Catalog Support

The current GeoServer catalog is stored locally on the same machine as the running server. However what about supporting a remote catalog. Or better yet backing onto an actual catalog server. Having a catalog interface in which we are able to abstract a remote catalog behind

This also falls inline with the idea of replication, or clustering a GeoServer instance across multiple machine. Having a central GeoServer instance which delegates to GeoServer instances on different machines, each one configured to serve different datasets. The catalog on the central server delegating to the catalogs on the remote servers.

Sharing Implementation

The uDig project has been running a catalog api based on our origional GeoServer data interfaces for some time. Aligning against a common interface would allow both projects to collaborate.

Reduced Number of Interfaces

Adopting a common catalog api for resource lookup and management and would allow us to retire the existing glue interfaces such as Repository (used to advertise the GeoServer data module to the validation module).

Assumptions

Proposal

Using the geotools catalog implementation in GeoServer.

Implementation

Implementation would boil down to having GeoServer code use the Geotools catalog directly. The following are some common use cases and how they would look implemented with a geotools catalog.

Adding a New Service

//get a reference to the catalog
Catalog catalog = ... 

//create a service finder
ServiceFinder serviceFinder = new ServiceFinder();

//build up connection parameters
HashMap params = new HashMap();
params.put( "server", "http://..." );
params.put( "port", 5432 );
...

//aquire the service handle
Service handle = serviceFinder.aquire( params );

//add the new service to the catalog
catalog.add( handle );

Looking Up All DataStores ( Connecting to a Service )

//get a reference to the catalog
Catalog catalog = ...

//loop through services
for ( Service service : catalog.services() ) {
     //ask if service can produce a DataStore
     if ( service.canResolve( DataStore.class ) ) {
         //connect to service / aquire DataStore
         DataStore dataStore = service.resolve( DataStore.class );

         //do something with dataStore
         ...
     }
}

Looking Up A Feature Type

//get a reference to the catalog
Catalog catalog = ...

//the qualified name of the feature type
String namespaceURI = "http://....";
String typeName = "...";

//loop through services
for ( Service service : catalog.services() ) {
     //ask if service can produce a DataStore
     if ( service.canResolve( DataStore.class ) ) {
         //loop through the members of a service
         for ( GeoResource resource : service.members(); ) {
             //ask the resource if it can produce a feature type
             if ( resource.canResolve( FeatureType.class ) ) {
                 //match the metadata of hte type we are looking for
                 if ( namespaceURI.equals( reosurce.getSchema() ) && 
                         typeName.equals( resource.getName() ) ) {

                     //connect and load the feature type
                     FeatureType featureType = resource.resolve( FeatureType.class );
                    
                     //do something with the feature type
                     ...
                 }
              }
         }
     }

Backwards compatibility issues

Risks

The geotools catalog is untested, and undocumented. The api has some problems that are yet to be resolved.