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
