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:
Copied a shapefile (and associated files) to the data directory
Appended info block to catalog.xml
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).
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.
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.