towards the geospatial semantic web

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.