Greetings all.

I am new to the GIS world. Well, not entirely. I’ve been an avid map fan since I was a wee lad, and to this day I own a small but extensive collection of Rand McNally Road Atlases. Fast forward the tape a bit, and here I am at The Open Planning Project, as an Outreach Engineer for GeoServer. However, despite some years of working in technical fields and some more years of ogling nice-looking maps, I must confess that I was and still am, shall we say, a novice to the technology surrounding GIS.

Here at TOPP, I see myself as a facilitator between those who use GeoServer, those who code/develop for it, and those who are somewhere in between. That said, I’ve still needed to bootstrap myself into being versed in the terminology. So, I picked up “GIS for Web Developers” by Scott Davis. Since then I have thumbed through a few other books and a fair chunk of online information, but by far, this has been the most helpful in getting me started.

The book follows a fairly straightforward arc, starting with a discussion of vectors and rasters. Two of my initial questions were answered quickly. The first was “where does all this data come from?” and the second, “what exactly is the data, anyway?” These may seem trivial, but it’s of course very hard to not see as obvious things that one works with as a matter of routine. (I can recall being very perplexed when I was first introduced to the Web, when trying to figure out the URL. Where was it going? What was it doing?) Although I can’t create a Shapefile out of thin air now (Adobe Illustrator for some reason doesn’t have it in its Export menu) I know that I can probably find what I need either from government websites or a small but growing community of neogeographers. As for what’s contained in the data, the answer is “a gratifyingly large amount of useful info”. The book covers Shapefiles, PostGIS databases, and other standard formats of the trade.

The discussion makes a sharp turn and delves into command-line utilities for editing and querying data inside spatial databases. Perhaps it was my background, but I thought that this topic might have sat more comfortably towards the back of the book, as it’s good information, but with a much steeper learning curve than what came before it. After delving very deep into the OGC web services, the book ends with a “Final Exam” of the complete process from non-geocoded data to spatial database to web browser. If one can follow the last chapter, one understands the relevant concepts. I think I’m nearly there.

One of the most beneficial aspects of the book was the clear definitions of terms, as the meanings of, say, DataStore and FeatureType were not intrinsically obvious to me. It was also quite nice to see GeoServer represented so favorably in the book, both from a practical point of view and as well from a root-for-the -home-team sort of way. But ESRI’s ArcExplorer is given as much treatment as, say, MapBuilder, which is nice for comparison’s sake. I have yet to spend too much time on anything past GeoServer and OpenLayers, but that’ll change in time, I’m sure.

Personally, I wished the book had delved more quantitatively into projections. However, I recognize that my interest lies mainly in the mathematics, and the tools that people have created shield the user from some of the more unseemly calculations. My coworkers have consistently said, “you don’t need to know any of that stuff,” which may in fact be true, but keeping projections as a black box isn’t quite in the spirit of the book. It’s a minor gripe, though.

All in all, I found this a great book with which to get started. While not trying to hide from the jargon, the reader isn’t bogged down with so much granularity that the plot is lost. That’s a sweet spot that most technical books miss. I’m no expert, and won’t be for a while, but at least I feel like I know what questions to ask. And knowing how to ask the right questions is so much more difficult than finding the answers.

Many of you have likely noticed that the main GeoServer site is migrating from docs.codehaus.org to the much easier to remember geoserver.org. This has been a long running process, that we’re finally approaching the end of. We were hoping to have automatic redirection from the old site to the new, but are waiting on a task to be done on the codehaus server (you may be able to help by voting on the issue - follow the link and if you have a jira account you should be able to click a link to vote). If that doesn’t happen then we will likely delete those spaces in a month or two, so please update your bookmarks to the documentation now, so that they continue to work. Note the structure of the pages is exactly the same as the old, so if there is a page like http://docs.codehaus.org/display/GEOS/Roadmap the new location will be http://geoserver.org/display/GEOS/Roadmap.

Though he’s already snuck in a blog post, I want to give a warm welcome to Mike Pumphrey, the new ‘outreach engineer’ at TOPP, who we’re going to see a lot more of on this blog. His role is still being defined, but he’s basically here as a resource to the community, to help out with documentation, to welcome new users, to manage releases, to create compelling demos, to make announcements, and much, much more. In time he’ll also be leading up commercial quality web and telephone support around GeoServer, and creating mapping applications for clients. But he’ll always be available to help out on irc (where he is known as bmmpxf) and on the email lists, so help him out as he gets up to speed, and soon he’ll be helping you out.

Just a quick shout: The .war for GeoWebCache 0.7.0 was accidentally compiled using a mixture of Java versions and was therefore quietly replaced with 0.7.1 the same morning. Since then Andrea and Jason have been busy reporting bugs, most of which have been closed. Updates include the return of JAI, support for vendor specific parameters in the configuration files, and image/png8 support. So without further ado, GeoWebCache 0.7.2.

GeoWebCache 0.7.1 is out on SourceForge. There was an issue with the WAR file, so the release has been bumped by .1 since last night. The actual code diff to 0.6.0 is 3746 lines (excluding openlayers and the formatter.xml), so there is a substantial number of changes under the hood. One of the main things is that layers now have a grid parameter and a bounding box. The grid should be the maximum extent of the coordinate system and is used to calculate the internal grid, and which is directly reflected in the cache keys. Separating these two means that you can later expand or reduce the bounds of the layer, and cached tiles will still work.

Other changes include:

• Support for multiple WMS backends per layer, queried in round robin fashion with automatic failover

• Microsoft Virtual Earth tiling support

• Google Maps tiling support

• Improved handling of layer bounds, give a rough estimate and it will approximate to closest metatile for all zoom levels

• Ability to run Jetty directly in Eclipse

• Some code cleanup, using GeoTools coding standard now (almost)

• Reduced JCS dependecies (berkeleydb,hsqldb,mysql), thereby cutting download in half

• Included configuration files and OpenLayers clients for topp:states, for testing

• Various bugfixes

The keen observer will note that this has very little to do with the features originally scheduled for 0.7, but it’s a lot of improvements nonetheless. Please make sure to revisit the configuration notes in the wiki since a number of things, including names of configuration parameters, have changed.

I have noticed that a number of people have reported problems with data in SRSs different from EPSG:4326 and EPSG:900913. Note that the the WMS Tiling Recommendations do not cover other reference systems, but we would be happy to look at them if you supply data and a little bit of your time.

Looking ahead we want to branch out in two separate directions. On one hand we want to integrate more tightly with GeoServer, which was originally planned for this release, on the other hand there appears to be demand to support other backends than WMS. While these are in no way mutually exclusive, supporting other backends would require some internal rewiring (Andrea Aime has suggested the Spring framework, which is also used in GeoServer and in many other high profile projects). Feel free to voice your opinion, especially if you are inclined to contribute in one way or the other.

QA is also becoming a serious concern at this point. Version 0.7.1 includes 18 unit tests that exercise the internal grid / metatiling system a fair bit, and it includes configuration files and OpenLayer clients for testing topp:states (loaded from a remote server) with EPSG:900913 and EPSG:4326. This is not enough, other parts of the system require additional tests, and functional ones to test the package as a whole, but it’s a start.

Thanks to everyone who has contributed patches and feedback, I look forward to hearing from you.