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.

OGC-Web Coverage Service implementation

Me and my collegue are working on adding an OGC-WCS service to the Open Source project GeoServer and a better raster support to the Open Source project GeoTools.

Look our progress here. 

A light OGC Web-Client

Think to a database composed by hundreds of records each one representing a location on a map (which can be expressed as a georeferenced point, line, polygon, etc…) and having a lot of related attributes… in the OGC world they are called Features with Geometry. The importance of such things is so high that a specific service was created to handle them, the WFS (Web Feature Service). Almost all OGC compliant servers have a WFS implementation. Through this service a client can request every information about a specific Feature or about all the Features inside a certain geographic location. The clients can make requests using both standard and spatial queries on Features.

Now, think to a wide location containing thousands of Features and to the needing to show them on a web page… of course it's impossible to send via web all the Features due to the band and memory limits of the communication channel and web browsers.

The idea
Another cool service is available in the OGC servers, the WMS (Web Map Service). This kind of service produces images of the requested zone and layers. From the OGC specs a client can even tell to the WMS how to render (apply color palettes) to each layer through a meta-language derived from XML called “Styled Layer Descriptor” (SLD). The protocol allows the client to send its own SLD directly to the WMS on the HTTP get request, i.e. on-the-fly. With SLDs you can even filter data so that you can tell the WMS which features to render or not. Usually the produced images are low size JPEGs, GIFs or PNGs… so it's really fast and light to get back the response from the WMS even of a very wide geographic zone.

From those considerations we can evince an idea… instead of asking features we can request an “image” of the features. Moreover we can tell the WMS how to colorize the image so that if someone wants to select a subset of the features we can just tell the WMS to render with a different color this subset. Only when the user has made his choices and has selected a small subset of the features then we can ask the WFS to give us back the real information of the selected features from the database.

The implementation
On the web there is an open-source project for an OGC web-client framework called MapBuilder based on latest web technologies like DHTML, XSL and AJAX.

Thanks to the DHTML it's possible to have on a web browser all the widgets and power of a desktop application and is very easy to change the aspect of the whole GUI with very few changes.

XSL lets us easily create new widgets and functions by simply describing them as XML plus JavaScript documents. All the work is done by the style-sheet renderer (Sarissa) which get the original document and does the HTML translation on-the-fly.

Finally AJAX lets us to make real-time HTTP requests to the server without changing/reloading the browser page, so that for instance the client can get any specific information of a feature on-the-fly.

The following example shows a real application that uses the above concepts to handle a database of mammals sightings and strandings.

First the whole region of interest is presented shwoing only strandings from all sources (as selected in the filter form below map). The filter form allows user to refine his searches. An advanced filter form is available too. The latter loads a pop-up window with a query form which interacts directly with the database. Once the user has choosen the parameters of the filter the query results are shown in the original map.

Thanks to DHTML the client has all the functionalities of a desktop GIS application like zoom, pan, hiding/showing layers, etc….

The user can select the features he desires and the client depicts the selection using another color.

Finally clicking on the info button the client get the original feature data from the WFS which is returned back as a GML (Geographic Markup Language) document rendered as a table by the XSL translator.

Play with the client here.

KMZ to let Google Earth serve your own images

The famous Google Earth client uses KML and KMZ to load/save his related documents. You can write your own KML document and let Google Earth show your data as you need.

Not only geometric features can be loaded on Google Earth but even rasters (or images), so for instance if you have a different and more detailed raster map of a certain location you can load this image on the client. With KMZ you can even redistribute those images and let other people to load them.

First of all… how a KMZ document can be produced? This is quite simple… just write a KML document with a text editor, save it and then compress it as a zip file. Rename the final zip file as kmz and you have your KMZ document.

Now lets build a KMZ archive capable of load into Google Earth the images.

• Write a new KML file (doc.kml) which contains a GroundOveraly element like this:
  <GroundOverlay>
  <name>something</name>
  <drawOrder>1</drawOrder>
  <Icon>
  <href>image.png</href>
  <viewRefreshMode>never</viewRefreshMode>
  <viewBoundScale>0.75</viewBoundScale>
  </Icon>
  <LatLonBox>
  <north>49.10698224231601</north>
  <south>-0.3047781102359295</south>
  <east>-49.715479493141174</east>
  <west>-99.03054296970367</west>
  </LatLonBox>
  </GroundOverlay>
• Build a zip archive containing the doc.kmz and image.png files
• Rename it as kmz.

The work is done!

32-bit HashCodes

"Hashing is a refinement of the simple idea that searching can be made more efficient if one can quickly narrow one's search by locating a subset of items to search. Each item is characterized by a key, a part of the item which uniquely identifies it; such as an employee-number. Hashing creates a subset of items to search by computing from the key a characteristic value, called the hash, and then groups items with the same hash; the group is called a bin." [1]

Now the problem … in Java2 the Hash Codes are computed as signed integers (32 bit). What happens if in an Hash Map we would like to have more than 2exp(32) keys? The Hash algorithm will fail doing a linear search avoiding all its benefits and performances. The problem could be a little minimized if the Hash Codes are represented as unsigned long (64 bit). Conceptually hash values from any class should be uniformly distributed across the largest integer domain available in the language. In Java this is long, which is specified as 64 bits.

Ref. 1 – http://www.serve.net/buz/hash.adt/java.000.html