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.

Summarising, if you are updating GeoSerber from 1.6.x or older, make sure to check to replace the raster.sld with the new onw.

Ciao a tutti.

At this point the extension is still quite young and is missing some key features like spatial indexing and support for well known binary. By trying it out and providing us with feedback you can help drive development of these features.

The extension is based on the recent re-architecture in GeoTools for database backed data stores. Code named “JDBC Next Generation”, it provides a framework for building new data store implementations quickly and robustly. Also based on this architecture are soon to come improved extensions for MySQL, Oracle, and DB2. A new extension for SpatiaLite is also in the works.

Download the SQL Server extension and try it out. We are very eager to here any feedback on the mailing list. You can also help us make it better by reporting any issues in our bug tracker.

GeoServer Developers Map

This map interface is built using OpenLayers. The data points are saved in a PostGIS database and are served through GeoServer. OpenLayers accesses the data using the WFS protocol. The background image is currently the Google terrain layer, but will soon be replaced by OpenStreetMap data.

If you are a GeoServer developer and wish to be included on the map, let us know. Please include your name, a short bio, and the city, state, and country where you live. If anyone has any other comments about this map or the technology behind it, please write to us at inquiry@opengeo.org.

]]> http://blog.geoserver.org/2008/11/07/geoserver-developers-map/feed/ http://blog.geoserver.org/2008/10/28/safe-fme-and-geoserver/ http://blog.geoserver.org/2008/10/28/safe-fme-and-geoserver/#comments Tue, 28 Oct 2008 23:08:23 +0000 Chris Holmes http://blog.geoserver.org/?p=143 OpenGeo and Safe Software have been talking about working together to make life easier for users of FME and GeoServer.  We’ve both been hearing more about organizations using FME to solve their data conversion challenges and then making the results available to the world using the OpenGeo Stack.

While many people are making things work with the software now, we figure that a few improvements towards tighter integration could be a big win.  Our end goal is to enable FME Server and GeoServer to work together seamlessly.  This allows each piece to solve the area they excel at - GeoServer in OGC standards and web output formats, FME at complex data conversions and translations.  With a few key improvements the combined solution should solve the ‘Community Schema’ problem that Ron Lake recently brought up better than any software in world.  In time the GeoServer community will definitely build the capability to handle the full community schema transformation natively, but integrating with FME should provide a transitional path, and FME will always be ahead in terms of the most advanced translations.

If you are a user of both FME and GeoServer we’d love to hear from you with input on how we could work together to make your life easier (or you can just give us encouragement ;).  We are still in the early stages, hoping to put together a rough prototype relatively soon, but beta testers in the future will be appreciated. And of course additional funding will enable us to prioritize the work and get it done faster.  If you are interested in helping out please get in touch at the OpenGeo contact form.

Security in 1.7 has been improved by allowing access control at the layer/feature type level, in addition to the service level. This allows users to secure data in a much more granular way. There has also been much work done to better performance for GeoServer 1.7. The short of which is faster rendering with WMS, as well as faster data access with Shapefile, PostGIS, and ArcSDE. For those interested in the specifics check out the presentation given by Andrea Aime at FOSS4G this year in South Africa. Also of note for this release is a retrofit of the built in OpenLayers map preview. The preview interface now allows for filtering and controlling various rendering aspects such as anti-aliasing and image format.

The folks from GeoSolutions have also been quite busy as usual and have once again made some great improvements on the raster/coverage side of things. GeoServer now supports additional raster formats such as ECW, MrSID, and JPEG 2000. This has been achieved by leveraging the GDAL library. As well as additional formats GeoSolutions has also provided the ability to perform much more powerful coverage portrayal via the SLD RasterSymbolizer construct. With support for RasterSymbolizer users can now do channel selection, define color maps, perform contrast enhancement, and more. Special thanks to GeoSolutions.

As the GeoServer community expands, so does the number of translations to support other languages. 1.7 brings a Dutch and a Russian translation. Thanks to Leon Vanberio and Maxim Dubinin for their great contributions. And special thanks to all users who helped us test the 1.7 release candidates and filed bugs in the tracker.

Not only is GeoServer 1.7.0 a big release for users, it’s also a notable one for developers. Some major improvements have been done to the GeoServer core which will act as building blocks for features in future releases. This involves a change to the internal feature model which now allows the modeling of complex feature relationships; something that gets us closer to achieving full community schema support. There have also been changes to the back-end configuration subsystem which now has a much cleaner API for developers writing plug-ins and user interface components. It will also serve as the base for supporting additional persistence mechanisms such as hibernate and other O/R mappers.

And as usual a heap of bugs were fixed for this release. Over 200 issues were handled for 1.7.0.

Download, try it out, and let us know what you think. Comments and feedback are always welcome on the mailing list. The community is always interested to hear how people are using GeoServer. Also stay tuned for the 1.7.1 release, due out in a month or so, which will include some exciting new improvements to Google Earth and KML support.

Update: I’ve been asked off-camera about uDig’s editing capabilities.  uDig does in fact follow the WFS-T(ransaction) standard, and is one of the best clients out there for doing so.  In this way, one can use uDig to edit features served using GeoServer from the safety of a familiar GUI.  That’s big news (shapefiles and other data structures can be rather opaque to edit otherwise) and I think it merits a mention here.

“GeoServer is nifty, but is it fast?”

Clearly some benchmarks are needed. Testing was first done at a presentation at FOSS4G 2007 by Justin Deolivera (OpenGeo) and Brock Anderson (Refractions Research). They chose to compare performance of GeoServer against MapServer, another popular open-source GIS. The presentation was well-received and showed off the strengths and weaknesses in both servers.

This year, at FOSS4G 2008, Andrea Aime (also OpenGeo) took over the benchmarking process, this time with an updated test suite including thematic mapping, anti-aliasing, raster data, and tile caching. Since the previous year, MapServer had improved its shapefile rendering to be faster than GeoServer’s render time. But Andrea continues:

“The hard part started when our results showed GeoServer being in the lead in both PostGIS and raster tests. I could buy the PostGIS results, but I did not believe the raster results. MapServer has had long-standing and well-reputed raster support, so how come the newcomer was doing better?”

Andrea and Justin worked directly with Steve Lime, Paul Ramsey, and Frank Warmerdam to confirm and discuss the findings. But the results were clear: although MapServer was faster at shapefile rendering, GeoServer was faster at raster and PostGIS rendering.

Andrea continues:

“When you look at our results, remember that the MapServer developers are already working hard to improve MapServer performance, just like they did one year ago with the shapefile results. GeoServer developers won’t be sleeping either, as we’re already working on some changes to get PostGIS support both more secure and faster.

For next year, we’re looking forward to doing a joint presentation that will allow each group to tune their respective servers to the best of their capabilities, and look into some extra tests. I’m looking forward to it; a bit of friendly competition is benefiting both servers and keeping the audience interested.”

Sounds like a friendly throwdown to me.

But don’t just take his word for it.  Why don’t you download the test suite and report back your findings?