Providing better default color maps

[wkearn]

@geo-luca's recent contributions have brought up the need for standardizing the color maps for plotting topography and other terrain attributes.

We currently have access to all of matplotlib's default color maps. The default color map for GridObject.plot is whatever the user has specified in their rcParams -- probably viridis if they haven't touched it. The default color map for GridObject.plot_hs is terrain, which we have coded in as the default cmap parameter.

matplotlib's built-in color maps with a topographic orientation namely terrain and gist_earth are not perceptually uniform. @geo-luca uses a few different ones in the updated tutorial notebooks, notably cubehelix, which is closer to perceptually uniform but has a slightly non-traditional look.

MATLAB TopoToolbox supplies several alternative color maps. The Scientific Colour Maps from Fabio Crameri are helpfully provided by a Python package. There is also a cmocean package.

We could easily depend on one or both of these packages and reexport their color maps, along with any additional custom color maps that we might include.

More important, I think, is to settle on some good defaults that we can share between MATLAB and Python (and R eventually). We can use these defaults in the documentation and set them as defaults in our various plotting functions.

[geo-luca]

Thank you for starting the discussion.

I will prepare an additional tutorial that explores why some colormaps are more advisable than others depending on the situation. It will be a good place to further discuss the respective advantages of different options. I fell back on cubehelix rather than terrain but while it fits the condition of perceptual unifomity, it is not particularly pleasant or intuitive to the eye. Amongst the default matplotlib ones, summer would often be better because it starts at 50% lightness, reducing the visual range to leave more space for other elements (I am using it for the Taiwan chi map). It also fills an intuitive expectation (bottom = green, top =white), but not as well as oleron or bukavu (from Crameri) or topo (from cmocean).

(I should revise the tutorial to use a unique colormap for all maps.)

Overall, for a topography that serves as a background to e.g., fluvial metrics, I would suggest to primarily rely on hillshade (from mid grey to white), this leaves a lot of "cognitive" space for the additional elements.

I did not know cmocean, this is a very nice set of colormaps that are strictly perceptual! Maybe not as esthetically interesting (a purely subjective statement) as the Crameri ones, but if we pick based on the objective condition of "perceptual uniformity" they would be favored.

[wschwanghart]

Hi @geo-luca and @wkearn
good and much-needed discussion! I think that TT should adopt best practices of color usage throughout, hence I am much in support on this. The only point that I like to emphasize is that none of the packages like Fabio's SCM or cmocean provide beautiful colormaps for showing elevations. cmocean's terra may be ok, but much to dark in lower elevations. Cartographers probably have worked for years to have nice color schemes, often specific for some countries. I am not sure whether these adhere to color scheme principles (perceptual uniformity, accessibility,...), though. Still, I have implemented them in the MATLAB function ttcmap. Here are a few examples.

DEM = GRIDobj('srtm_bigtujunga30m_utm11.tif');
imageschs(DEM,'colormap',ttcmap(DEM,'cmap','france'))

The colormap is defined for some specific color ranges (these are listed if you call ttcmap without arguments). france, for example is defined for elevations between 0 and ~4000 m, so that the taiwan dataset is depicted quite nicely.

DEM = readexample('taiwan');
imageschs(DEM,'colormap',ttcmap(DEM,'cmap','france'))

The colormaps in ttcmap also have bathymetric colorscales and by supplying the elevation range to the function, the colorschemes adapt to the elevation range.

Finally, I have added some options to imageschs and introduced a couple of functions such as ttclrr (lets you use color names as in R) or ttclr (returns colors of some frequently used elements in maps (glaciers, lakes)). For example, this example would interpret NoData pixels as water pixels and colorize them accordingly:

DEM = readexample('taiwan');
imageschs(DEM,'colormap',ttcmap(DEM,'cmap','france'),'nancolor',ttclr('lake'))

There's probably much to explore what is available in terms of terrain colors (e.g. here) and I am happy to join the discussion.

[geo-luca]

Hello @wschwanghart & @wkearn ,

We might want to separate use cases, 1) topography as a background to data and 2) topography as an illustration.

In the first case, I would think we want to stay as close as possible to visuals driven by objective representation of data. In most cases, the key information represented on a map will be something else than elevation: slope, aspect, water discharge, chi, ksn, etc. I would argue in this case that we rarely need to display the elevation of every single pixel of the map. And if we do so, a medium to light colormap is to be preferred (like summer or a truncated bone). Wolfgang, you highlighted the issue of topographicish colormaps that start in very dark hues (e.g. cmocean's topo ). Removing the darker half of a perceptually uniform gradient can solve the problem. Importantly, the topographic hue should not interfere with the hue of the data presented.

I would argue that a default hillshade is most often the safest choice to frame and contextualize the data you want to show. That data could be elevation as it could be slope, or chi profiles. What I would suggest is default ~40% opaque hillshade layer with the option of adding discrete elements on top (e.g., river attributes) and map attributes below (e.g., slope or elevation). Caveat: this solution is not as good for maps that cover on- and offshore domains, but this will be a rarer use case. It could be patched with two unique (pale) colors for submerged versus emerged domains of the hillshade.

In the second case, if a DEM should be displayed for illustration purposes, we get closer to a GIS software output and some users might want to have access to specific colormaps (and color options like the handy ttclr). In that situation, one could argue that the importance perceptually uniform colormaps is secondary to the subjective esthetic choice of the user. For example, the maps Wolfgang showed above do not use a perceptually uniform colormap (goes from dark to light to dark to light) and that is fine for illustration purpose where the user's esthetics is important. There is a subjective choice to make the elevation zone 500–1000 masl special with a lighter shade. But I think we want to handle that case separately.

Final point, having a built-in map that recognizes 0m elevation as a coastline and colors the elevations and below with two sequential maps like oleron or cmocean: topo would be useful.