Automation with the administration REST API¶

Understanding the zip file uploads¶

The description of a collection and product is normally made of various components, in order to expedite data creation and reduce protocol chattines, it is possible to bulk-upload all files composing the description of collections and products as a single zip file.

Template variable expansion¶

Some of the metadata/HTML description can embed simple templating variables that GeoServer will expand while generating output. Here is a description of the variable, and where they can be used

Usage of the API for search and integrated OGC service publishing¶

In this case the user intend to both use the OpenSearch module for search purposes, but also to publish actual mosaics for each collection.

In this case the following approach should is recommended:

• Create a collection via the REST API, using the ZIP file POST upload

• Create at least one product in the collection in the REST API, using the ZIP file POST upload and providing a full granules.json content with all the granules of said product

• Post a layer publishing description file to /oseo/collection/{COLLECTION}/layers to have the module setup a set of mosaic configuration files, store, layer with eventual coverage view and style

A collection can have multiple layers:

• Getting the /oseo/collection/{COLLECTION}/layers resource returns a list of the available ones

• /oseo/collection/{COLLECTION}/layers/{layer} returns the specific configuration (PUT can be used to modify it, and DELETE to remove it).

• Creation of a layer configuration can be done either by post-ing to /oseo/collection/{COLLECTION}/layers or by put-int to /oseo/collection/{COLLECTION}/layers/{layer}.

The layer configuration fields are:

The layer configuration specification will have different contents depending on the collection structure:

• Single CRS, non band split, RGB or RGBA files, time configured as an “instant” (only timeStart used):

  {
      "workspace": "gs",
      "layer": "test123",
      "separateBands": false,
      "heterogeneousCRS": false,
      "timeRanges": false
  }
  

• Single CRS, multiband in single file, with a gray browse style, product time configured as a range between timeStart and timeEnd:

  {
      "workspace": "gs",
      "layer": "test123",
      "separateBands": false,
      "browseBands": ["test123[0]"],
      "heterogeneousCRS": false,
      "timeRanges": true
  }
  

• Heterogeneous CRS, multi-band split across files, with a RGB browse style (“timeRanges” not specified, implying it’s handled as an instant):

  {
      "workspace": "gs",
      "layer": "test123",
      "separateBands": true,
      "bands": [
          "VNIR",
          "QUALITY",
          "CLOUDSHADOW",
          "HAZE",
          "SNOW"
      ],
      "browseBands": [
          "VNIR[0]", "VNIR[1]", "SNOW"
      ],
      "heterogeneousCRS": true,
      "mosaicCRS": "EPSG:4326"
  }
  

In terms of band naming the “bands” parameter contains coverage names as used in the “band” column of the granules table, in case a granule contains multiple bands, they can be referred by either using the full name, in which case they will be all picked, or by using zero-based indexes like BANDNAME[INDEX], which allows to pick a particular band.

The same syntax is meant to be used in the browseBands property. In case the source is not split band, the browseBands can still be used to select specific bands, using the layer name as the coverage name, e.g. “test123[0]” to select the first band of the coverage.