A new home for the ImageIO-Ext project

Dear All,
after a long wait a new home has been finally created by Oracle for the ImageIO-Ext project on the new Java.net infrastructure. You can reach it here.

For the records the Image I/O-Ext project extends the Java's ImageI/O framework capabilities by providing access to new raster formats directly or through the integration of other frameworks and libraries, like GDAL, JMagick (experimental) and Kakadu for JPEG2000.
The project is Open Source but commercial-friendly, part of the code is released under an LGPL license, some other parts (namely, derivative work from Oracle's imageio source code) are licensed under BSD license.

This work has been started with the Google Summer of Code in 2006 by Ing. Daniele Romagnoli mentored by Ing. Simone Giannecchini (GeoSolutions).

The GeoSolutions team.

Workshop su GeoServer al meeting degli utenti GRASS e GFOSS

GeoSolutions sarà presente al  XII Italian GRASS and GFOSS users meeting con un workshop  su  GeoServer.

Il workshop fornirà agli utenti una veloce introduzione al framework GeoServer, concentrandosi essenzialmente sui seguenti aspetti:

• basic installation
• basic data configuration and publishing
• basic data exploitation

Nel case voleste partecipare al workshop, non dimenticate di registrarvi in quanto i posti disponibili per la conferenza sono limitati!

The GeoSolutions team.

GeoServer Workshop at Italian GRASS and GFOSS Users' Meeting

GeoSolutions will hold a GeoServer workshop at the XII Italian GRASS and GFOSS users meeting, the annual gathering of the Italian FOSS4G crowd. 

The workshop will provide a quick introduction to the GeoServer framework and will mainly focus on:

• basic installation
• basic data configuration and publishing
• basic data exploitation

In case you are around and you want to attend the workshop, make sure to register for the conference since seats are limited!

The GeoSolutions team.

Developers Corner: have your SLD transform raster data into vectors on the fly

Hi all,

in this post we'd like to share our most recent endeavor in dynamic data rendering within the GeoServer and GeoTools open source projects.

The problem

Suppose you have a set of scientific raster data sets, maybe they represent some sort of concentration, elevation, or maybe they represent wind, currents, or some other vector phenomena via two bands (one for magnitude, one for direction).

Now, you have lots of them and people want to display them in various ways. Raster with color scales are nice, but often you need to render them in other ways, such as contour lines, polygons catching all the pixels within certain ranges, or vector fields (think wind barbs).

Those are all raster to vector conversion processes that a WPS can take care of. However, suppose you also have a ton of those raster data, and that the raster classification parameters need to be dynamic, with a user providing, for example, the contour levels to extract.

Now you're facing a somewhat hard problem, in theory you would have to:

• call the WPS with the given data
• store the results somewhere
• register that new layer as a published WMS layer, along with the proper style
• update the viewer to add that layer
• purge that temporary layer once the user is done or wants a different set of parameters to be applied in the transformations

To add icing on the cake, suppose your datasets are massive, so doing the WPS extraction at full resolution can take its dear time.... does not really sound like a situation one would like your server and client infrastructure to deal with.

The solution

Instead of doing all of the above work, wouldn't it be nice to just specify the transformation needed in the style sheet? That's exactly the road we decided to follow.
We've created and SLD extension allowing to pipe a process (yes, a WPS one) inside the SLD so that it can be dinamically updated. It looks like the following:

The above would call on the fly the contouring process and then render its result: no need to create and manage a new vector layer, the data is generated on the fly only when needed.
Here is how the result looks (using a style sheet just a bit more complex than the above one):



Chaining transformations we can also extract and display the value of the single pixels and show it as a label, as in the following example:



Alternatively you may want to extract the polygons containing all the cells in a certain data range, like in the following transformation:

The result, coloring each range in a different way, is:



Finally, we may want to extract as set of wind arrows starting from a raster having the horizontal and vertical components of a vector (u and v):



We're linking to the full SLD of this last one because it's quite the testament of SLD flexibility: the magnitude and direction of the arrow are computed on the fly by using filter functions (functions that are part of GeoTools/GeoServer, you may not find them in just any implementation).

One important bit here is that the raster to vector conversion are happening at the visualization resolution: this means you can have the transformation work against large datasets without heavy slowdowns, because it is going to happen only in the area you're looking at, and at the resolution that would have been used to draw the raster.
This makes it possible to get fast, on the fly operations that do not excessively slow down rendering.

This is yet another example of how processing capabilities can be integrated into GeoServer, and it's by no means the last. Also, there is still plenty that can be done to improve this kind of transformations, as well as new transformations to support mapping tools such as heatmaps. Interested? Let us know!

The GeoSolutions team

GeoSolutions is sponsoring FOSS4G 2011

GeoSolutions is proud to announce its participation has a bronze sponsor to the Free and Open Source Software for Geospatial (FOSS4G) 2011 conference, being held September 12 - 16, 2011, in Denver, CO, USA.

The GeoSolutions team.

Developers Corner: Improving GeoTools/GeoServer raster reprojection performance

Ciao a tutti,
we hope everybody had nice seasonal holidays and is back fresh and ready to move on with another year of activity.

In this blog we'd like to present some of the work we have been doing in recent time to improve GeoTools and GeoServer raster reprojection abilities.

Raster reprojection is a quite heavy process in which every single pixel of the original image has to be mapped into a new position in the target raster. Here is a visual representation of a small set of pixels, before and after the reprojection (in this case, from WGS84 to polar stereographic):

A point by point reprojection is obviously taking quite a toll, a screen sized image has easily well over one million pixels to reproject, much more than the number of vertices one can find in the common vector map. To make things worse, the transformation to be used often involves trigonometric functions and other complex mathematical tools that visibly slow down the calculation.

The reprojection algorithm used by GeoServer and GeoTools until now worked exactly like that, it used a very accurate but also very slow approach.

Now, if you think about it, the transformation applied to one pixel and the one applied to the next one are basically the same, the difference is going to be minimal.If we only had a small bunch of pixels we could compute a simple translation and apply it to them all.
Having more pixels we could try to approximate the overall transformation with a simple linear one, which in two dimensional space is known as an affine transformation.

If the area gets larger a single affine transformation would not be good enough anymore, but we could use many of them to fit different areas of the raster.

Have a look at the following one dimensional representation to get the gist of the idea (this is known as piecewise linear function):

The trick to apply this approach if finding out where and how much to subdivide the original area into discrete pieces that can use a single affine transform: to do so we devised a simple error estimation method that proved to work well with all common map projections.

So we start by evaluating the linear transformation error over the entire raster area, if it's larger than a certain target we split the area and evaluate again, and recurse this way until the approximation error has been put under control.

The optimized method proved to be quite effective, drastically reducing the time it takes to reproject a raster. We made some tests with GeoServer using the same data and the same reprojection test used in the FOSS4G 2010 WMS shootout measuring a six times speedup:

We also compared the images generated by the original and optimized method finding there was hardly any human noticeable difference, and very little difference that could be machine detected at all.

For all of you that want to dig into the nitty-gritty details, we have a full tech report that you can inspect.

There is still plenty that can be done to optimize further raster data reading and in memory transformations to reach even higher performance and scalability. Interested? Let us know!

The GeoSolutions team