We have released our second beta version of GeoServer 1.5.0. It contains many bug fixes and improvements. You can find the download here. Another useful feature it has is the ability to add coverages outside of your data directory.

Our next round of releases before the official 1.5.0 release are going to contain several larger changes that should clean up the UI and also introduce a suite of useful coverage tools, such as a Pyramid Builder and an Image Mosaic tool. This beta release will help us figure out what users want and need for the official release. So please try it out and give us lots of feedback either on our mailing list or on this blog.

Last week one of our users alerted us that IBM is now listing GeoServer as an open source option for DB2, their spatial database offering. This is obviously a nice endorsement of GeoServer, as IBM is a serious player and DB2 is their premier spatial database, and they are pointing their users to GeoServer as a great way to present and edit spatial information from their database.

We checked with David Adler, our contact at IBM, and he told us that yes, we could let the world know that the GeoTools DB2 datastore was written by him and contributed by IBM. IBM is obviously no slouch about open source, with their Eclipse and Derby offerings, and it’s great that this has extended a bit to the spatial domain. Instead of writing their own WFS, WFS-T and WMS interfaces for DB2, they realized that creating a datastore for GeoTools, which is used by GeoServer and uDig, could have a much bigger impact for much less work.

David also informed us that IBM is planning Spatial Support for DB2 V9 for zOS (IBM mainframe) which will provide comparable capabilities of the current DB2 Spatial Extender for Windows and *IX platforms. He’s got fixes for the DB2 GeoTools plug-in to support DB2 on zOS, and plans on checking them in by the time it emerges as a general release.

It’s great to see the industry recognize open source and show their support for it. The open development model easily allows for new extensions and features to be added, without forcing contributors to jump through a lot of hoops. This leads to some excellent plug-ins such as MySQL, ArcSDE, Oracle, and VPF. New data formats are welcome and the community is always eager to help you get started on developing one of your own, or tell you how to add to existing ones. Suggestions and requests are welcome too so send them our way.

As some of you may know, GeoServer can serve up WMS data as KML or KMZ for Google Earth. There is a full video tutorial located here on how to set it up.

One of the tools GeoServer has to make serving up KML/KMZ easier is a reflector script. This exists so people don’t have to type in an entire WMS request URL to view the data in Google Earth. Here is an example of its use:

http://localhost:8080/geoserver/wms/kml_reflect?layers=states

By using this URL, you can ignore all the other WMS information. Information such as projection, image size, output format etc. You can also specify more than one layer by just separating the layer names with commas: layers=states,roads,lakes

The reflector will take the layer names and fill in the missing information, then return back a full WMS request. Users have asked why a URL is being returned when they use the reflector in their web browser. The reflector is meant to be used within Google Earth in a Network Link. The network link will interpret the returned WMS request and send it off again to GeoServer to get the real KML data back. So at first it makes two requests to get the real data, but after that it updates with just one get map request.

One recent item of discussion has been how to format the description of the features that are returned. In KML you can return an HTML description of the data.

What we do is take all of the feature information and put it into an HTML table that pops up when you click on the feature. But say if you wanted to hide some of the attribution, or turn some value into hyper links, there is no current way to do this (at least with not hacking the code). A few ideas have been suggested: including the formatting information into the SLD file, have a separate SLD-like file for just the descriptions, and XML transforms with a template document. In order to make a decision on which path to take, we would like some input from the users: use-case scenarios, requirements, etc.

So drop us a line and tell us what you think.

So this may be about as close as I’m going to get to ‘Developers notes’ for awhile (though I may let myself work on some GeoJSON or GeoRSS output over the holidays), but wanted to let everyone know that I updated the GeoServer Roadmap in an attempt to capture the latest directions of the community. If I’ve missed anything please don’t hesitate to update it (all our docs are wikis). The roadmap had fallen out of date - the ‘short term’ projects were set to complete in september - so I’ll try to be more vigilant about updating it more regularly.

But I must say it was quite satisfying doing the update, as the GeoServer community had actually managed to hit most of the things we said we would. The demo site is up, GeoCollaborator stuff has moved from discussions to the beginning of an implementation. 1.4.0 is out, and the WCS branch not only got up a release, but is a part of the GeoServer main line as 1.5.0-beta1. We’ve also had some work on tiling/caching with a tutorial on running OSCache. The only thing we didn’t get to was an improved SLD editor, but I’m hoping we can do it after our web gui overhaul - which made it’s way up to ‘medium term’, as we’ve been feeling the pain too long. If people have suggestions of a good web framework let us know, the ones we’re likely going to look at are Wicket, WebWork2, and Google Web Toolkit.

Elsewhere on the horizon we’ve got WFS 1.1 (which includes GML 3.1.1 simple features) from OWS-4 coming home, and Justin’s made some nice improvements on that branch. And 3d and 4d support in WCS will be in the works as the 2D version works towards the stability of 1.5.0. Also Social Change Online and Axios are likely going to be doing some more work on bring the new Feature Model home, which should be a huge step forward. On the non-technical side of things we’re also going to be working on changing the license of the ‘core’ of GeoServer (configuration of data and access to GeoTools) to LGPL, which should enable others to build even more interesting services on top.

So stay tuned, there’s lots of fun coming from the edges to the mainstream of GeoServer, and there are some other fun things that may be in the works. It’s going to be an exciting year for sure.

Happy Holidays from all of us working on GeoServer!

It’s finally here! Version 1.4.0 is out the door and kicking. This is quite an exciting release for us because it is taking GeoServer in a new, more developer friendly, direction with the Spring framework it is built on. What we gain from this new framework is the ability to modularize GeoServer into separate components and allow for outside developers to create plug-ins easily. It used to be a lot more difficult to add extensions, comparatively to what we have now, and this means that we can look forward to new and interesting additions from the many users out there.

That said, I will point you at the documentation that describes just how to write your own plug-in: http://docs.codehaus.org/display/GEOSDOC/4+Programmers+Guide

Of course there are many bug fixes and improvements in this release. We have also worked on stability a fair amount and are currently testing version 1.4.0 on our demo server: Sigma . So if you have a WMS up and running, feel free to point it at our layers and use our data. The more we can hit the server the easier it will be to find problems.

Hot on the heels of this release is GeoServer 1.5 with Web Coverage Service support. We hope to see the first release candidate in January. So stay tuned!

You can grab the 1.4.0 release here.