GeoWebCache Integration Use Cases
The following is the distilled list of use cases for the GeoNode's GeoWebCache integration project proposal. Most of them derive from the User Needs document, whilst some may derive from further analysis or knowledge of limitations of the software components involved that complement the initial statement of needs.
Note: in the use cases bellow, "Priority" assumes one of the following values: <Essential | Expected | Desired | Optional>, and Status one of <Approved | Validated | Pending validation | Rejected>
Remote Caching
Use Case 0a: Cache remote layer
Priority: essential
Status: approved
Description: Adam uses a layer from a remote WMS in a GeoNode map. That layer is automatically included in the GeoNode search index (GeoNetwork) and the GeoNode GeoWebCache cache. From that point on, whenever Adam or any other user accesses the layer through a GeoNode's tiled map, the JavaScript client requests tiles to the GeoWebcache instance instead of the original service end point.
Notes and Questions:
- Note: Adding a layer to GeoWebcache does not imply automatic seeding. It should always be a lazy cache so that only the tiles that are actually used get cached, tradeoff being possibly having a slower turn-around the first time a tile is requested.
- Implemetation note: Given the possibility of layer name clashes when adding layers from different sources to the same GWC instance, it may be a good option to use the Django app UUIDs as layer name, at least for remote layers?
- Question: Which CRS's and styles get cached for a given layer? A: Cache only the CRS's used in GeoNode webapp views, and only those styles that are requested
Traces:
Use Case 0b: Truncation of Layers based on GeoRSS feed
Priority: desired
Status: validated
Description: Charles publishes a GeoRSS feed of changes to the data layer used and cached by Adam in Use Case 0a. GeoNode indicates GeoWebCache to periodically check this feed for that Layer to invalidate the cache only for the affected area.
Traces:
Use case 0c: WMS Service Registration
Priority: Optional
Status: pending validation
Description: Daniel registers a new WMS service with GeoNode.That WMS gets added to GeoNode's GeoNetwork index, and its metadata pages become available in the Django web app.
GeoNode periodically scans the capabilities for added/removed layers, updated descriptions, new styles. These would be reflected in GeoNetwork and GeoWebCache as well as the Django database.
Notes and Questions:
- Question: See GeoRSS feed-based updating above. Should implement that for these services?
- Question: What is 'periodically' precisely? Who sets that?
Traces: Python client for GWC REST API
Use case 0d: WMS Service registration through Composer
Priority: Optional
Status: pending validation
Description: Adam adds a WMS via the composer application. That WMS becomes registered with GeoNode, as in Case 2b
Notes and Questions:
- Question: Who owns (has privileges on) those layer records in this case?
- Ee don't provide editing or styling for these. what privileges exist?
- allowed to reseed cache
- allowed to remove the layer (or service)
Use case 0e: <name?>
Priority: Optional
Status: pending validation Note: doesn't it duplicate Use Case 0c?
Description: Earl has an existing SDI implementation based on MapServer and Drupal. He wants to get faster (cached) access to a WMS, so he adds it as a service to a GeoNode to take advantage of its automatic caching. *
Notes and Questions:
- Implementation note: Having the WMS capabilities handled on the server side (and cached there) would probably be a nice win for loading services. We could do away with reading capabilities entirely until the user pulls up the add layers dialog (which is not available in the embedded viewers).
Local Caching
Use case 1a: Cache local Layer
Priority: essential
Status: approved
Description: Bob uploads a new layer to GeoNode. This registers the Layer into GeoWebCache.
Traces: Python client for GWC REST API
Use case 1b: Bypass cache on Style edition and invalidate cache on style submission
Priority: essential
Status: approved
Description: Bob starts editing one of the styles of the layer he uploaded in Use Case 1a. While he's working on the style, the JavaScript application bypasses GeoWebcache by hitting the original WMS end point.
When Bob finishes editing the Style and hits the submit button, the cache for that Layer/Style combination is invalidated and the JavaScript application switches back to the GeoWebCache end point for the layer. GeoWebCache responds
with tiles having the modified style applied.
Traces:
Use case 1c: Cache new Styles
Priority: expected
Status: validated
Description: Bob adds a new style to a Layer. When he submits it, the style gets automatically cached for that layer and the JavaScript application managing the Map automatically switches to the GeoWebCache WMS-C end point.
Traces:
Use case 1d: Invalidate cache for a Layer/Style upon Style deletion
Priority: expected
Status: validated
Description: Bob disassociates a Style from a Layer (delete it?). The association is automatically removed from the GeoWebCache configuration for that Layer and the cache for the Layer/Style combination is cleared.
Traces:
Use case 1e: Invalidate layer cache upon new layer version upload
Priority: essential
Status: approved
Description: Bob uploads a new version of the layer he uploaded in Use Case 1a. This invalidates the cache for the whole layer and resets it.
Management
Use case 2a: Limit max cache size
Priority: essential
Status: validated
Description: Mike, a site administrator, opens the GWC admin page and checks the status of the cache in terms of configured cache disk size limit and current usage. He notes the cache size is reaching the configured limit in GeoWebCache, but also that the configured limit is rather low. As there's still plenty of disk space available in the filesystem where GeoWebCache cache resides, Mike decides to increase the cache disk size limit. The admin page allows him to set a new maximum cache size by typing a numeric amount and selecting a storage unit. He types 50 and selects GiB as the storage unit, hits submit, and the page refreshes reflecting the new cache limit.
Alternative scenario 1: There's no limit set for the maximum cache disk size. So the admin page says. The cache usage is above 100GiB though. Mike sets the max cache size to 50GiB. When he submits, GeoNetwork starts cleaning up tiles from the cache until it reaches the 50GiB limit.
Alternative scenario 2: Mike needs to free up some disk space, but the cache usage is near the configured maximum of 50GiB. Mike sets a new limit of 25GiB. When he submits, GeoWebCache starts cleaning up tiles from the cache until it reaches the new limit.
Traces:
Use Case 2b: Manual cache truncation
Priority: essential
Status: validated
Description: Adam has been using a remote WMS in a GeoNode map, and is in communication with Charles, the owner of the remote WMS. Charles informs Adam that he has changed the data (and/or style) for the layer in question. Adam should be able to invalidate the cache through GeoNode.
Notes and Questions:
- Note: On a first version, it is foreseen that only site administrators can manually trigger layer truncation
Traces:
Return to the overview page
