We seem to be releasing something every week now, a testament to our tireless developers and input of the community.  Last week, we released 1.6.5, which is still the official stable release at the time of writing.  However, we are closer than ever to a stable release of the 1.7.0 branch, and today we release the third release candidate of 1.7.0 to the wider world.  Among others, there were two pernicious bugs that caused FeatureTypes and coverages to disappear in certain circumstances.  (Yikes!)  No more, though.  In total, there are 19 bug fixes in since RC2, and as usual, we encourage you to test out the latest version.  Will the fourth release candidate be the charm?  Stay tuned.

The GeoServer team would like to present the newest stable version of GeoServer, 1.6.5. This is likely to be the last release of the 1.6.x branch, as development moves towards a stable version of 1.7.x. Nevertheless, this is an important release, as it features a whopping 65 bug fixes and improvements. Special thanks go to Léon van Berlo for translating GeoServer into Dutch. This marks our eighth language, and means we now have between approximately 100 and 6904 left to go, depending on what source we quote and how we define a language. We also have WMS point layers rendering correctly again, fixes regarding using the Google Maps projection, and improvements to the Map Preview area of the admin console. You can take a look at the entire changelog if you’d like, or just download this version and check it out for yourself.  Feedback welcome!

Each year, the Free and Open Source Software for Geospatial Conference (FOSS4G) brings together the best minds from the open-source geospatial software world to discuss their work and hopes for the future. GeoServer will be well represented in at least three presentations, two workshops, two posters, and one lab session.

Justin Deolivera and Andrea Aime will be discussing the “Past, Present, and Future” of GeoServer, with emphasis on the new access control and RESTful API, and a brief but exciting look a the new and much-improved user interface.  Also, Chris Holmes will be giving a presentation about GeoServer and the GeoWeb.  This will go into detail about about how GeoServer can expose geospatial data to search (via Google Maps) using KML and GeoRSS.  For those who want to dig in and see GeoServer in action, Justin and Chris will also be hosting a hands-on introduction to GeoServer.  This will run from basics such installation, data setup, and map creation, to more advanced topics like templates, versioning, and Google Earth integration.

FOSS4G is a great event for anyone interested in open source geospatial software, regardless of whether you are a user, developer, or decision maker.  The conference runs from September 29 to October 3, 2008 at the Cape Town International Convention Centre in Cape Town, South Africa.  The show is approaching fast, but there is still time to register for the conference.  Come on by and say hello!

If you’ve ever needed to import multiple shapefiles into GeoServer, you know that currently there aren’t any built-in tools to let you to do this.  I had to import about a hundred of them for some work I was doing, and it simply wasn’t feasible to do them one at a time.  (Recall that shapefiles are their own DataStores, so one needs to set up DataStores and FeatureTypes for each shapefile, in effect double the work compared to a database.)  I polled the users mailing list but didn’t get much of a response, aside from others looking for the same.

Impetuously, I decided to set out to solve this problem myself. I am by no means a programmer (at least not yet), but I have some shell/batch scripting history, and was, as Hunter Thompson once said, “just sick enough to be totally confident.”  I decided to write a batch import program in Python, if for no other reason than we have some sophisticated Python developers in the office, so I figured I was in good hands.  Yes, I didn’t actually have any Python experience per se, which sort of likened the experience to someone who has never held a soldering iron building a personal computer.

So, I tweaked, tinkered, read Learning Python, asked a ton of questions to my tireless office mates, and in a short eternity had a script that did the following:

1. Copied a shapefile (and associated files) to the data directory

2. Appended info block to catalog.xml

3. Created named FeatureType directory and associated info.xml

Some parts of the process were made easy in my particular case.  All my SLDs were already loaded into the data directory, with the same name as the shapefile.  Every shapefile had the same bounding box, projection, and namespace, so I could hard code those into the script without having to figure out how to get at them another way.  The script wasn’t pretty, but it worked, and to me, that was the most important part.

The punchline to this story is that the very next day after I got all my shapefiles loaded, there appeared a response to my initial query, wherein a kind soul had posted a python script that did (approximately) the exact same thing.

Stoyan Shopov from LISAsoft, a geospatial software and consulting company, was in the same situation as I was.  He created the script, as he says, “by my own initiative and out of frustration,” which pretty much sums it up.  His script was, of course, miles ahead of mine in compactness and sheer elegance.  That said, in the spirit of open-source and sharing that is our solemn creed, I offer both mine and Stoyan’s scripts (with his permission, of course).

Download Stoyan’s script Download my script (Warning: If you are a Python programmer, you may be horrified.)

Now, eventually a lot of this work will be obsolete, as the GeoServer developers are working on a RESTful interface that will allow for easy configuration changes from a command line.  I have seen a demo of this functionality, and it is impressive in its simplicity and its why-didn’t-they-do-this-sooner-ness.

Are there any interesting scripts or external programs you have employed when working with GeoServer?  If so, then speak up, as there’s a good chance that someone is encountering that very problem you’ve already solved.

Note: Comments have been restored to this blog after a long absence, so your comments will no longer be lost in the void.  Thanks for your patience on this one.

We’ve received some good feedback from the community on the first release candidate of version 1.7.0, and have made some improvements that we wanted to share with you.  This second release candidate is more stable and features some code-tightening as well (MIME types are now case insensitive, a limited SRS list persists again, and more.)  This is the most stable release yet of the new 1.7.0 branch and we encourage you to try it out.  If all goes according to plan, we should have a final release around the corner.