-
Notifications
You must be signed in to change notification settings - Fork 1
GSIP 9
Replacing the existing GeoServer catalog with one which can provide more functionality and better scale.
Justin Deoliveira
Core Module Change
To be determined
Being discussed.
JIRA task:
Email discussion:
Other wiki discussions:
- [GEOTOOLS:Catalog Improvements]
[http://udig.refractions.net/confluence/display/DEV/3+Tracking+Changes]
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.
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.
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.
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.
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).
Using the geotools catalog implementation in GeoServer.
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.
//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 );
//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
...
}
}
//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
...
}
}
}
}
The geotools catalog is untested, and undocumented. The api has some problems that are yet to be resolved.
©2020 Open Source Geospatial Foundation