While others have mentioned this, I figured it was worthwhile to point out here, as there’s a lot of great tutorial information on GeoServer contained in Ian Turton’s new Open Web Mapping Course. He managed to get the content released under a creative commons license, so all are able to make use of his great work.

The other highlight is all the student projects, that are mostly built with GeoServer. They are some great examples of what’s possible with GeoServer. If anyone else has interesting sites they’ve built with GeoServer, please let us know. We’d like to start an interactive gallery soon, and these definitely make for a solid start.

Geoserver WMS has been know so far for the beautiful looking maps it’s able to generate. This is the result of true color rendering, antialiasing, and SLD expressiveness. Yet, there is a price to pay for such an output: size. Image files generated by the current WMS are big, and this shows up quite evidently when serving maps over slow links. When images are mostly satellite imagery, jpeg can be used with good results, but the same does not apply to vector image, where compression introduces visible artifacts.

To cope with such environments, we decided to go for a different compromise, allowing the user to choose for speed and size, while giving up some of the beauty. The current 1.5.x branch, setting the stage for the 1.5.1 release, contains a new WMS vendor parameter, “palette”, that allows the user to choose a 256 color palette to be used during rendering and image generation.

As a result, image generation is faster, and files are up to 4 times smaller. This is especially compelling for vector layers where most of the space is filled with uniform color. By default we ship with the internet safe palette, but you can provide your own, by example: just drop a 256 colors GIF or PNG in the GEOSERVER_DATA_DIR/palettes directory, and refer it from the GetMap request, asking for a PNG or GIF output.

For further details, see the paletted images research page and the WMS vendor parameters page. If you’re eager to test it, grab a recent Geoserver 1.5.x nightly here, and let us know if you enjoyed it: http://geo.openplans.org/nightly/1.5.x/

We’ve recently been kicking around the notion of requiring Java 1.5 to run GeoServer. There are a few nice features, such as generics and annotations, that are useful when you’re aiming to be a framework instead of just an application. And some potential libraries, like user interface ones, are starting to require Java 1.5. Other things pointing towards why it might be ok include the fact that Java will be open sourced soon, so it will be even easier for non core platforms to run GeoServer. But we figured the best way to figure out is to ask you, the users. If you have or are a sys admin who just isn’t ready to upgrade to Java 1.5, let us know. We realize that it’s a server application and admins like things stable. But with Java 1.6 out, and 1.5 very, very stable, we’re thinking it might be time. So please vote in the poll below, and place comments on this post if the options don’t do it for you. We will strongly take this feedback in to account for our decision.

</p>

So I’m about to update the GeoServer Roadmap, since the short term projects currently listed should be done. And I thought before doing that I’d see how we did against the previous goals. Of course we don’t make any promises about delivery of these, unless of course someone funds a core developer to meet a hard deadline. But it’s worthwhile to see how we measured up, to get a progress report on where everything is at.

GeoServer 1.5.x

1.5.0 Released! Woo hoo! This took a good bit longer than expected, but I think everyone is quite satisfied. It’s our most stable and scalable release yet, with lots of good bug fixes and improvements for users, in addition to the incredible new raster support. We’re planning for more 1.5.x releases, back porting the fixes and smaller improvements from 1.6.x, including using openlayers for demos and some very nice KML improvements, and a contributed Chinese translation of the web admin.

Further Tiling Infrastructure

So unfortunately our research on this didn’t yield the results we were hoping for, as we wanted a rendering option that worked better with tiling. But it turns out that doing meta-tiles (rendering an image much bigger than the tiles then splitting them up). There is great news on this front, though, which is that Google’s Summer of Code has funded Chris Whitney to make a JTileCache, a pure java port of TileCache, backed in his initial implementation by JCS, which will let us make distributed caches very easily. Since it’s java we’ll be able to ship with GeoServer, and it will function as a stand-alone.

Speed Improvements to WMS Renderer

Most of the speed improvements of the past few months have actually been made on the WFS side of the fence. Chris Tweedie has some information on his blog, the main work done is not so much on speed improvements, but on setting up a framework for stress tests so we can measure things much more easily. But Andrea also found some great improvements that doubled-t3541274.html) the WFS output in some cases.

GeoCollaborator (Geowiki) experimental implementation

The server side implementation is close to done, we’ve got a working interface, which we encourage to try out and write clients against. We’ve got it working against existing WFS-T implementations, but we’re working to collaborate on a ‘version-aware’ client. The one remaining piece we need to do on the server side is a bit orthogonal, but necessary, and that’s a security framework. Andrea is gathering requirements and evaluating right now, if you have any feedback throw it on the wiki. Our needs are minor at the moment, but we’d like to pick something that can expand for future uses.

LGPL for the core

I’m still working on this. We’ve decided to just push on getting contributor agreements first that will give us the flexibility to re-license by having all the legal pieces in place, and then we’ll figure out LGPL for the core at a separate time. But I hope to have progress on this relatively soon, so that potential users can license GeoServer under non-GPL licenses.

WFS 1.1 / architecture improvements

Justin finished this up. It is on trunk and will be one of the main pieces of 1.6.0. It’s currently available in an alpha release, and hopefully a beta release pretty soon. Other developers have had good feedback on the new dispatching architecture.

New Geotools Feature Model

Gabriel has made some great progress on this. Hopefully he’ll give us all a full update soon. We also got some great news on this front, as TOPP has been awarded a CAP grant to work on uDig, making it able to accept WFS 1.1 with US Framework Schemas, which will entail getting on to trunk the GeoTools feature model that GeoServer fully depends upon.

So overall I feel we did pretty well.  In the next week I’ll update the roadmap and talk a bit more about the exciting stuff coming down the pipeline.  And hopefully we’ll get the developers talking more about what they’ve been working on, since there’s even more than what I’ve managed to mention here.

With all the releases that the GeoServer team has been making, topped off by 1.5.0, we’ve managed to crack the top 20 open source projects on freshmeat.net for ‘vitality’. We’ve got a lot more coming out soon, so hopefully we’ll be up there and even higher in the future. If you’re reading this today, you can go to http://freshmeat.net/stats/#vitality and see. If not we’ve got the screenshot.