Let’s have a look at an example. Below is a map drawn by GeoServer that is reprojected to a projection that happens to sit across the dateline, the usual “edge” of the map. As you can see the reprojection is not doing a good job where the dateline is crossed:

Polygons crossing dateline change before improving the renderer

However, GeoServer now has what is called advanced projection handling. With this enabled, the dateline wrapping is properly handled and, in addition, the map repeats in a continuous fashion:

Polygons crossing the dateline with advanced projection handling

For more information, including how to turn on this (optional) feature, please see this post from GeoSolutions.

http://yourserver/geoserver/wms?REQUEST=GetMap&...&TIME=2009-12-12,2009-12-13&...

You can get some more details on the GeoSolutions blog.

Supporting a project such as GeoServer requires a great investment of time and resources. Organizations that support it are faced with the problem of finding funding. As founder of my own company, I often find myself in the position to seek funding for supporting GeoServer and I obviously tend to prefer large contracts to small ones. This seems perfectly reasonable, however I do recognize that in the long run this approach may cause some missed opportunities. Large funding usually focuses on large developments, but they leave aside common glitches and bugs, i.e. isolated features that are not working properly or could be improved relatively easily. To counter this, supporting organizations must invest surplus money and resources from other contracts into tackling these problems, since it is difficult or inefficient to chase money to address each small issue separately.

As a specific example, I have lately seen people struggling to get the ImagePyramid extension working, and I know it would be relatively easy to improve things (in that it would not need a lot of funding) but none of our current clients needs this functionality, so the work never gets done.

With this in mind, I have come up with the following idea: once someone, be it a user or a support organization, recognizes an issue/missing feature that no one else wants or has funding to fix, we should try to describe the problem/feature somewhere (such as on this blog), provide a Point of Contact (POC) for the work and then ask the community for an Expression of Interest (EOI) to check whether there is enough momentum/desire to fix/implement. Perhaps the POC should write the proposal having already scoped out the work or maybe the scope should wait until we know that there is enough interest. Another topic where I would see some interest is in whether the process should be completely transparent or not regarding who gives the funding as well as who spends the funding gathered. I would be interested in feedback on all of these suggestions.

To test his idea, I would like to invite anyone who might be interested in providing a bit of funding to improve the support for the ImagePyramid extension in GeoServer to express your interest to me. Specifically, I am talking about automagic import from GDAL retile, improved stability and performance, and/or automagic pyramiding as a GeoServer/GeoTools utility.

If you are interested you can drop me an email at simone.giannecchiniATgeo-solutions.it.

Ciao, Simone.

The session will be held on Thursday 22nd October, late afternoon (specific time TBD). If you are attending FOSS4G 2009 (and you very much should), feel free to stop by in order to say hi and chat a bit with us.

See you there!

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, to cope with point 2 above, however point 2 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 to store the configuration

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

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 and Oracle as the target database, but as you know, many more are supported by Hibernate (spatialite wi  ontheradar as well).
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 .
If you are interesting in supporting somehow (funding or human resources) this effort, please, drop me a few lines at simone.giannecchiniATgeo-solutions.it.

If you you need help wrestling with JBoss, feel free to contact us!

Thanks to the contribution of the geoSDI research group belonging to the CNR IMAA Research Center and in collaboration with GeoSolutions, all these organizations are using open source technologies (see here) via the geoSDI stack to provide geospatial services (you can find a few screenshots of the portal on the GeoSolutions blog). Please, note that GeoServer is playing a central role in delivering data via OGC W*S services (see here).

The GeoSolutions team would like to thank the geoSDI team, in particular Dr. Dimitri Dello Buono,  geoSDI project head, Dr. Francesco Izzi, geoSDI technical lead and Dr. Giuseppe La Scaleia, geoSDI  technical coordinator, for their effort in bringing the geoSDI concept into reality.

Looking forward to other challenging scenarios.

I have been playing lately with some remote sensing data for the geoSDI project specifically the emissive subdataset coming from the  MODIS sensor on-board the TERRA satellite. A small sample dataset can be found here. Its gdalinfo is here below:

Files: EmissiveCampania.tiff
Size is 63, 156
Coordinate System is:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.2572235630016,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]]
Origin = (13.742259882413393,41.506517193315830)
Pixel Size = (0.032872864093301,-0.009584951678830)
Metadata:
AREA_OR_POINT=Area
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( 13.7422599, 41.5065172) ( 13d44’32.14″E,
Lower Left ( 13.7422599, 40.0112647) ( 13d44’32.14″E,
Upper Right ( 15.8132503, 41.5065172) ( 15d48’47.70″E,
Lower Right ( 15.8132503, 40.0112647) ( 15d48’47.70″E,
Center ( 14.7777551, 40.7588910) ( 14d46’39.92″E,
Band 1 Block=63×65 Type=UInt16, ColorInterp=Gray
NoData Value=65535
Band 2 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 3 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 4 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 5 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 6 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 7 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 8 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 9 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 10 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 11 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 12 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 13 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 14 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 15 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 16 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535

The goal was to build a simple RGB on the fly (WCS usage is als envisioned, hence we could not just build it offline) by using bands 11, 9 and 1 respectively.

The style I have used for doing this is reported here below, it is a nice guideline in case you want to do something similar with Landsat data as an instance and create a false color image from the oiriginal dataset ( I might blog about that as well sooner or later ).

<?xml version=”1.0″ encoding=”UTF-8″?>
<StyledLayerDescriptor
xmlns=”http://www.opengis.net/sld”
xmlns:ogc=”http://www.opengis.net/ogc”
xmlns:xlink=”http://www.w3.org/1999/xlink”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=”http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd” version=”1.0.0″>
<UserLayer>
<Name>raster_layer</Name>
<LayerFeatureConstraints>
<FeatureTypeConstraint/>
</LayerFeatureConstraints>
<UserStyle>
<Name>raster</Name>
<Title>A boring default style</Title>
<Abstract>A sample style for rasters</Abstract>
<FeatureTypeStyle>
<FeatureTypeName>Feature</FeatureTypeName>
<Rule>
<RasterSymbolizer>
<Opacity>1.0</Opacity>
<ChannelSelection>
<RedChannel>
<SourceChannelName>11</SourceChannelName>
</RedChannel>
<GreenChannel>
<SourceChannelName>9</SourceChannelName> >
</GreenChannel>
<BlueChannel>
<SourceChannelName>1</SourceChannelName>
</BlueChannel>
</ChannelSelection>
</RasterSymbolizer>
</Rule>
</FeatureTypeStyle>
</UserStyle>
</UserLayer>
</StyledLayerDescriptor>

Since we are here, I will also show another rendering we have set up which applies a user defined colormap to band 11 (emissive temperature) which ranges from blu to red. Here is the style:

<?xml version=”1.0″ encoding=”UTF-8″?>
<StyledLayerDescriptor
xmlns=”http://www.opengis.net/sld”
xmlns:ogc=”http://www.opengis.net/ogc”
xmlns:xlink=”http://www.w3.org/1999/xlink”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=”http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd” version=”1.0.0″>
<UserLayer>
<Name>raster_layer</Name>
<LayerFeatureConstraints>
<FeatureTypeConstraint/>
</LayerFeatureConstraints>
<UserStyle>
<Name>raster</Name>
<Title>A boring default style</Title>
<Abstract>A sample style for rasters</Abstract>
<FeatureTypeStyle>
<FeatureTypeName>Feature</FeatureTypeName>
<Rule>
<RasterSymbolizer>
<Opacity>1.0</Opacity>
<ChannelSelection>
<GrayChannel>
<SourceChannelName>11</SourceChannelName>
</GrayChannel>
</ChannelSelection>
<ColorMap extended=”true”>
<ColorMapEntry color=”#0000ff” quantity=”3189.0″/>
<ColorMapEntry color=”#009933″ quantity=”6000.0″/>
<ColorMapEntry color=”#ff9900″ quantity=”9000.0″ />
<ColorMapEntry color=”#ff0000″ quantity=”14265.0″/>
</ColorMap>
</RasterSymbolizer>
</Rule>
</FeatureTypeStyle>
</UserStyle>
</UserLayer>
</StyledLayerDescriptor>

and here is the result:

Enjoy,

Simone.

Anyway, today I have been playing with some bathymetry data for the geoSDI project. I cannot share them since it is classified data but I have been told that I can show some snapshots .

Here below you have the gdalinfo on one of the datasets:

Driver: GTiff/GeoTIFF
Files: DEM_Vulcano_Lipari_Salina4326.tif
Size is 3718, 3600
Coordinate System is:
GEOGCS["WGS 84",
....
AUTHORITY["EPSG","4326"]]
Origin = (14.747192412574043,38.660954215168857)
Pixel Size = (0.000090196304703,-0.000090196304703)
Metadata:
AREA_OR_POINT=Point
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
….
Band 1 Block=3718×1 Type=Float32, ColorInterp=Gray

As you can see we are talking about Float data. First of all I retiled it with gdal_transalte (striped tiff are pretty bad performance-wise) then I added a few overview using gdaladdo with nearest neighbor interpolation. Once this was done I just throw it at the GeoServer and here is the result for an untiled request (here a detailed request ) and for a tiled request. Quick explanation, when you set up a raster with no real raster symbolizer element in its style (like for the raster.sld that ships with GeoServer) you can get strange results in case your data is raw, like bathymetries, DEMs and the like. What we do is trying to render something useful by doing a local contrast stretch, hence a tiled request can have the checkerboard approach and an untiled request can look fuzzy since maximum and minimum values are used for the stretch. In the future we might computer approximated statistics for a layer at configuration time and use them for the subsequent renderings.

Beside this I wanted to show a nice extension we implemented for the raster symbolizer element. Check this style as well as this one (notice that to use the secondo you have to uncheck SLD validation since the extension is not recognized by OGC schemas). They look like the same but if you check the second one you’ll see that the color map element looks like this <ColorMap extended=”true”> while in the other one it looks like this <ColorMap>. Well, long story short this is an extension I implemented in order to allow people to ask the GeoServer to symbolize raster data using as many colors as possible (specifically 65k) instead of limiting itself to 256. This results in much better looking images but you have to give away some performances. I guess it is something nice to have for layer that you want to cache with TileCache or GeowebCache.

To see you the differences, check the following:

• 256 colors
• 256 colors – detail
• 65536 colors
• 65536 colors -detail

I guess I have bothered enough.

Ciao a tutti.

PS. I found a minor bug today on the SLDParser which was not parsing the extended attribute. It is now fixed but unless you build things yourself, you won’t be able to test these things on 1.7.0. Drop me a few lines in case you want to try the differences and I’ll tell you how to fix this problem.

“geoSDI is the complete solution for Spatial Data Infrastructure used by the Italian National Civil Protection Department.

The geoSDI solution is based on Open Source Technologies and was born to allow the real time geospatial data sharing between the Functional Centers of the Italian Civil Protection Department, being OGC (Open Geospatial Consortium) standard compliant, INSPIRE Directive compliant and CNIPA Repertorio Nazionali dei Dati Territoriali specifications compliant.”

The  geoSDI infrastructure aims to provide a coherent National Spatial Data Infrastructure (NSDI) which is compliant with national and internal recognized standard as outlined by organizations like ISO and OGC as well as by initiatives like INSPIRE.

We are glad to announce that a core role in the geoSID inititive will be played by the GeoServer framework and that GeoSolutions SAS has been selected to provide professional support for the developments and customizations required.  Stay tuned for more information on the topic.