Welcome to GISWeekly!
GISWeekly examines select top news each week, picks out worthwhile reading from around the web, and special interest items you might not find elsewhere. This issue will feature Industry News, Top News of the Week, Acquisitions/ Agreements/ Alliances, Announcements, Financials, New Products, Around the Web and Events Calendar.
GISWeekly welcomes letters and feedback from readers, so let us know what you think. Send your comments to me at Email Contact
Susan Smith, Managing Editor
GeoWebCache Takes the Ouch out of Tile Caching
By Susan Smith
The need for a caching solution that could be easily integrated with GeoServer drove the development of GeoWebCache, a product that seeks to break down the limitations of tile caching. For those unfamiliar with GeoServer, GeoServer is an open source software server written in Java that allows users to share and edit geospatial data. Designed for interoperability, it publishes data from any major spatial data source using open standards.
GISWeekly: What was the impetus behind the creation of GeoWebCache? The history?
Through Google Summer of Code Chris Whitney was able to spend a summer creating what became known as jTileCache. It had very basic functionality, but also original ideas like using the Java Caching System to store image objects and compress them on the fly. Over the next nine months that code was then reworked by OpenGeo into what is today known as GeoWebCache. Through external funding we were able to add native interfaces for Virtual Earth and Google Maps, making it easy to use those clients against data served by WMS servers.
Last summer the project benefited from another generous Summer of Code grant, allowing Marius Suta to contribute code that enabled XML configuration using XStream and a RESTful configuration interface.
Google's Open Source Office has also funded OpenGeo to add streaming Google Earth support to GeoServer, and GeoWebCache benefited from this, gaining the ability to tile and cache KML placemarks and vectors.
Looking forward, we are continuing to break down some of limitations commonly associated with tile caches.
GISWeekly: What is GeoWebCache’s relationship to the GeoServer?
GeoServer is sort of like an older sibling. GeoWebCache has benefited tremendously from the collective experience of the GeoServer developer community and the feedback from GeoServer users. They have had a strong influence on the design and helped identify bugs. Originally GeoWebCache was intended to be a library for GeoServer, but since the WMS standard provides a very stable interface it turned out to be just as easy to develop a separate servlet.
GeoWebCache was first included as a plugin in GeoServer 1.7.1. In the 1.7.x series it basically has the same functionality as a standalone version of GeoWebCache, but the plugin is automatically configured and has a reduced footprint since it shares many libraries with GeoServer.
In the 2.x series of GeoServer, which is currently at the alpha-stage, we have started going beyond what can be achieved using the standard HTTP requests. If a layer is added or reconfigured, the tile cache will be informed immediately through a callback interface and reevaluate any existing tiles. However, GeoWebCache also has a RESTful configuration interface that allows other servers to achieve the same effect.
GISWeekly: What is new in the 1.1.0 release?
The main improvement in version 1.1.0 is the support for "modifiable parameters.” Other tile caches have associated one layer name with one set of tiles, meaning they only consider the bounding box and the layer name of the request, the rest is defined by the configuration of the cache. GeoWebCache has for a long time supported a separate set for each combination of spatial reference system and output format.
The new release takes this one step further, allowing you to configure filters and specify what other parameters constitute a set of tiles. For example, you can now serve the same layer with multiple styles, you can apply CQL filters, or you can use the time and elevation parameters introduced in WMS 1.3.0. One of the filter types uses regular expressions, which are extremely flexible, and the other is written for matching floating point numbers.
One existing feature that many users appreciate is the automatic configuration of GeoWebCache from a WMS getcapabilities document. The drawback with using this method has been that you could not specify additional projections or output formats. In 1.1.0 this problem has been reduced, if the configuration file and the getcapabilities document have overlapping layer names the two configurations will simply be merged. In the long run we still hope to provide an AJAX interface to make this easy.
Very basic WFS caching is included in 1.1.0. The motivation behind this is that GeoServer's WFS supports zipped shapefiles as an output format.
These can be several hundred megabytes and very expensive to compute, so any public server should cache them. Again, you can limit what queries are allowed by using a regular expression, but this is definitely a feature that will be improved over time.
But most importantly, the 1.1.0 release lays a lot of the groundwork for future development. Key to this is the pluggable H2 database which stores meta information about tiles, so that it will now be possible to remove tiles that have not been accessed in a certain time period, or find tiles that have been outdated by a recent change.
GISWeekly: Does GeoWebCache work with other open source software? Is it mostly used by developers?
GeoWebCache works great with any WMS compliant server, including MapServer and deegree. But there are also a number of people who use it in front of ESRI products, Ionic and even custom WMS servers. On the client side it currently works with any software that can use the OSGeo WMS-C recommendations, including OpenLayers and uDig. There are also custom clients that use the Google Maps API.
The user base is anything from professional developers to home users.
Based on the activity on the mailinglist, my impression is that developers are actually the minority. Most questions appear to come from end users who own an existing WMS solution and wish to improve its performance or reduce costs.
While some understanding of WMS makes life easier, there are also those that do not want to deal with OGC services and use GeoWebCache so that they can access their data in Google Earth or use the APIs that Google Maps and Virtual Earth provide.
GISWeekly: How does GeoWebCache speed up delivery of geographic data from OGC Web Services?
GeoWebCache acts like a proxy between clients and one or more WMS servers. When the client makes a request, GeoWebCache first checks to see whether it already has the corresponding tile. If not, the request is forwarded to the appropriate WMS server. When the response comes back, GeoWebCache first saves a copy (caches) and then forwards it to the client. The entire process adds only a few milliseconds to the time it takes to do the WMS request. Subsequent requests for the same tile are then answered in milliseconds using the copy, with the added benefit that this requires no resources on the WMS backend.