Make different colormaps available

[Jens-Uwe Grooß]

Currently CLaMS and CAMS parameters are displayed using the colormap "viridis" This colormap has the advantage of showing similar color contrast at all values. As there are many possible applications that may need higher color contrast, it would be desirable, if different choices of colormaps for the color contour plots will be offered in the UI, e.g. also the colormap gist_ncar_r

[Marc R.]

Many colorbars in the MSS should be eliminated anyway, in particular the perceptually non-linear rainbow maps. In Met.3D we're mainly working with HCL colormaps (see http://hclwizard.org/online-creator-eeecon/), the ColorBrewer maps (http://colorbrewer2.org/) may also be useful. I can provide more information.

[Jens-Uwe Grooß]

My point is, that for the CLAMS plots (and also the CAMS plots) only a single colormap is currently defined. A possible choice between 2 or 3 colormaps would be a major improvement as it increases the possibility to display different parameters with different contrasts.

If there is an option with many colorbars or colorbar generation, this would be even better.

[Joern Ungermann]

It is easy to define those as styles. However: the currently provided one for CLaMS plot (matplotlib viridis) is a perceptually correct, colour-blind friendly one. As such it is a better choice than what most people would use (i.e. jet or worse).

[Reimar Bauer]

check met ocean standard implementation http://external.opengeospatial.org/twiki_public/MetOceanDWG/WebHome

[Jens-Uwe Grooß]

When using the MSS tool with the current colormap setting, discussions have continued.

It would be desired to have the flexibility to define all the available plos (lin, log...colorscales) with different available colormaps. Furthermore one could gain flexibility if min and max of the displayed range could be given by the user. One could define this as additional style, however this would result in a high number of possible styles 5 (default, auto, autolog, nolinear, log) times the number of available colour scales. Better would be an "orthogonal" second style However, it seems not to be forseen in the OWS/WMS standard to exchange such "orthognal" styles

Can we somehow extend these definitions? Potentially such that if a server or client does not understand these extensions, it would return to the default colormap?

[Joern Ungermann]

Rereading the spec, I found something about "vendor-specific" extensions that one might tap into for those features.