Extension to specify simple styling/processing expressions

[jerstlouis]

We have been experimenting with how to style coverages in CMSS, e.g. being able to select which bands to use and how to use them and potentially combine their values (e.g. allowing to compute vegetation index), and apply colormaps, etc. It occurred to me that part of this could also be used as part of a simple coverage request to define bands to return with the additional capabilities of very simply defining arithmetic to perform to compute the values, e.g. something like:

http://maps.ecere.com/ogcapi/coverage/s2?bands=evi(2.5*(B08/4000.0-B04/4000.0)/(1+B08/4000.0+6*B04/4000.0+-7.5*B02/4000.0))

or

http://maps.ecere.com/ogcapi/coverage/s2?bands=r(B04/4000),g(B03/4000),b(B02/4000)

Below is the syntax we are considering in CMSS (mostly intended for either client-side rendering, or server-side e.g. for Maps or Maps/Tiles API).

#Sentinel_2_L2A
{
   // For normal sentinel-2 L2A imagery (if no band named r, g, or b: single band (other than 'a') is an index; multi-band is assigned to r,g,b in order)
   bands =
   {
      a = (B02 != null | B03 != null | B04 != null) ? 1.0 : 0.0,
      r = B04 / 4000.0,
      g = B03 / 4000.0,
      b = B02 / 4000.0
   };

   // For EVI:
   /*
   bands =
   {
      a = (B02 != null | B03 != null | B04 != null) ? 1.0 : 0.0,
      evi = 2.5 * (B08 / 4000.0 - B04 / 4000.0) / (1 + B08 / 4000.0 + 6*B04 / 4000.0 + -7.5*B02 / 4000.0)
   };
   */

   // Generating a multi-band coverage (processing use case)
   /*
   bands =
   {
      b1 = B04 / 4000.0,
      b2 = B03 / 4000.0,
      b3 = B02 / 4000.0,
      evi = 2.5 * (B08 / 4000.0 - B04 / 4000.0) / (1 + B08 / 4000.0 + 6*B04 / 4000.0 + -7.5*B02 / 4000.0)
   };
   */

   // For a tint to apply to the monochrome index, or the default single band value:
   //color = lime;

   // For a color map applied to the index (e.g. EVI) instead of grayscale monochrome:
   /*
   colorMap = [
      { 0.0, 0x533300 },
      { 0.5, sienna },
      { 0.6, darkGoldenrod },
      { 0.7, oliveDrab },
      { 0.8, yellowGreen },
      { 0.9, greenYellow },
      { 1.0, lime }
   ];
   */
}

[jerstlouis]

CQL2 with extensions might also be considered for expressing this, and possibly some extension could allow to define aggregation capabilities.

Coverage access/processing capabilities:

• Downsampling resolution
• Subsetting (Trimming and (reducing) Slicing)
• Select only some values from the range (range subsetting)

Additional capabilities which could expressed e.g. with CQL:

• Band arithmetics (and defining new bands) -- this original issue
• Filtering (by range values, by geometry) -- i.e. filter
• Reduction (e.g. summation, average, minimum, maximum resulting in one less dimension)
• Aggregation ( group result ) downsampling to lower-resolution, e.g. daily averages

See also OpenEO description https://openeo.org/documentation/1.0/datacubes.html

[jerstlouis]

Most of these capabilities could actually be handled by query parameters as described in #164.