This page last changed on Mar 25, 2008 by jdeolive.

GeoWebCache Improvements


GeoWebCache a small java-based tile caching library. It was started during last years summer of code project under the name "JTileCache". It has been quite a success thus far, and improvements to it are in high demand.

This project will involve implementing various improvements to GeoWebCache, including implementing additional front-ends for publishing tiles, and additional back-ends for storing tiles. Along with implementing improvements the student will have the opportunity to become an integral part of a running open source project. This involves performing daily tasks which every open source developer performs, such as handling bug reports and interacting with users on the mailing list.

Any experience with tile caching libraries such as GeoWebCache or TileCache would be beneficial, but not mandatory.

Technical Details

Students will perform improvements in the following areas:

Front-End / Back-End Improvements

In GeoWebCache a "front-end" is a format in which tiles are delivered to a requesting client. A "back-end" is a format or location in which tiles are physically stored. When a tile request comes in, GeoWebCache must convert from the front end grid format, to the query format of the backend.

In GeoWebCache, front-end's and back-ends are pluggable, which makes it straight forward to create new implementations. An example of a new back-end implementation might be storing tiles in Amazon S3.


Currently GeoWebCache stores all of its configuration in property files. While this is acceptable for manually editing, it does not lend itself to programmatic configuration. A nice way to expose configuration is through a REST api, which allows clients to perform configuration programatically over HTTP.

Past configuration this approach also provides a nice way to provide access to the tile structure. Which would allow clients to programmatically add tiles (useful for tile seeding for instance), or to remove tiles (useful when data changes).

Statistics and Benchmarks

A useful feature would be the ability to capture benchmarks about incoming requests. Useful statistics could include:

  • response time
  • what data clients are accessing most frequently
  • concurrency load, number of thread statistics

This feature would most likely be implemented as a filter between the front end and the back end. In essence every layer would get something similar to an accounting object that would keep track of how often each tile is accessed. The results could for example be presented as an overlay, like a heat map. Timing, and information about the number of simultaneous requests, will make it easier for users to tune their servers and eliminate bottlenecks that depend on how their container is configured or the storage mechanism used for the tiles.

Document generated by Confluence on May 14, 2014 23:00