Users Status

You are not logged in.

Recent Updates

Kepler, First Stakeholders...
I have already introduced the Scientific Workflow Management...
ctuot - 11. May, 23:21
Galileo - Chance für...
On Monday April 29, 2008, the German Federal Ministry...
ctuot - 7. May, 08:05
First evaluation of our...
I know that it has been a while since my last blog...
ctuot - 23. Apr, 08:32
Deutschland schaltet...
Saturday, 8. December 2007. Turning off all lights...
ctuot - 8. Dec, 20:36
Project RAPR - Demo Videos...
I have just finished uploading two videos in Youtube...
ctuot - 28. Sep, 17:41

Sunday, 11. May 2008

Kepler, First Stakeholders Meeting, May 13-14, 2008 @UC Davis

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). Kepler Logo
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.

Wednesday, 7. May 2008

Galileo - Chance für innovative Märkte

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.
Satellit (Quelle: ESA)
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.

Wednesday, 23. April 2008

First evaluation of our biomassplaner (RAPR)

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.
Ragional newspaper article about the evaluation of RAPR with 14 farmers.
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

Deutschland schaltet das Licht aus - Germany tuns the lights off

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...
Google macht das Licht aus
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.
Licht aus für unser Klima
Nevertheless, nice action!!!

Friday, 28. September 2007

Project RAPR - Demo Videos are online

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
DFKI-RAPR-Logistikplaner
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).
DFKI-RAPR-Biomasseplaner
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.

Thursday, 27. September 2007

The IVIP Project @DFKI

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.

Monday, 24. September 2007

RAPR Project presented at the German Federal Ministry

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).
RAPR Flyer in English
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.

Friday, 3. August 2007

Kepler: A platform to process spatial information?

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.

GML versus JSON when providing Geographical Data, speed and size factors

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.
Andrea Aime (anonymous) - 7. Aug, 09:13

Compression

Hi,
one easy way to reduce the network transfer size is to enable gzip compression at the http level. This is usually done at the http server/web container level.
For example, with Tomcat you have to hack the server.xml file and include the MIME types in the compressableMimeType attribute, more information here: http://tomcat.apache.org/tomcat-5.5-doc/config/http.html

This may reduce the amount of data that is actually travelling over the network by 10 times, without the user noticing it (gzip compression is part of the HTTP standard, compatible clients will handle it transparently).

ctuot - 9. Aug, 12:50

CGI Application Plugin?

Hi Andrea,

Thx for the tip. This is a nice and easy solution for the GeoServer which runs in Tomcat. I have tried to find a similar solution for the UMN Mapserv (cgi application) and I found this CGI Application Plugin:
http://search.cpan.org/~rhesa/CGI-Application-Plugin-CompressGzip-1.00/lib/CGI/Application/Plugin/CompressGzip.pm

At the moment, I do not have the time to test the UMN Mapserver with the CGI GZIP Plugin but if it works this could be great!

picture of me Christopher James Tuot

Search

 

Status

Online for 364 days
Last update: 15. May, 13:15

Credits

Knallgrau New Media Solutions - Web Agentur für neue Medien

powered by Antville powered by Helma


xml version of this page
xml version of this page (with comments)

twoday.net AGB

RSS Box


Event
GIS
Kepler
Perso
Projects
Profil
Logout
Subscribe Weblog