The Context Bucket

To avoid confusion I've callled the lump of data the 'context bucket' instead of the 'shopping basket' to kept the 'shopping basket' as the page where a user can see what endpoint have been selected.

This is a data object that will be accessable form PHP,Javascript, Python via HTTP requests.

There data contained is not secured in any way and it may be possible for someone to read and/or modify another users data.

The aim of this bucket is to join together unrelated catalogs, visualization, download and shopping basket pages.

  • catalogs - lists of datasets with WMS/WCS endpoints that can be added to the bucket to be used with the UI.
  • visualizations - let the user select layers from the WMS endpoints in the bucket and generate images
  • download - let the UI download data via a WCS endpoint
  • shopping basket - let the user see what is in the bucket and remove/reorder it.

Creation and Destruction

These buckets can be created by anonymous browsers, when created they are given an new ID which is then returned to the browser.

This bucket ID can then be used to add additional data to the same bucket or retrieve the data stored in the bucket.

These buckets have an associated expiry date when they should be cleared up, this expiry date could be extended by the user either manually or automatically when the bucket is accessed.

If the user logs in then these buckets can also become associated with a particular user name, this could remove the need for an expiry date or just extend it.

Then it would be possible for a logged in user to have multiple data buckets that they can select from. This would also be possible for an anonymous user, they would just have to remember the id's of the different buckets and prevent them from expiring.

What it will Store

  • A list of WMS + WCS endpoints
  • the active state for a number of pages

The state is stored so that the pages can be navigated from one to the other without having to re-select everything.

The WMS + WCS endpoints are stored so that after being selected on a catalog page they are available on the UI/Download page

Some aspects of a pages state can set by adding parameters to the page URL, this will overwrite the current state in the associated bucket (if one is present). It will be up to a page to correct the state in the bucket when additional parameters are received.


  • WMS/WCS endpoints
  • ui page
    • selected layers (in order) with:
      • selected lat/lon
      • with visualization parameters
      • selected dimensions
    • download get figure format
    • download make figure format
  • download page (assuming only downloading a single layer)
    • selected layer
  • selected lat/lon
    • data format
    • crs
    • selected dimensions

The status of the UI page could be described as a web map context document with some data stored in extensions (such as the display options for each layer).

An advantage of storing the UI state in this common format would be that multiple different applications could use the UI state, there could even be a 'generate web map context document' option.

Would it be allowed for two different visualization pages (both using the same bucket) to use the same document to store their state or would they both have a separate context document?

Required Interface

The bucket would need to allow HTTP requests to modify its contents.

To enable the smoothest navigation the page state would need be updated in the bucket as it happens rather than all at once when the page is navigated away.

Required Functionality:

  • add a WMS/WCS endpoint
  • remove a WMS/WCS endpoint
  • move a WMS/WCS endpoint up/down the list
  • get the WMS/WCS endpoint list
  • add page (e.g. wmsvis) property (e.g. lat_lon_selection) value (e.g. -180,-90,180,90)
    • this may not be a simple text string but a more complicated list, e.g.:

Selected layers:

1, ( Layer_1 , endpoint: ... , dimensions: ... , display options: ...) 2, ( Layer_2 , endpoint: ... , dimensions: ... , display options: ...) 3, ( Layer_3 , endpoint: ... , dimensions: ... , display options: ...)

  • get page (e.g. 'wmsvis') property (e.g. lat_lon_selection)
  • remove page (e.g. 'wmsvis') property (e.g. lat_lon_selection)
  • (possible?) get state for page ('wmsviz')
  • (possible?) add state for page ('wmsviz')


(by Dom): We also need to capture if a WMS endpoint has a particular WCS endpoint associated with it (as opposed to them just being distinct endpoints - which you might also want!).