[GeoNetwork-devel] Proposals to include NGR functionality to GeoNetwork trunk

hello,

in the Dutch géoportail project, known as NGR (“nationaal georegister”, see http://nationaalgeoregister.nl) we have developed some things that we think might be useful to port to the common GeoNetwork trunk codebase.

Here is a list of them. I’d like your opinion on whether you agree to see it in trunk code, and any other comments you’d like to make.

(1) performance improvement to search. We greatly improved the speed of the search service, by replacing the “lucene.xsl” with an equivalent function in Java, and by retrieving the list of regions only once in application lifetime from the DB (rather than at every search request).

(2) support for INSPIRE. We implemented a number of INSPIRE-specific search parameters, along with a INSPIRE validation function. Now this may be Europe-specific, so maybe we could make it invisible in the GUI; if you’d want to display it then change a css style. It might also be nice to support INSPIRE as one of the predefined formats in a template, but I’m not immediately sure how well that goes as I don’t think there is a dedicated XSD that defines INSPIRE.

(3) validation. We implemented validation (XSD+Schematron) to run at every time a metadata is inserted or changed, and we persist the result. This way, we can always show the validation status of a particular metadata, without having to run validation on it again (we use it in the display of search results).

(4) organizations. We implemented the notion of “organization”, by fiddling a bit with the existing GeoNetwork notion of “group”. I think the SwissTopo project does things similarly. Let’s put support for organizations into GN trunk, but ideally not in this way as a hack to groups, but rather as a first-class citizen in GN’s model. In NGR we also have a dedicated “organizations” page, which allows for one-click search for metadata from a particular organization, and shows some statistics about the metadata of each organization.

(5) service monitoring. We measure the availability of all services (WMS etc.) that are advertised in the metadata. A percentage expressing the availability is shown on said organizations page and in the search results summaries.

(6) open layers. We replaced InterMap with a OpenLayers implementation. So does the SwissTopo project, and maybe other adaptations of standard GeoNetwork. Let’s put a common OpenLayers map viewer in the GeoNetwork trunk.

(7) user interface. We show metadata in their own page, rather like in the standard GN editor, and put in place a number of tabs to display just a portion of the entire metadata, depending on which tab you select. I think similar functions are developed in the Australian BlueNetMEST project, at least in the editor. Let’s find a common solution to put a “tabbed” view of metadata into trunk.

(8) local rating. In GeoNetwork, the users’ rating of metadata is broadcast to all GN nodes known to the one where the rating takes place, and the resulting rating is weighed across all GN nodes that store that same metadata that’s being rated. In NGR we didn’t want this and we simply store rating info on the one and only node where the rating happens. We could add this to trunk by way of a configuration option for admins (local / distributed rating).

Looking forward to your comments. Any of these proposed changes that gain popular support will be added to the WIKI as change proposals, so then the PSC can vote on those.

Kind regards
Heikki Doeleman

Hello Heikki, some comments inline

2009/8/1 heikki <tropicano@anonymised.com>:

Here is a list of them. I'd like your opinion on whether you agree to see it
in trunk code, and any other comments you'd like to make.

(1) performance improvement to search. We greatly improved the speed of the
search service, by replacing the "lucene.xsl" with an equivalent function in
Java, and by retrieving the list of regions only once in application
lifetime from the DB (rather than at every search request).

+1

(2) support for INSPIRE. We implemented a number of INSPIRE-specific search
parameters, along with a INSPIRE validation function. Now this may be
Europe-specific, so maybe we could make it invisible in the GUI; if you'd
want to display it then change a css style. It might also be nice to support
INSPIRE as one of the predefined formats in a template, but I'm not
immediately sure how well that goes as I don't think there is a dedicated
XSD that defines INSPIRE

support for INSPIRE take place in different modules I think:
* search (new criteria as you mentionned) in classic search and CSW
* schema ISO 19115/119
  * metadata on data & services (in trunk already)
  * multilingual metadata
* view / editing : template to edit following INSPIRE metadata IR
* validation : schematron
* thesaurus : GEMET & INSPIRE theme

Some times ago, I started one page on this:
http://trac.osgeo.org/geonetwork/wiki/InspireReadyGeoNetwork

Maybe we should work on a join proposal on that.

(3) validation. We implemented validation (XSD+Schematron) to run at every
time a metadata is inserted or changed, and we persist the result. This way,
we can always show the validation status of a particular metadata, without
having to run validation on it again (we use it in the display of search
results).

Sounds good, how do you make the validation results persistent ?

(4) organizations. We implemented the notion of "organization", by fiddling
a bit with the existing GeoNetwork notion of "group". I think the SwissTopo
project does things similarly. Let's put support for organizations into GN
trunk, but ideally not in this way as a hack to groups, but rather as a
first-class citizen in GN's model. In NGR we also have a dedicated
"organizations" page, which allows for one-click search for metadata from a
particular organization, and shows some statistics about the metadata of
each organization.

If you create a new organization notion, do you plan to manage
privileges by organization or by groups or both ? maybe groups is
enough.

(5) service monitoring. We measure the availability of all services (WMS
etc.) that are advertised in the metadata. A percentage expressing the
availability is shown on said organizations page and in the search results
summaries.

+1

(6) open layers. We replaced InterMap with a OpenLayers implementation. So
does the SwissTopo project, and maybe other adaptations of standard
GeoNetwork. Let's put a common OpenLayers map viewer in the GeoNetwork
trunk.

I agree on that, as said on previous post, people in camptocamp are
working on CSW protocol support in OpenLayers which will help a lot to
build such client side interface.
I also made a draft proposal to add a GeoExt/OpenLayers map
viewer/editor to allows to view and edit geographic extent (bounding
box and polygon) in the editor. This proposal does not make changes to
the search interface, only improve extent section in view and edit
mode of ISO19139 records. This proposal is almost ready (under testing
with Mathieu).
http://trac.osgeo.org/geonetwork/wiki/GeoEditorViewer

Then on the search interface, more work is required in order to define
a default UI for trunk based on NGR, geocat.ch and other on going
works.

(7) user interface. We show metadata in their own page, rather like in the
standard GN editor, and put in place a number of tabs to display just a
portion of the entire metadata, depending on which tab you select. I think
similar functions are developed in the Australian BlueNetMEST project, at
least in the editor. Let's find a common solution to put a "tabbed" view of
metadata into trunk.

(8) local rating. In GeoNetwork, the users' rating of metadata is broadcast
to all GN nodes known to the one where the rating takes place, and the
resulting rating is weighed across all GN nodes that store that same
metadata that's being rated. In NGR we didn't want this and we simply store
rating info on the one and only node where the rating happens. We could add
this to trunk by way of a configuration option for admins (local /
distributed rating).

+1

Cheers.
Francois

Looking forward to your comments. Any of these proposed changes that gain
popular support will be added to the WIKI as change proposals, so then the
PSC can vote on those.

Kind regards
Heikki Doeleman

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork