towards the geospatial semantic web

I have already introduced the Scientific Workflow Management System: Kepler which we are using to process spatial information in some of our projects like RAPR/IVIP or LoFos. (see my blog).
We have now been using Kepler for more than 2 Years and I believe we are starting to get some good expertise in using the platform, expertise that I intend to share at the first meeting of the Kepler Stakeholders which will be held at UC Davis May 13-14, 2008. This meeting is organized within the Kepler/CORE project which aims to further improve the Kepler platform with respect to its interdisciplinary domains of application.

On Monday April 29, 2008, the German Federal Ministry of Transport, Building and Urban Development organized an event to discuss applications relative to Galileo, the European version of the GPS (Global Positioning System).
The date for this meeting has been pretty well chosen since the second Galileo Satellite Giove B has been successfully launched on Saturday April 27, 2008.
The Galileo system will be productive at the end of 2013 with 27 Satellites over 3 orbits with one spare satellite per orbit. This should offer a very good coverage, better than what GPS is offering at the moment. Actually, no need to really compare GPS and Galileo, I personally do not want to see a competition here but more like a nice cooperation to offer better services.
Besides the general presentations of the system, 4 workshops took place in the afternoon to discuss some domain specific application of Galileo. I took part to the Workshop about the agricultural domain leaded by Dr. Armin Werner.

One very important conclusion of that workshop is that Galileo as positioning system only makes sense for the agricultural domain if the respective geographical material is made available for use, which is not really the case at the moment.
From my experience, getting access to geographical material is always tricky and all rights are reserved, but we are working on that issue.
Most of the presentations given during the event will be soon made available online. I will give the link in a future blog.

I know that it has been a while since my last blog but so many things to do and so little time.

We have been working a lot on our Biomassplaner (RAPR) which I have already briefly presented in a former story. One of the most important steps in research and development is the evaluation.
Some weeks ago, we had the opportunity to evaluate our software with 14 farmers. Each of them gave us some electronic documentation of their fields downloaded from the public service "FLächeninformationen Online" (FLOrlp). The documentation goes through our Biomassplaner which delivers a prognosis for the yield based on the model (Biomass Yield Model) developed by Professor Piorr and Sybille Brozio at the University of applied sciences Eberswalde. Our Biomasseplaner offers both some advanced geographical and table based visualization. We also developed several export plug-ins for Goolgle Earth and Microsoft Excel.
During the evaluation, we were interviewed by a journalist working for a regional newspaper “NAHE-REPORT” and finally we got a whole page describing our current work.

The first feedback we got from our users is more than positive and we are now working on a first release. I hope I will be able to blog soon about RAPR going productive.

AT last, just some few words to thank my project partner Dr. Wolfgang Schneider from Dienstleistungszentrum Ländlicher Raum who initiated the project.

Saturday, 8. December 2007. Turning off all lights from 08:00 PM to 08:05 PM to protect the environment.

Did you hear about the German initiative "Deutschland schaltet das Licht aus" (Engl: Germany turns off the lights)? If you are German and you are a Google user, you might have noticed that the German Google Page was kind of different today...

Turning off the lights to protect the environment, I do like the idea and I did it. At 08:00 PM, I turned off all the lights in my flat. I went to my window to see if other people were taking part to the action; and I did actually saw whole flats become dark! But still, a lot of lights were still to be seen in Kaiserslautern. Whether this means that people were not informed or simply are not interested in the cause is difficult to say.

Nevertheless, nice action!!!

I have just finished uploading two videos in Youtube both demos of the tools we have implemented in the RAPR project. The videos are commented but in German, sorry for that but it is always difficult to maintain different versions. Since I am also not convinced about the quality of the videos (thx Youtube), I will render new Videos with English comments and store them on my Homepage.

1. DFKI - Projekt RAPR - Demo - Logistikplaner
2. DFKI - Projekt RAPR - Demo - Biomasseplaner

The Logistikplaner is kind of a mashup based on Adobe Flex 3 and GoogleMaps. The Logistikplaner can be used for example to determine the best position to build a plant for the production of Biogas optimizing the distance to specific fields minimizing the transport distance (routing distance).

The Biomasseplaner has access to the soil quality and the weather information and uses the Biomass Yield Model developed by the FH Eberswalde to compute the yield on given fields depending on their crop rotation. The tools offers a hight interaction with the user to correct results and also supports export in Open Document Format (ODF).
The Biomasseplaner is based on XForms and OpenLayers.
One objective of the IVIP project is to deploy those tools in a productive environment.

IVIP stands for "intelligent integration of source of information for business specific, location based planning for the production of energy crops" (German: Intelligente Vernetzung verteilter Informationsquellen zur betriebs- und standortspezifischen Planung der Energiepflanzenerzeugung).

Decision making in crop production is essentially stamped by location-based or more precisely by space-oriented information or also by particular location driven situations. This is for example the case for the production of food and renewable raw-materials. Indeed, the cultivation of bio-raw materials can in certain regions lead to severe irregularities in the configuration of crop rotations. According to this fact, farmers and regional experts producing renewable raw materials mostly rely on new spatial-data-oriented decision making tools.

Within the RAPR project, DFKI conducted a feasibility study in Rhineland-Palatinate to show the benefits of a location-based biomass-planer using digitalized geographic information about ground allocation (FLOrlp) and soil quality (LGB). This project resulted from the successful cooperation of the different geologic and plant cultivation consulting facilities in Rhineland-Palatinate.

With the IVIP project, we intend to fill in the gap between the bid of information from LGB and the valuable location-based consulting services of DLR/ZEPP/ISIP in Bad Kreuznach by using the Web-based Spatial Decision Support System prototype developed in RAPR.

Last Wednesday, I had the opportunity to present the RAPR project at the German Federal Ministry in Bonn. But what is exactly the RAPR project?
Spatially Oriented Rule Based System for a Resource and Production Management of Raw Bio-Materials (German RAPR: Raumbezogene Regelwerkzeuge fuer ein Produktions- und Ressourcenmanagement von Biorohstoffen).

A DFKI Kaiserslautern - Knowledge Management - project for the region Rhineland-Palatinate in collaboration with John Deere and Agricultural Management Solutions (AMS) in Zweibruecken. RAPR aims to develop a rule-based prototype to process space-oriented agricultural knowledge in order to economically grow organic commodities. The prototype is planned to be tested while supporting the existing advisory service for production and resource management. After its completion the system will be available as open source software.
We already have two working prototypes, the Logistic-Planner and the Biomass-Planner. For copyrights problems, we are not allowed for the moment to put those prototypes online. However, I will write blogs describing both tools in details with Snapshots or Videos.

I believe the presentation went quite well and people were impressed by the demos. We have already got positive feedback and I hope this will continue.

The RAPR project was successfully closed on April 2007. I am now working on the IVIP project, more information in my next Blogs.

Kepler is a platform that scientists can use to efficiently design and execute scientific workflows.

Almost two years ago, I was looking for a platform that I could use to process spatial information. I found the concept of Kepler pretty cool and although no real GIS functionalities were present at that time, I decided to give it a try.

We have implemented new Kepler actors supporting some basic GIS functionalities using the GeoTools API:

• Bounding Box Selection
• WFS Requests
• Feature Merge Operations (geometry and attributes)
• GML Reader
• GML Writer

Those actors define the base for workflows dealing with spatial information processing.

In one of our first workflows, we have developed a new actor implementing the Biomass Yield Model developed by the FH Eberswalden (Prof. Piorr and S. Brozio). The workflow takes as parameter a bounding box and computes the yield based on the information retrieved from different WFS Servers (soil quality, temperature, precipitation…).

We are currently working on further GIS functionalities like for example JSON support and some more advanced operations on Features.

So here is the situation: I need to process some spatial information which I retrieve from different servers using the OGC standard WFS protocol. I simply use the GeoTools to query and process the information.

Information providers are all partners using either GeoServer or UMN Mapserver. All providers have a relative good internet connection in terms of speed but try as much as possible to spare some bandwidth (In Europe, a lot of internet connections are still volume based).

If I tell you that some spatial information stored in GML format requires more space than when stored in JSON format, you certainly will not be surprised. But about how much extra space are we exactly talking?

Since the GeoServer supports both delivery in GML and JSON format, I decided to give a quick shot to get a better idea about speed and size differences between GML and JSON.

The spatial information I used is stored in Oracle 10g and accessible through a GeoServer in a Gigabit Network.

Here are the queries I used:

• for GML: wfs?SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&TYPENAME=topp:ACKERFLAECHEN_RLP_GK3
• for JSON: wfs?request=GetFeature&typename=topp:ACKERFLAECHEN_RLP_GK3&outputformat=json

All caching mechanisms have been disabled!

Here the results:

Delivery time:

• WFS: 12,33s
• JSON: 8,86s

Result size:

• WFS: 235 MB
• JSON: 157 MB

Of course, there are many other aspects besides speed and size which should be taken into consideration like for example validation issues.

Nevertheless, JSON spares a lot of bandwidth and for slower internet connections, this means sparing a lot of time when providing information.