Our mantra around here is “release early and often” and we’re certainly holding to that these days.  The GeoServer team is woking on three (yes, three) parallel tracks of GeoServer.  First, there is the stable branch, currently at 1.6.4, which is current recommended version for those who need rock-solid dependability and minimal fuss.  Last week, we unveiled the first alpha of GeoServer 2.0, which brings a new UI and new customization options.

But today we’re proud to unveil the first release candidate of GeoServer 1.7.0.  We have received plenty of feedback from users, and there has been a great deal of work done to bring this one out of beta.  This version provides many new features, such as Xlink support for WFS 1.1, full implementation of WCS 1.1.1, and per layer security.  I personally like the new OpenLayers toolbar, which allows for dynamic updating of the configuration options.  Special thanks goes out to GeoSolutions for all of their hard work on the GDAL extensions.

So please download 1.7.0-RC1 and give it a spin.  Over 30 bugs and features have been fixed and implemented (respectively) since our last beta.

It’s nice to see that GeoServer is getting some recognition from those in the wider commercial GIS world. Tele Atlas, the map data provider famously known for providing its road data to Google Maps, has written a white paper on “Open Source Map Rendering.” The white paper zeros in on GeoServer as its open source solution, so we all felt our ears burning around here.

The paper guides users through the rendering of Tele Atlas data using GeoServer and related software such as PostGIS and OpenLayers. The paper and its data are only available to members of Tele Atlas’s DeveloperLink network.  (If you are not a member of DeveloperLink, you can sign up.)  Once logged in, the paper can be found in Technical Tools / Training & Technical Information / White Papers (Direct link)

I found this white paper to be a simple and helpful tutorial, regardless of whether one is working with Tele Atlas data or not. There are copious links to GeoServer’s documentation as well as to forums on the Tele Atlas site, so the reader is never lacking in avenues for finding out more information. It is a testament to the robustness of GeoServer that a high-quality commercial data provider such as Tele Atlas is recommending GeoServer’s use to their customers.

The GeoServer team has been working on something very exciting over the past few months, that we’d like to share with you now.  We have the beginnings of a brand new user interface on the admin console for GeoServer.

The admin console isn’t the face of GeoServer; the maps one serves with it are.  (And even then, it’s really the application, such as OpenLayers, or whatever front end is used, that is the real face.) That said, anyone who has spent any time working with GeoServer needs to get very intimate with the admin console.  The current UI is based on Apache Struts, which was historically the de facto Java web framework standard. However, it does have its limitations, mainly, its difficulty in maintenance and extensibility, and its programmer-centric workflow. Personally, I always felt that the UI was never built with the end user in mind, and I think most would agree.  This was fine back in the day when the project was in its infancy, but now that GeoServer has become an enterprise-level product, able to compete in the marketplace with any geospatial server, the community has come to think that now was an appropriate time to rethink the UI with the future, and the users, in mind.

The new UI is based on Apache Wicket.  Those who are curious about the more technical aspects of Wicket vs. Struts, they are welcome to read the Wicket GeoServer Improvement Proposal (and Wicket also has a nice page on the rationale behind yet another framework.) Personally, I think one look at the new environment will convince you that the product has turned a corner.

And so I welcome all users and developers to the first alpha release of GeoServer 2.0. This release is very experimental, and is intended primarily to show off the new user interface. The entire team is looking for any feedback on the look and feel of the new interface. Please sign up for the users or developers mailing list if you haven’t already, as posting there is the best way to ensure your feedback is noted and recorded by all.

One note on the distribution of 2.0.0-alpha1. Due to the very experimental nature of the release, it is currently being offered in .WAR (web archive) format only. This means that you will need a container server such as Tomcat or JBoss to be able to run the software. Future releases will contain all of the standard formats.

For more information and technical details about the new UI, please see the following links:

• Wicket UI in GeoServer

• Adding a Configuration Page with the Wicket UI

Download GeoServer 2.0.0-alpha1

The GeoServer team has been working full steam ahead on the new branch (1.7.x) of GeoServer.  With 1.7.0-beta2 released, KML regionating has been optimized.  Regionating is the process of automatically filtering what data is shown based on an attribute of that data (say, only showing large features when zoomed out).  Currently regionating is only functional for KML output, but this may eventually change.  Also, per-layer security has been added and enhanced, which people have been asking about on the mailing list for some time.  Per-layer security* will allow for layers to be viewable based on certain security credentials.  _*The development team is looking for a better, more succinct name than “per-layer security.”  If you have an awesome name suggestion, meet us in IRC and tell us!

_This is still a beta, so bugs will occur.  Nevertheless, if you find one, please let us know.  Also, we still haven’t abandoned the 1.6.x branch (the most recent stable version remains at 1.6.4), so if you’re not looking for cutting edge (or if you’re looking to run GeoServer in a production environment), 1.6.4 is the version you want.

We’ll be unveiling some exciting news about the future of GeoServer fairly soon, so stay tuned!

So one of the nice indicators of the success of GeoServer is the fact that skills in the technology can now actually pay the bills. As more and more organizations are relying on it and building solutions using it as a base, those who have experience with deploying and programming with GeoServer have become in high demand. As an open source project it’s easy to show off your skills, by writing code and contributing in other ways, so that you become known in the community. So even if you’re not ready for a job yet, do consider getting involved, since if you prove your skills its quite likely that you’ll be able to find paid work relatively soon.

And I’m not just talking in the abstract here. Portland’s TriMet, their main public transit agency, is rolling out a new map built on GeoServer and OpenLayers. They’ve got a very interesting job for a Java Software engineer with experience in geospatial web application development. Portland is a great city to live in, and they’ve been doing some really nice work with GeoServer.

Though I believe it’s closing on Monday, there are a number of jobs [1] [2] [3] [4] [5] in Australia offered through Curtin University who will work on AuScope projects, likely two of them will be GeoServer and three will be GeoNetwork. In addition, the core companies working on GeoServer are all growing, and are always on the look out for great people with experience. See the sites of OpenGeo, GeoSolutions and Refractions. If anyone else has job postings that value GeoServer experience please let me know, and I can do another post in the future.