Context Navigation

GeoWebCache 0.8.0

Version 0.8 has seen a lot of changes over 0.7.2, here are the most important ones.

To accommodate future changes the URL structure has changed. WMS no longer answers on http://yourserver:8080/geowebcache/wms, but is now moved to http://yourserver:8080/geowebcache/service/wms , Similarly there I apologize if this inconveniences anyone, if you use Apache for proxying you can accommodate for this change.

The major one being that GeoWebCache, in preparation for integration with GeoServer, is now using Spring 2.5.2. You can read more about the spring framework on their pages, the main advantage is that it should be easier to extend GeoWebCache with new features. Another good thing is that Spring makes the application more flexible, much of the structure that had to be coded statically is now described in an XML file and put together at runtime.
You are encouraged to examine WEB-INF/classes/applicationContext.xml and send questions to the user list.

The JAI wraper that was introduced in 0.7 appears to have some issues with JPEG. More specifically, it would always return the bottom left tile of a metatile. As a temporary solution, GeoWebCache will now revert to Java 2D when processing JPEG images.

GEOSERVER_CACHE_DIR, either as a system environment variable, Java environment variable or set as a context parameter in web.xml, determines the default location for where GeoWebCache will store its cache. See notes on "Changes to File Storage" below.

GeoWebCache will now, in most cases give the end user a sensible error message if an environment variable is missing or invalid. If you find cases where you see tracebacks, please report them as tickets. At the same time, logging (unless you enable trace or debug) has become less verbose in production, but it will write more info during startup.

Each layer can now support multiple projections. If you choose to do this, you need to also specify a bounding box and grid for each projection. These boundingboxes are semicolon separated. Note that GWC still only supports EPSG:4326 and EPSG:900913 officially.
There is a new configuration option layername that lets you specify the name for the layer. This overrides the previous convention of using the midsection of the filename, and allows you to use names that contain : on Windows. Note that a layername can also contain commas, giving clients the impression that there are two layers.
See WEB-INF/classes/layer_states.properties for an example of both

To accomodate for the feature above the storage needs to be prefixed with the chosen projection. So if you have a layer topp:states that supports both EPSG:4326 and EPSG:900913, and GEOWEBCACHE_CACHE_DIR is set to /tmp/geowebache, it will create two directories /tmp/geowebcache/topp_states/EPSG_900913 and /tmp/geowebcache/topp_states/EPSG_4326 and store the files in these structures. If you have already seeded a layer you can manually copy the subdirectories into this new structure.
cacheprefix, which replaces the old filecachepath property, overrides GEOWEBCACHE_CACHE_DIR and also prevents the addition of the layer name. This means two .properties files should never contain the same cacheprefix= setting.
If none of these variables exist, GeoWebCache will revert to the TEMP variable (if set) and prefix with geowebcache. The structure then becomes something like /tmp/geowebcache/layername/srs/zoomlevel/000/000/000/000.png

GeoWebCache supports KML super overlays for Google Earth. The simplest example is to install Google Earth and go to http://yourhost:8080/geowebcache/service/kml/topp:states.kml (replace topp:states with the name of your layer). It creates KML (a dialect of XML) files automatically and links to images that are superimposed on the surface of the earth.
The mentioned example defaults to PNG images. You can request other image types by inserting a second file extension before the .kml: http://yourhost:8080/geowebcache/service/kml/topp:states.jpeg.kml

GeoWebCache can be automatically configured based on a WMS server, by making a getCapabilities request and parsing the resulting XML. Currently this relies on the WMS module of GeoTools?, which bumps the download size up considerably, so it may be replaced with a small SAX parser in the future.
Note that the automatic configuration copies the layer names from the WMS server. If you end up with two layers with the same name, either from two different WMS servers or from a combination of .properties files, there is no guarantee which one will be used.

The seeding mechanism has not changed much, and is still very simple, but has a new access control. In applicationContext.xml there is a section that lets you defined what IP addresses may access the seeder. By default this list only includes 127.0.0.1, which should make it secure. Note that this does not prevent people from seeding your cache by running their own script against the WMS service.

One of the main objectives for the 0.8.0 release was to be able to integrate with GeoServer. This introduces a small problem because the layers are determined from the WMS getCapabilities request. However, Jetty is not listening on port 8080 until after all the Spring beans are initialized. Consequently layers are now parsed on the first request, not during startup. I will be looking for a way to improve upon this, but for the time being this makes it extra important that you make a test request to GWC after you make changes.