GeoWebCache Integration Feature Set

F01: GWC admin page

Provide a GWC admin page with a GUI consistent with the rest of the web app

  • Show the disk space used by the cache. May be show the disk space used by the more demanding layers.
  • Allow GeoNode admins perform the following GWC admin functions through it:
    • Change the global cache disk usage limit
    • Request the truncation of all the tiles for a given Layer. Optionally specifying which of the layer CRS's and/or Styles to truncate.
    • Define a GridSet
    • Register a GeoRSS "update source" for a Layer

Back traces:

Derived Work Items

Ticket Summary Resolution Estimated Hours
#604 GWC Admin summary page fixed 12
#605 GWC truncate page fixed 12
#606 Set GWC cache size limit admin page fixed 4
#607 GWC admin page to define a GridSet invalid 16
#608 GWC admin page to set a GeoRSS update source for a Layer wontfix 8


F02 - Track cached/uncached versions of the same Layer

When editing, the viewer should be able to determine when it is appropriate to bypass the cache and switch between them without direct intervention by the user. An (the?) example is the styling application embedded in the main viewer. To this end, the layer model the viewer uses shall hold the URL end points of the original WMS service as well as the one for the GeoWebCache version of the layer, and be able to switch between them as required.

Back traces:

Derived Work Items

Ticket Summary Resolution Estimated Hours
#609 Track cached layer on Django and JavaScript layer model invalid 8
#610 JavaScript client layer source switching fixed 16


F03 - Python/Django client for GWC REST API

This client should be integrated with:

  • the map editor
    • adding layer, either "local" or "remote", should invoke a hook that adds the original WMS and the GeoWebcache service end points for the layer

Back traces:

Derived Work Items

Ticket Summary Resolution Estimated Hours
#618 Python GWC REST client: Design and prototype invalid 8
#619 Python GWC REST client: WMS Layers invalid 8
#620 Python GWC REST client: GridSets invalid 16
#621 Python GWC REST client: Truncation invalid 8
#622 Python GWC REST client: Disk Quota invalid 8
#623 Python GWC REST client: GeoRSS update sources invalid 8


F04 - GWC REST API

The integrated GWC instance shall be fully configurable through its REST API. For instance, it shall be possible to execute the following operations:

  • Define a GridSet
  • Add a remote WMS Layer
  • Remove a remote layer (subsequently eliminating its cache)
  • For an existing Layer (either local or remote), start caching a new WMS Style
  • For an existing Layer (either local or remote), stop caching the layer for a given Style, subsequently cleaning up the cache for that Layer's Style
  • Truncate the cache for a Layer
  • Set a global cache disk size limit
  • Register a GeoRSS "update source" for a Layer

Back traces:

Derived Work Items

Ticket Summary Resolution Estimated Hours
#611 GWC REST API: GridSets invalid 8
#612 GWC REST API: WMS Layers invalid 12
#613 GWC REST API: Style caching wontfix 12
#614 GWC REST API: Layer truncation invalid 4
#615 Implement global cache size limit for the diskquota module fixed 16
#616 GWC REST API: Disk Quota fixed 8
#617 GWC REST API: GeoRSS update sources invalid 8


Feature(s): Resolve thes problems:f

  • If we set the disk limit too low we may just end

up with a lot of cache churn for little/no performance benefit. And the disk requirements can grow with minimal warning, since anyone can add a layer.

  • There's also an easy DOS attack - anyone can fetch 18 zoom levels

of some layer nobody uses and trash the cache (not a huge deal, how long would it take an attacker to do that anyway?).

  • Refine caching limits based on usage tracking.

Feature: allow the person who adds a GeoRSS location to automatically truncate from. Q: Can this location be reset? By whom?

Feature Set

Feature GWC_F02 - GWC DiskQuota global limit Derived from: almost everywhere :)

Future Wish List and Ideas

  • Optional feature: every 1000th access to a tileset we re-fetch a tile that's already available from the cache. we do a simple image comparison and if it doesn't match the old cached tile, we invalidate all tiles within that image's bounding box. if more than half of the image doesn't match we invalidate all adjacent tiles, etc etc.

I think the complexity of implementing this is not worth the benefit

  • Feature: enhance the geoserver georss output format (actually not the wms output format. This looks like a whole new beast using transaction listeners?) to send both the new and old values for the affected geometries, so that a GeoRSS feed can be used to truncate the cache based on the affected area when the data changes
  • Distant Future Phase: A push model for changes so that the truncation doesn't have the snags that inevitably happen with the above model....
  • Alternative Future Phase: Implement versioning and use revision numbers the truncation doesn't have the snags that inevitably happen with the above model....
  • Alternative alternative future phase: Rely on data versioning/merging/federation and truncate cache based on that.

Return to the overview page