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.

The GeoServer development team would like to announce the release of GeoServer 1.6.4. Primarily a bugfix release, it contains over 30 patches and improvements since 1.6.3. This version contains better support for the GeoWebCache plugin (if you haven’t checked out GeoWebCache you very much should.) There is now better default formatting of KML output, including including support for paging. The Windows installer has been updated and now has better compatibility with Windows Vista. Also, support for Freemarker templates for coverage layers has been added.

You can view the full changelog for more details. Thanks to everyone who submitted patches! Please keep them coming. I’ve been hearing rumors about the features planned for future releases, so exciting developments look like they are coming down the line. Stay tuned! (Or better yet, get involved!)

A quick announcement, that we’ve been showing off at Where 2.0: OpenGeo is building GeoServer 1.7.0 to be automatically crawlable by Google’s Geo Search. David and Arne have been working on trunk, and we’ve stood up a working prototype at http://geosearch.opengeo.org/geosearch/rest/. This has been crawled by Google’s crawler, and is now findable from Google Maps or Google Earth. The dataset we’re standing up is Benzo(a)pyrene emission levels around the Great Lakes region, so now you can search for those levels directly on the places in the PostGIS database, like ‘Benzo(a)pyrene Carbit Paint’. That link shows the search results on Google Maps, with the blue marker at the top of the list containing data coming straight from GeoServer. You can also constrain the search to just geosearch.opengeo.org and browse through the results. Try clicking on the various links, which will take you to visualizing the whole dataset in google earth, using GeoServer’s traditional KML output, or you can click on the glc:glin_benzo link to see the KML in Google Maps.

Though it’s not incredibly flashy, this feature to me is one of the most exciting things to come in awhile.  It speaks to the future of the geospatial web, where your data is just available on a variety of platforms.  Instead of making a specific mapping application and putting some metadata on it, your geospatial data - the actual data - is crawlable and available on the geospatial web.  Our dream is that GeoServer is like Apache for the geospatial web, the standard open source way to get your information on the web.   Google and others can then crawl and figure out better and better ways to return and rank the results.

At Where 2.0 John Hanke and Jack Dangermond just announced that ESRI ArcGIS Server 9.3 will also support all content being crawlable, which is great to see as well, to get all the people who already have their server set up to easily expose their data to the geospatial web.  Though Jack seemed to almost gloss over that fact, he was eager to get to the point that these are real services that offer real GIS analysis.  John twice had to bring it back to the availability of this data to be easily found and used by other people in new ways, which to me is the much bigger point, that anyone will be able to do new analysis, even if they aren’t ‘GIS Experts’.  The geospatial web is not about the GIS analysis (though it’s an interesting aspect for sure), it’s about getting many more eyeballs on the problems facing us today.  GeoServer and ArcGIS Server 9.3 will both be great ways to open up vast amounts of existing geospatial data to be found and used by everyone, to be combined and reused in ever more interesting ways.

Chris Holmes and I are at JavaOne in San Francisco this week, and Chris and Justin will also be going to Where 2.0. We are wondering whether there are any GeoServer users here, or in the bay area in general, that would be interested in meeting for lunch?

Tentatively around noon tomorrow, Thursday the 8th, near the Moscone center. Just an informal chat and a great opportunity to meet other users. Please email ak+meetup@openplans.org if you’re interested and I’ll be in touch with the details.

Also email me if you’re going to Where 2.0, we’ll try do something similar there as well.