GeoServer presentation @ Italian GFOSS day 2008

During last year's italian GFOSS day (see here) I gave a presentation on GeoServer, specifically "GeoServer, interoperabilita' à la carte". I have found it laying around on my hard drive therefore I am posting it here, in case someone can't sleep because he is not able to find it. Notice, it is in Italian!

GeoServer presentation @ Italian GFOSS day 2008

View more documents from GeoSolutions.

Job offer @ GeoSolutions

We are looking for talented
software engineers to fill a couple of positions.
Qualifications as follows:

- good knowledge of Java both JEE and JSE
- good knowledge of c++
- knowledge of most important OGC specifications and concepts (WMS,
WFS, WCS, coverage, etc...)
- working knowledge on at least 2 of the following projects: Geotools,
GeoServer, Gdal, OpenLayers
- at least 2 years of experience in the above languages and projects
- being fluent in English, both written and spoken

We offer a variety of contracts, working remotely is the preferred option.

Please send a detailed resume together with a letter of presentation
at jobs at geo-solutions.it

FOSS4G 2009 Abstract selected

I have just received notice that one of the abstracts I submitted to FOSS4G 2009 has been voted enough to make into a presentation. The title is "GeoServer, GeoTools and GeoBatch: supporting operational Meteorology and Oceanography" and you can find more info here.

So, yeah , see you in Sydney!

Hibernating GeoServer: seeking for scalability and robustness

I thought it would have been worth spending a few minutes to let people know about this development that we are bringing forward at GeoSolutions.
Being not only GeoServer developers but also GeoServer hungry users, we have been a bit unpleased in the past by the scalability problems that it was showing by the fact that:

1. GeoServer was keeping all its configuration into memory
2. GeoServer was making use XML files to handle its internal configuration

Now a lot of work has been lately for the upcoming 2.0 version of GeoServer, however, while 2 has been made less evident by GSIP 36 1 has not been touched yet.
If you use GeoServer the way we use it, with thousand of layers and with 10 to 100 new layers added daily (usually remote sensing data), you might agree with us that we need to:

1. Not load and keep the entire configuration in memory
2. Use a database store the configuration

In a few words, we need to improve scalability and robustness while tring to not jeopardize performance.

At GeoSolutions we have decided to tackle this problems by implementing a new GeoServer internal catalog that leverages on Hibernate as its persistence engine and that would also not bring the whole configuration into memory. Our goal is to be able to support at least Postgis, Oracle and H2 as the target database, but as you know, many more are supported by Hibernate.
The range of features that this work would open up is pretty wide, just think about using Hibernate distributed caching, simplified GeoServer replication, etc., etc.

The work is in progress, we have started to describe the details on the GeoServer wiki and we will be committing a first version beginning of September.
If you are interesting in supporting somehow (funding or human resources) this effort, please, drop me a few lines at simone.giannecchiniATgeo-solutions.it.

Supporting FAO Fishery department with a custom GeoServer DataStore for Oracle

GeoSolutions is collaborating with FAO Fishery department in order to improve the statistical GIS application "Atlas of Tuna and Billfish Catches".

The interactive version of the Atlas of Tuna and Billfish Catches presents the global distribution of 1950 to 2003 catches, at 5° latitude by 5° longitude resolution, of those tuna and tuna-like species for which this distribution is generally well known on the global scale. These species consist of the so-called principal market tunas and some billfishes.

Its refactoring mainly consists into switching the actual architecture which produces static snapshots of the statistic requested by the users through a parameter selection form, into a fully dynamic GIS map client based upon the OpenLayers served by a GeoServer/GeoTools/GeoWebCache stack working on top of an Oracle database.

Here is a common use case to solve.
Consider a table which contains the yearly catches of several fish species around the world by using different kind of gears; the user may want to issue several kind of statistical requests like for instance the total sum of the yearly catches grouped by gears and species over a specific time-range. Moreover the user wants to be able to compute these statistics on a defined by a lon,lat grid so that in the end he can either map the squares for the grid with different colors depending on the catches' statistics. In the normal approach we should create a new view which joins the catches table with the lon,lat grid table and performs the requested aggregate functions on the result.

The main issue when coping with such a complex use case was to allow GeoServer to work with an underlying complex databases structure, joining tables on the fly depending on some parameters selected by the users and being able to apply statistics function by aggregating resulting records for criteria like across years or quarters of the catches. One of our goals was to not generate views on the fly inside the database as well as not to create new layers inside GeoServer on the fly, because such an approach would have, on a side,consumed a lot of resources and on the other side, it would have required a sort of clean-up mechanism to remove old, unneeded views and GeoServer layers; in a word a nightmare.

At the end of the analysis we have come out with an architecture proposal based upon a brand new GeoTools driver capable of producing Aggregate DataStore

s on the fly, by analyzing and rebuilding the SQL at run-time and also a CQL filter adapter for GeoServer able to understand Aggregate Filters to be forwarded to the Aggregate Driver.

The proposed architecture, as depicted in the drawing aside, consists of several components:

• A Proxy which intercepts the client request and traduces the parameters selection into an appropriate Aggregate CQL filter
• The Aggregate DataStore which dynamically changes the FeatureType structure on GeoServer
• The Business logic which performs dynamic queries to the DB by merging statistical and GIS datasets.

This approach can be generalized to similar problems. The proposed architecture, in fact, aims to be the base for future GIS statistical mapping application of the Fishery department.

Actually we based the driver on the Oracle NG plugin, but with some more effort it could be extended to the JDBC one allowing it working with other Databases like for instance PostGis.

The results of the plugin are shown in the screenshots below:

GeoSolutions is supporting the G8 meeting @ l'Aquila

GeoSolutions, in coordination with the geoSDI team, has helped to build and set up the geospatial portal and SDI used by the Italian Civil Protection and the G8 help desk, as you can see here and here, to support the G8 meeting at L'Aquila, Italy. The building blocks are well-known open source projects, GeoServer, GeoNetwork, geoSDI-ERA, OpenLayers, Hibernate.

For those of you that don't have access to the portal I am posting here below some screenshots of the portal showing data from various WMS servers.



In the pictures above you can se the portal overlaying WMS layers from differentWMS servers which have been accessed and catalogued to gain access to a wide range of information.

A special thanks goes to Dr. Dimitri Dello Buono, the head of the geoSDI project and to Francesco Izzi, the leader of the technical team, working with them on these challenging scenarios is always a pleasure.