Improve data presentation. Intersection between OGC API maps and coverages.

[joanma747]

I have been playing with the properties= syntax to create band indices and diffs between two times etc. I need to present the result to myself to be sure what I'm doing in each iteration, so I use a f=jpeg.

This is one of my last results:
http://localhost/cgi-bin/mmdc.py/collections/TerrestrialConnectivityIndex/coverage?subset=E(260000:528000),N(4488000:4748000),time(%222017-01-01%22)&subset-crs=[EPSG:32631]&crs=[EPSG:32631]&properties=Forest-Slice(Forest,[%22time%22],[%222012-01-01%22])&scale-factor=0.5&f=jpeg

Fine but...

OGC API maps does not support "playing" with bands or doing diff etc.
(synergize implementation supports that in WMS with a costum parameter EVALSCRIPT: https://docs.sentinel-hub.com/api/latest/api/ogc/additional-request-parameters/), so I use OGC API coverages for visualization; sorry.

But, immediately, I run into common issues that I remember discussing with Jon Blower many, many years ago. See the ncWMS implementation for reference.
https://reading-escience-centre.gitbooks.io/ncwms-user-guide/content/04-usage.html#getmap

I cannot control the color of the nodata value (no bgcolor=). I cannot change the color pallete to see positive values one color and negative values the oposite. I cannot control how colors are streaked.

Now that OGC API maps and coverages are so similar, does it make sense to use bgcolor= in coverages? or parameters= in maps?. Can we think about having a very simple way to select a color palette?.

(Yes, I'm not saying this are new questions but for some reason, they were never addressed and that is why people keep invent costum parameters)

[jerstlouis]

Hi @joanma747,

I also ran into these issues. There are some things that can already be done:

• Note that there is no JPEG requirement class defined in Coverages, because JPEG only supports 8-bit channel, so it's really not great for raw data values.
• The PNG requirement class defines the values-scale and values-offset query parameters, so that can help to better distinguish things
• For the NODATA, in our implementation we always use a value of 0 when returning a single (16-bit) PNG.
• The PNG (or better yet, GeoTIFF) output can be loaded into QGIS and there you can easily apply any style you want
• The same CQL2-Text expression used for properties= can be used in CartoSym-CSS style set up on the server, together with a color map, then you can access /styles/{styleId}/map to get a server-side rendered result.
• With Processes-Part 3 Collection output, the client can invoke a PassThrough process with a "collection": input where the "properties:" is specified, and then the client can request from the resulting virtual collection either a /map (and specify bgcolor) and the server can use some default color map style, or /coverage to get the raw data (with the properties expression applied)
• With Processes-Part 3 Collection output, the client can invoke a RenderMap process with a "collection": input where the "properties:" is specified, and a style can be specified that separately applies just the color map. Then from that resulting virtual collection, you can request /map

[chris-little]

@joanma747 This issue is also one for CoverageJSON. Initially, it seems rather silly to specify a colour for data. Surely it should be a function of the client software, not the API.