Proposal number : Proposal title: Collection of changes originating from ​Nationaal Georegister

Date	2009/08/24
Contact(s)	​Heikki Doeleman
Last edited	Timestamp
Status	draft
Assigned to release	2.5
Resources	The work is done in the NGR project

Overview

This proposal combines various changes originally implemented in a GeoNetwork fork in the project ​Nationaal Georegister. The changes are otherwise unrelated, but they are not very big and I think it's more efficient to bundle them in this single proposal.

The proposed changes are:

1. Performance improvement to search
2. Persistent validation results
3. Organizations
4. Service monitoring
5. Tabbed view of Metadata
6. Local rating

Another change proposal (INSPIRE support) will be separately described by ​Francois and ​Heikki. Yet another change proposal (replacing InterMap by OpenLayers) is already described ​here.

Proposal Type

• Type: GUI Change, Core Change, Module Change
• App: GeoNetwork
• Module: Search engine, Data Manager, Group Manager, Rating

Links

• Email discussions: on geonetwork-devel: ​Proposals to include NGR functionality to GeoNetwork trunk

Voting History

• None as yet

---

Motivations

The motivations for these changes are :

1. A better performance is preferred
2. The "validation status", that is to say whether or not a metadata is valid, is readily available e.g. for display in search results
3. The notion of Organization is lacking in GeoNetwork's domain model
4. The uptime percentage of services is readily available, e.g. for display in search results
5. A nice layout for the large view-metadata page
6. Only the metadata rating of users of your own GeoNetwork node is counted

Proposal

1. Performance improvement to search
In current GeoNetwork, the search from the main page works as follows: the request with search parameters is sent to GeoNetwork and is turned into a JDOM structure by Jeeves; this request object is processed in XSLT (lucene.xsl), the result of which is a different JDOM structure; this in turn is further processed in Java to create the actual Lucene query.

This proposal removes the step of XSLT processing by lucene.xsl. The function of lucene.xsl is exactly re-built in Java (LuceneQueryBuilder.java). The resulting Lucene query is not changed in this proposal.
LuceneQueryBuilder.java was developed ​test-first and as a result, it's well covered by a unit test.

A second performance gain is effected by a change to retrieving the regions data in the search service. In standard GeoNetwork, the regions are retrieved from the DB at each search request; in this proposal, it happens only once, after which the regions data is kept in memory for application lifetime.

Performance metrics from ​YourKit Java Profiler show that this change leads to a 90% performance increase of the search service as such (excluding the creation of the search results page).

2. Persistent validation results
This proposal is to run validation (XSD+Schematron) every time a metadata is inserted or changed. The result of validation is persisted in the DB. This way we can always show the current "validation status" of metadata, e.g. in the search results page.

Validation status is either "valid", "not valid", or "not determined". This last status is the initial validation status when validation has not yet run.

A validation report is also stored in the DB. It contains any XSD or schematron validation messages, a reference to the schematron file that was used, a timestamp, and if applicable a message saying that the metadata profile could not be determined.

3. Organizations
4. Service monitoring
5. Tabbed view of Metadata
6. Local rating

Backwards Compatibility Issues

1. none
2. a database change is required. SQL script to update existing DBs will be available
3. a database change is required. SQL script to update existing DBs will be available
4. a database change is required. SQL script to update existing DBs will be available
5. none
6. none

Risks

Participants

• As above