GeoServer

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.

GeoServer 1.6.2 is now available for download here. This is a Security Release, which means it contains fixes for two Security Vulnerabilities. We highly recommend that you upgrade to this version. We found out about both these vulnerabilities in the past couple days, and made an effort to fix them and get this release out as quickly as possible. One of the issues also affects older versions of GeoServer. We are not doing a security release for it at this time for all the older versions, but have clear instructions on how to update one file to disable the page where the exploit is possible. We highly recommend that any production instances of GeoServer follow this, it should be easier to do than a full upgrade.

The GeoServer team announces the release of GeoServer version 1.6.1! Here are some of the highlights in this release:

GeoServer now supports FeatureType aliases, which allows for the creating of friendly names for unwieldy FeatureTypes. Also, support has been added for limiting (per FeatureType) the maximum number of features that can be requested by a client, thus easing server load. (Thanks to Landgate for funding both of the above!). Cédric Briançon from Geomatys contributed the GetFeatureInfo operation on WMS coverage data, and GeoServer can now output PDFs from raster as well as vector data. Saul Farber of MassGIS added support for UpdateSequence, which returns a “revision number” of the capabilities of the service; this gives clients more efficient access to the Capabilities document. Also, there have been improvements in MySQL integration: The Java connector was updated, performance was improved, and GeoServer is now using the more-efficient Well Known Binary protocol.

In total, this new release contains over 40 patches and improvements since 1.6.0. (You can view the changelog for details. You can download this latest version from geoserver.org. As usual, we thank everyone who has tested out the software and reported issues. Please continue to submit bug reports using our bug tracker.

Early this year I submitted an article to GIS Development and it got published in the February issue!! You can check out the article here. Let us know what you think.

Since I have been the intern at The Open Planning Project for a couple of months, I think that its about time I introduce myself and what I have been up to. First the introductions. I am Ivan Willig, an undergrad at College of the Atlantic and currently studying urban planning. Now to my work. As some of you might know (if you read this blog) Tim Coulter and Sebastian Benthall have doing some excellent work with GeoServer, Versioning WFS and OpenLayers. The software uses versioning to allow shared editing and viewing history of edits. I have taken their work and applied it to make a new GeoServer user’s map. You may remember the old map, kind of slow and hard to use. I hope that ease of use of the new GeoServer user’s map will encourage all you GeoServer people to post. You will find the GeoServer user’s map at http://sigma.openplans.org/users/. It should be fairly self-explanatory, however if you have any questions let me know at iwillig [at] openplans.org.

You might also notice that user’s map is using nicer styles for the Tiger dataset on Sigma. Tiger is the US Census data set that has high quality data for the whole United States, road, water-bodies… etc. This was the other part of my work at TOPP, redoing the styles for the Tiger dataset. I am building off the work done by Arne Kepp and Portland’s TriMet.

To find out more about integrating GeoServer and Tiger information please visit the GeoServer wiki http://geoserver.org/display/GEOSDOC/Loading+TIGER+data.

Vmap is a similar dataset, produced by the Department of Defense, but covering the whole world.
Check out this tutorial out for more info. http://docs.codehaus.org/display/GEOSDOC/Loading+VMAP0+data .

GeoWebCache is finally out in the open and announced on freshmeat.net and other pages. This should really have happened a long time ago, and there are many reasons for why it didn’t, but I am very excited about the current momentum.

GeoWebCache, is a tile cache, meaning it acts as a proxy between the client and the WMS server (GeoServer) and stores the image. If another client requests the tile it can respond in milliseconds, regardless of the complexity of the tile. It is different from a regular HTTP proxy, such as Squid, in that it interprets the parameters and matches them to the best tile supported by the configuration.

It is currently not as mature as say Tile Cache, but has the advantage that you do not need a webserver with Python support. It can either be run in Tomcat, alongside GeoServer, or as a standalone server using Jetty (no binaries are available yet, but we will make them soon).

We have not been sitting still since releasing 0.6.0 either. Based on a customer request we have already added native support for Microsoft Virtual Earth’s quadkey scheme. This is currently available in the repository, and we’ll probably push it out in a new version soon, after looking into whether we can do the same for the Google Maps API.

Looking to version 0.7.0 and beyond we will start working on integrating GeoWebCache more tightly with GeoServer. Some key features are

• Automatic configuration based on what layers are available . This will obviously have some limitations, since there are important parameters that the user will have to make some decisions on.
• Update events, so that when the data changes on the backend GeoWebCache will automatically purge the affected tiles and (optionally) reseed them.
• A nice RESTful API that we can program an easy to use JavaScript client against.

There are some internal structures that should still be simplified, and now that the basic structure has solidified we’ll gradually start adding tests.

Want to see it in action? http://sigma.openplans.org has been using GeoWebCache for over two months (and uncovered some bugs in the process). We look forward to upgrading the site with something that is really pretty to look at, probably soon.

Please sign up to the mailing lists if you are interested, we’d love to hear back from you so that we can fix bugs, improve the documentation and stake out the general course.

The GeoServer team is excited to announce that GeoServer 1.6.0 has been released. There are a host of advances from 1.5.x, and many GeoServer users have been testing the release candidates and giving us great feedback, so this final release should be very stable. Foremost among the improvements is a huge performance increase in the rendering of maps (WMS), bringing GeoServer speed that matches the fastest mapping engines in the world. The other big focus has been on tightening everything up, as we’ve been getting more and more feedback from production deployments of GeoServer (which we’ll highlight soon in this blog).

The most cutting edge new feature is support for ‘versioning’ as extensions to WFS-T. This allows users to edit geographic data as if it was a wiki or in a version control system like svn. You can check out the preliminary demo, though we’re working on a more intuitive user interface. The start of that can be seen on our New York annotation demo, which also has a base map served by GeoServer. Right now only PostGIS can support versioning, but we’re hoping to find funding to hook it up to the native versioning in ArcSDE and Oracle Spatial.

There are also a number of other new features, including WFS 1.1 support, which adds reprojection when accessing raw data, as well as the ability for queries to return the number of results expected before getting the full results. We’ve also added a new integrated security subsystem, built on Acegi, to provide role-based access control to GeoServer resources. There is also improved connectivity to Google Maps/Virtual Earth/Yahoo! Maps, leveraging better integration with OpenLayers as well as bug fixes for our Google Earth support.

Also added is the WFS datastore, enabling GeoServer to serve as a Cascading WFS and a Component WMS (also known as a Feature Portrayal Service). Another cool improvement is our WMS reflector, which makes it a lot easier to experiment with map rendering through the browser. There are countless other improvements and fixes, in all over 400 issues were handled for the 1.6.0 release.

Stay tuned for the 1.6.1 release, we’ve already got a bunch of improvements lined up for it that we’ve held off on to get 1.6.0 absolutely stable. Thanks to everyone for all your hard work on this one, it’s a great step forward for this community, and the future is looking quite bright. And just to give the link one more time, the release can be downloaded from geoserver.org.

Though it’s a bit overdue, we finally got around to updating the GeoServer Roadmap.  There’s a lot of activity going on, and we generally have a good sense of what should be completed in the next three months, with more and more vague ideas on what may be further out.  I still want to work some more on the long term / dream section, as I’ve had some more fun thoughts recently.  But there should be a lot of great work in the next few months, which is exciting.  Highlights include online SLD editing, integrated tile caching, security improvements, a better ‘preview’ application, and more.  The thing I’m most excited about is the REST configuration service, which should make it much easier to add data programmatically, and is how we’re going to integrate with GeoNetwork Open Source.

The best part of updating the roadmap is looking back at what we hoped to accomplish and seeing what we succeeded in.  This time is a bit of a softball, since we are late on updating so the ’short term’ ones were supposed to be finished several months ago.  But we aimed to do quite a bit, and most of it has come to pass.  GeoServer 1.6.x is just about to go to 1.6.0, with not only a new security framework, WFS 1.1 and versioning WFS, but also great increases in speed and reliability.  KML support has improved a lot, and is only getting better, as we have some more funded work to make it stream large datasets really well.  The new output formats - GeoRSS, 8bit PNGs, and GeoJSON are now all released and performing well.  And we’ve got a new security system and backend for geocollaboration.  The prototype for a GeoServer 2.0 was built, and feels ready to move on, though unfortunately it has not moved much past a prototype phase.   The only short term goal that was not completed was ECW, MrSID and JPEG2000 support, but those are actively being worked on right now, and we expect at least one pretty soon.  Thanks to everyone for all their hard work, things are really coming together in to a great product, and the future looks even brighter - we’re truly only just getting started.