This page last changed on Sep 01, 2009 by simonp.


Many people use GeoServer and GeoNetwork in conjunction, and indeed many users of GeoServer are interested in an integrated CS-W solution. This RnD page is a scratch pad to gather requirements and ideas of how to get better integration between GeoServer and catalogs.

Primary use cases

The main basic use case is to have GeoServer and GeoNetwork stay in sync with their metadata. GeoNetwork serves up full metadata records through the CS-W protocol, and in those records there can be links to WMS/WCS/WFS data services (I believe). GeoServer serves up data as WMS/WCS/WFS, and includes some minimal metadata for each layer, like keywords, abstract, title, etc. It also includes a link to a metadata record.

Ideally the minimal metadata that is in common between the two automatically stays in sync (edit through the admin console of one and have the change reflected in the other). And a new record created in one should create references in each to the other:

  • Create a new layer in GeoServer, fill out the service metadata, and it automatically creates the metadata record in GeoNetwork, with the same service metadata. The record in GeoNetwork should automatically refer to the layer in GeoServer (so searches return the link to the data), and the online resource in GeoServer should automatically refer to the online geonetwork record (though it will start with just the same minimal metadata until someone goes in to GeoNetwork and edits). See below for some progress on this use case.
  • Create a new metadata record in GeoNetwork and upload a shapefile or geotiff, and then it prompts the user to style the data and puts in GeoServer, and have it as WMS/WFS/Google Earth. It should automatically fill out the service metadata in GeoServer, and get the proper online resource reference to itself. A proposal to add similar functionality is Publish to GeoServer Integration
  • New primary use case? With the addition of Xlink support to GeoNetwork, another use case for closer integration between GeoNetwork and GeoServer could be the componentizing of metadata records into fragments of metadata delivered by a WFS. The motivation for this use case comes from the need to fit GeoNetwork into organisations that already manage metadata in one or more databases. See GeoNetwork Composed Metadata Proposal May be useful to explore the relationship between this use case and some of the ideas in the secondary use cases below?

Secondary use cases

It could be nice to have a number of GeoServers sync with a single catalog. Allow users to stand up their GeoServer and then fill out their metadata in a second catalog.

We've also been thinking a lot about the concept of the 'user' in GeoServer, letting users comment/rate/tag maps. And then also automatically keeping track of statistics on maps, who views what, how many times a map has been viewed. See User Collaboration. Could be nice for GeoNetwork to be aware of those types of stats, and to sync between them.

Another useful piece of functionality is syncing of users/groups. Have not just an admin user who can do everything, but controlled groups who can upload and edit their section, but not everyones. Both GeoServer and GeoNetwork have users and roles/groups. Should figure out how these can integrate. Andrea can likely fill out more thoughts here.

Deployment story

We'd like to be able to tell a good deployment story all around. On the GeoNetwork side this is already pretty well handled, as GeoServer is shipped with most installations. This can be improved to have the upload data step automatically put it on GeoServer, and to integrate Styler.

On the GeoServer side, it'd be great to have GeoNetwork as a module that can be deployed, like MapFish Printing or GeoWebCache (before it was more integrated). This way users who want CSW and already have a GeoServer deployed can easily add GeoNetwork. They'd get their service metadata automatically exposed as CSW, and then could use the GeoNetwork admin interface to further add more metadata information.

Technical details

(please help)

REST API's on both sides - a change in one system triggers an active call on the other's rest api.

Syncing feeds on both sides - one system subscribes to changes in the other, and updates itself when a change happens on the other.

Could be an interesting place to leverage PubSubHub - Make sure the sync is active.


Sharing users/permissions?

JVM level integration? Any advantages to not doing this all through web apis?

Level of effort - can the work be broken down in to milestones? What are the estimates to complete them.

Progress on first primary use case

I think some progress has been made on this use case since this page was originally written (perhaps after the OSGeo hacking workshop in Bolsena in 2008?) and some further refinements are pending so it seems like this 'scratchpad' is a good place to record this (I hope) 

Firstly GeoNetwork has a WxS getcapabilities harvester which will use the metadata in the getcapabilities response to create service metadata (ISO19119) and dataset metadata (ISO19139) for layers in a WxS. The mapping between the getcapabilities xml and the metadata record(s) is dealt with using xslt. The harvester can be set to harvest on a regular interval. So the coupling between GeoServer and GeoNetwork is not quite as tight as the write up implies, but the end result is probably pretty much the same. This was work done by Francois Prunayre (GeoNetwork developer) and has been committed to GeoNetwork 2.4 (released in July 09).

At present the WxS harvester in GeoNetwork creates a complete metadata record for services and layers. This is not really optimal as the metadata obtained from the getcapabilities is often just a fraction of the useful metadata that could be in either the service or dataset records. A better solution perhaps would be to harvest the metadata from the getcapabilities info as metadata fragments. The fragments could then be xlink'd into a metadata record with the advantage that they can be updated by the harvester without disturbing the record. The harvester itself could be augmented to accept a template metadata record as part of its parameters so that on the first run of the harvester, records could be created with the fragments xlink'd into them (using the same mapping already provided by the xslts used in the existing WxS harvester). GeoNetwork does not have Xlink support at present but there are a number of sandbox versions that do (eg. GeoCat, BlueNetMEST).

Document generated by Confluence on May 14, 2014 23:00