GeoServer : GeoServer GeoNetwork Integration
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.
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:
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.
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.
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 - http://code.google.com/p/pubsubhubbub/ Make sure the sync is active.
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.
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|