GeoNetwork evaluation

Overview
Recently I have installed and tried the 2.0.2 release of GeoNetwork opensource server edition. My taste is that it's a really good piece of software and could be very useful for a ton of GIS Web based applications. It can be used as a middle layer between the user and the final map, infact it has a great metedata catalogue managing service.

As mentioned in the GeoNetwork portal "GeoNetwork opensource is a standardized and decentralized spatial information management environment, designed to enable access to geo-referenced databases, cartographic products and related metadata from a variety of sources, enhancing the spatial information exchange and sharing between organizations and their audience, using the capacities of the internet. This approach of geographic information management aims at facilitating a wide community of spatial information users to have easy and timely access to available spatial data and to existing thematic maps that might support informed decision making… The main goal of the GeoNetwork opensource software is to improve the accessibility of a wide variety of data, together with the associated information, at different scale and from multidisciplinary sources, organized and documented in a standard and consistent way."

GeoNetwork consists mainly of two web applications, the first is the portal which let users query the metadata catalogue and the administrators manage it with the possibility of creating cool metadata templates and store them, the second is a Web Map client to view and represent geospatial data. GeoServer WMS is fully compatible with the client, and you can load each WMS layer into this one.

Actually metadata information have to be inserted manually against XSD schemas. There is the possibility of uploading valid XML files. They have to be ISO 19115, Dublin Core or FGDC compliant. The Z39.50 protocol should be supported to.

The architecture
GeoNetwork is a Java2 based Web Application. It works unsing a Java Web Container like Jetty or Tomcat. Jetty is alredy provided with the package and the server can be started up easily by calling batch procedures. Otherwise you can install the two web applications into a Tomcat context (or JBoss as well for example).

The architecture is based on a Framework called Jeeves. It's based on the architecture below:

 

"The browser request is received by Jeeves which, if necessary, uses JDBC to query or alter a database and build a response XML object. This object is then passed through a XSL transformation and the resulting document is sent back to the browser. The cycle repeats for every request.

Each request is mapped to a Java method, either provided by Jeeves or developed ad-hoc. Jeeves checks access privileges and provides support for multiple languages in the response XML. In the process, Jeeves handles session specific information (e.g. the user sending the request, the user's IP, cookies and so on) and passes it over to the Java method…Jeeves offers full support for multiple languages through a simple URL encoding mechanism." … and many other features are offered by this powerful framework, see the manual for more details.

Basically the usual "big Servlet" intercepts the HTTP requests and does the work against a configuration file.

The WEB.XML file is configured as follows:
…
<servlet>
  <servlet-name>geonetwork</servlet-name>
  <servlet-class>jeeves.server.sources.http.JeevesServlet</servlet-class>
 
  <init-param>
    <param-name>systemLog</param-name>
    <param-value>log/geonetwork.log</param-value>
  </init-param>  <init-param>
    <param-name>moduleLog</param-name>
    <param-value>log/modules.log</param-value>
  </init-param>  <load-on-startup>1</load-on-startup>
</servlet><servlet-mapping>
  <servlet-name>geonetwork</servlet-name>
  <url-pattern>/srv/*</url-pattern>
</servlet-mapping>
…

As said before before building the XML final response file, which is then DHTML translated by the XSL processor against the XSL template, custom Java classes are processed which represent the Controller side of this MVC pattern.

Proposals
It would not be a bad idea take a look to the Z39.50 Geoserver Servlet and see if they can be useful to make a better GeoNetwork integration.

Otherwise to have a little more automation for the loading of metadata information in GeoNetwork we could write a simple Geoserver module which reads the stored Features and Coverages metadata, traslates it into ISO 19115 compliant XML documents and send back the result to GeoNetwork allowing the latter to automatically ingest the catalogue.

Several features sould be added to the Geoserver admin interface to better handling internal metadata and its XML serialization.