[GeoNetwork-devel] GeoNetwork 2.1.0 alpha-1

GeoNetwork GeoNetwork Developer
1

Hi Developers,

My name is Michael Gannon, I work with another mailing list participant of yours, John Hockaday, at Geoscience Australia and he recently put me onto your product Geonetwork. I hope my questions don’t seem too little trivial for the developers list but I thought I may as well put my toes in the water eventually and see how it works.

We have been looking into using Geonetwork as a prototype solution for a metadata entry tool to be integrated into our larger emerging registry platform. Geonetwork has most of the functionality that we are looking for and John Hockaday seems to have been pleased with the ISO-19139 support that it provides.

I have been playing with Geonetwork over the last week or so and have just recently upgraded my source to the new 2.1.0 alpha-1 version, but I am facing some problems, well really only one problem that is in my way at the moment and I was wondering if you could please confirm if this is a known problem in this particular release or if perhaps my tinkering around might have dislodged some logic.

When I try to add a metadata record under ISO 19115 it throws a null pointer exception and redirects to the error.xsl with the resulting stack-trace pointing to the EditLib class:

NullPointerException

java.lang.NullPointerException

at org.fao.geonet.kernel.EditLib.expandElement(EditLib.java:481)

at org.fao.geonet.kernel.EditLib.expandTree(EditLib.java:420)

at org.fao.geonet.kernel.EditLib.addEditingInfo(EditLib.java:137)

at org.fao.geonet.kernel.DataManager.getMetadata(DataManager.java:439)

at org.fao.geonet.services.metadata.GetEditableData.exec(GetEditableData.java:72)

I noticed that in the notes section of your alpha release you said ‘- the iso 19139 can be viewed but not edited’ does this also apply to the ISO-19115?

I have also been working to decouple the Intermap application from the metadata tool such that I might be able to integrate IMF (our current corporate mapping application of choice). I have written a small wrapper around the IMF libraries that will launch the application from a HTTP request with the service URL and service name provided from Geonetwork and I have manipulated the metadata-iso19115.xsl and metadata-iso19139.xsl to call my predetermined URL instead of the Intermap libraries (perhaps it is here that I have dislodged the logic for entering metarecords under these schemas). Perhaps a little left field, but is the work currently being undertaken in Geonetwork going to strengthen its coupling with Intermap or is there a move try to implement mechanisms to decouple these two applications.

I can appreciate that you have more important things to do than reply to help requests all day so any assistance at all would be highly appreciated and I look forward to contributing more to this project as our work ramps up in the coming months.

Cheers,

Michael Gannon.

-----Original Message-----
From: geonetwork-devel-bounces@lists.sourceforge.net [mailto:geonetwork-devel-bounces@lists.sourceforge.net] On Behalf Of Andrea Carboni
Sent: Saturday, 21 October 2006 9:58
To: GeoNetwork Users
Cc: geonetwork-devel@lists.sourceforge.net
Subject: [GeoNetwork-devel] GeoNetwork 2.1.0 alpha-1

Hi all,

from the project page you can download the first alpha of geonetwork 2.1.

After installing it, remember to use the ‘admin’/‘admin’ as username and

password because what you provide in the installer gets discarded (we

started to refactor the installer).

here is a list of what is new:

  • Added Lucene FuzzyQuery support

  • Added catalogue services for the web 2.0.1

  • Added ISO19115 CSW 2.0.1 output stylesheets (thanks to Steven Smolders/Stefaan Desender)

  • Added RSS search services

  • Added chinese localization (thanks to Enri Zhou)

  • Added log4j to both jeeves and geonetwork

  • Logs moved into jetty/log folder. Now old logs are archived

  • Added web/WEB-INF/db/data.tgz. This is an empty McKoi database ready for use,

very usefull to users that do a cvs checkout/update: simply unpack where it is.

  • Added localization of categories, groups, regions, operations and profiles

  • Added an Ajax wen interface to configure harvesting

  • Removed uuid-2.1.0.jar: used java 1.5 builtin UUID class

  • Removed jaxen: used java 1.5 classes

  • Increased connection pool to 10 connection to allow harvesting tasks

  • Added more information to users (email, address, organisation etc…)

  • Fixed the metadata-util.xsl stylesheet so that GeoNetwork can run on Java 1.6

(thanks to Andrew Davie)

  • Added ‘author’ to the RoleCd codelist

  • Harvesting engine totally rewritten to provide more flexibility

  • Now the search engine works with Chinese language (thanks to Enri Zhou)

  • Fixed bug with user list: if the user is an Administrator but with id other

than 1 only a subset of the groups where shown

  • Fixed bug with thumbnails stylesheet: now the ‘back’ button is correctly

shown

  • Fixed validation bug when adding a new metadata

  • Fixed problem with IPv6 protocol: geonetwork was unable to handle the

0:0:0:0:0:0:0:1 local address.

  • Fixed a security hole: using sql injection was possible to login into geonetwork

  • Fixed “Services is not a subcontext” exception with Z39.50

  • Added reconnection patch for MySQL (thanks to Enri Zhou)

  • Fixed a security hole in user management : a user admin could gain admin privileges

Some notes:

  • the iso 19139 can be viewed but not edited

  • the new harvesting interface works but the server is not completed so now

you cannot harvest from anywhere

  • the CSW has some problem that we fixed after having created/tested the jar file

We have planned to release a new alpha in November (first or second week) with

some more bugs fixed and a few other advances.

Cheers,

Andrea

Using Tomcat but need to do more? Need to support web services, security?

Get stuff done quickly with pre-integrated technology to make your job easier

Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo

http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

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

2

Hi Michael,

I have been playing with Geonetwork over the last week or so and have just
recently upgraded my source to the new 2.1.0 alpha-1 version, but I am facing
some problems, well really only one problem that is in my way at the moment
and I was wondering if you could please confirm if this is a known problem in
this particular release or if perhaps my tinkering around might have
dislodged some logic.

When I try to add a metadata record under ISO 19115 it throws a null pointer
exception and redirects to the error.xsl with the resulting stack-trace
pointing to the EditLib class:

<error id="error">
  <exception>
    <message />
    <class>NullPointerException</class>
    <stack>java.lang.NullPointerException
        at org.fao.geonet.kernel.EditLib.expandElement(EditLib.java:481)
        at org.fao.geonet.kernel.EditLib.expandTree(EditLib.java:420)
        at org.fao.geonet.kernel.EditLib.addEditingInfo(EditLib.java:137)
        at org.fao.geonet.kernel.DataManager.getMetadata(DataManager.java:439)
        at org.fao.geonet.services.metadata.GetEditableData.exec(GetEditableData.java:72)

I noticed that in the notes section of your alpha release you said '- the iso
19139 can be viewed but not edited' does this also apply to the ISO-19115?

The ISO-19115 should work fine, both in visualization and editing because it did not change.
Now I cannot track the error because we made some changes to that class but if you send
me the metadata you used I can try to do the same.

Anyway, don't expect great stability or functionality completeness. We made this release
because some users have problems doing a cvs checkout.

PS: we moved to subversion, so use that tools now if you want to be updated.

I have also been working to decouple the Intermap application from the
metadata tool such that I might be able to integrate IMF (our current
corporate mapping application of choice). I have written a small wrapper
around the IMF libraries that will launch the application from a HTTP request
with the service URL and service name provided from Geonetwork and I have
manipulated the metadata-iso19115.xsl and metadata-iso19139.xsl to call my
predetermined URL instead of the Intermap libraries (perhaps it is here that
I have dislodged the logic for entering metarecords under these schemas).
Perhaps a little left field, but is the work currently being undertaken in
Geonetwork going to strengthen its coupling with Intermap or is there a move
try to implement mechanisms to decouple these two applications.

I can appreciate that you have more important things to do than reply to help
requests all day so any assistance at all would be highly appreciated and I
look forward to contributing more to this project as our work ramps up in the
coming months.

Cheers,
Michael Gannon.

Decoupling geonetwork from intermap is another planned activity. From my point
of view the projects (and so the installers) should be kept separate and geonetwork
should allow the user to configure the external map viewer to use. Up to now we
provided a unified installer to keep things simple for users but I think that 2 separate
installers are better.

I would like to start a discussion on how to develop such a plugin mechanism.
In detail, we should address these issues:

- how to store the map viewer information into the metadata. Which format to use
  and where to put it. Is the actual one the best solution?

- which parameters of the map viewer should be configurable inside the metadata.

- which parameters geonetwork should allow to configure to call the map viewer.
  I'm thinking about an admin form with some options to specify the link to the map
  viewer.

- how to start the map viewer.

Cheers,
Andrea

3

Hi Andrea,

On Oct 24, 2006, at 2:29 PM, Andrea Carboni wrote:

Decoupling geonetwork from intermap is another planned activity. From my point

of view the projects (and so the installers) should be kept separate and geonetwork

should allow the user to configure the external map viewer to use. Up to now we

provided a unified installer to keep things simple for users but I think that 2 separate

installers are better.

Yes, decoupling should be cleaner than it is now and a plugin mechanism is required to do that.

In fact, there should be a handler mechanism that is extensible to the different types of services that the metadata could describe, not only WMS.

I could think of a configuration through small XSL templates that are in a separate folder and that do the mapping of parameters into a target URL.

Such XSL templates can be generic (for each metadata type) and use parameters stored in the database so they are configurable through a web interface!?

The configuration for each handler can include things like the icon or text to display, the target and method used by the element etc…

What this needs is the minimum set of parameters required for a(ny) service type (+ maybe some custom ones for particular services if this is unavoidable?!)

Ciao,
Jeroen

I would like to start a discussion on how to develop such a plugin mechanism.

In detail, we should address these issues:

  • how to store the map viewer information into the metadata. Which format to use

and where to put it. Is the actual one the best solution?

  • which parameters of the map viewer should be configurable inside the metadata.

  • which parameters geonetwork should allow to configure to call the map viewer.

I’m thinking about an admin form with some options to specify the link to the map

viewer.

  • how to start the map viewer.

Cheers,

Andrea