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.

While lots of talk here has been about software releases and work that’s already been completed, I thought that it might be nice to mention some of the work that’s in progress. After all, the GeoServer community is just that, a community, not a closed-door office, and while congratulations are often in order, the people have a right to know what’s going on as it happens. With that in mind, I put on my press credentials, got out my tape recorder and microphone, and have been interviewing some of the GeoServer developers to see what they’ve been up to recently.

I first talked with David Winslow, who has been working on what is known as KML regionating (via a grant from Google). When working with large amounts of data, not only can it take a long time to plot all those points/lines, but it is not always necessary or even useful to display all of those them (say, when fully zoomed out). Filtering data by zoom levels is now accomplished by the use of SLDs (style layer descriptors), a handy but abstruse XML document that can easily become unmanageable. There exists a need for a tool to simplify this, and that’s where regionating comes in. Regionating, despite the possibly questionable name, allows the automatic splitting of features via zoom level. Features with (say) high values would be displayed at higher zoom levels, while features with lower values wouldn’t show up until zoomed in. Regionating is expected to be able to automatically filter by data type or size of feature (say, large polygons versus smaller ones). As someone who has generated SLDs that have run to thousands of lines (most of it semi-duplications for each zoom level), this will be a help indeed. Note that for the time being this work is for KML output only, so it will benefit users of products like Google Maps and Google Earth.

Through the wonders of Skype, I then phoned in on Andrea Aime in Italy who discussed with me plans for per-layer security. Currently, security in GeoServer is very rudimentary. Per-user properties exist, as does a sensible user/role/service relationship, although passwords for the moment are stored in plain text. However, as one can only lock down via user or service, if a user has access to (say) WMS, the user has access to all data served using WMS. This isn’t always optimal. Per-layer security will add more granularity to the security subsystem by allowing or disallowing based on namespace or layer, and even specifying read/write access as based on predefined roles. This system, when implemented, will be backwards compatible with previous versions; that is, security will be open by default, so users who upgrade won’t find all of their layers suddenly inaccessible! The conventions proposed, such as giving priority to more specific rules over generic rules, seems well-thought out, and will be a nice step forward. The plan as it stands now is to implement this as part of version 1.7.0, but this could easily change.

There has also been lots of talk about the upcoming code sprint in Bolsena, Italy, where, among much else, work will commence on a new user interface for the admin console. The new UI is an issue close to my heart, being more of a user than a developer, and I’m very much looking forward to their advances. I’ve also been starting to hear rumors about a version number that begins with 2, but my press credentials will only get me so far.

I should remind everyone that these features are not yet released, stable, or in some cases even coded. And issues may come up that prevent some of these new improvements from ever seeing the light of day. GeoServer, though a robust product, is still a work in progress, one that is helped enormously by contributors. I encourage anyone who is interested in seeing these features (or any others) come to life to get involved, join the mailing lists, meet us in IRC, edit the documentation wiki, or submit a patch. The more people involved, the better GeoServer will be. As for me, I’ll just continue to try and get my copy in before the deadline.