Improve map colourscales

[rod-glover]

This issue derives from a recent conversation with Trevor. Although he and I agree that we prefer a fixed-range (min and max value) colour scale across all regions and seasons for a given variable, users are understood to prefer a range that is more tuned to their particular area of interest, and so vary with region and season.

Trevor proposes the following ideal set of options, selectable by the user:

1. Colour scale dependent on region. Colourscale range is 90% of data range across all seasons.
2. Colour scale dependent on viewport (determined by zoom/pan). Colourscale range is 90% of data range across all seasons.
3. Colourscale range is 90% of data range within selected season.
4. A catch-all scale for the whole province.
5. All of the above but some other fraction (100%? - TBD) of range.
6. User-adjustable range.

Some of these are overlapping. Reduced it might look like the following options:

1. Spatial extent for determining data range: all BC | selected region | current viewport
2. Temporal extent for determining data range: all seasons | selected season
3. Fraction of data range covered by colour scale: 90% | 100% | user-selected (sliders)

At present we have implemented the option combination (all BC) + (selected season) + (100% range (approx.)).

Analysis:

1. Spatial extent for determining data range

   1. viewport: PCEX has an "autoscale" feature that scales to current viewport. Its implementation uses an ncWMS GetMetadata minmax request, which is parameterized with a bounding box derived from the map viewport. Since we use the same backend for P2A, this same request can be made.
   2. region: It's not clear that a GetMetadata minmax request can accept anything other than a bounding box. Therefore we likely cannot submit take a minmax over the region proper, but we can take it over its bounding box, which is likely to be an acceptable substitute.
   3. all BC: A trivial subset of region.

2. Temporal extent for determining data range

   1. all seasons: Can this be proxied by just the "annual" dataset? If not, then 4 GetMetadata minmax requests will be required.
   2. selected season: Straightforward.

3. Fraction of data range covered by colour scale

   1. 90% | 100% | (other fixed percentage): Trivial.
   2. user-selected (sliders): I have already implemented a test version of sliders for colourscale range. It comes with a possible risk: promiscuous sliding of the sliders can cause a lot of requests to the backend as the climate layer is remapped to the new range. We suspect this may have been responsible for a big spike in backend requests during the time I was experimenting with it. However, careful selection of the increments available on the sliders and/or throttling of the slider onChange events could reduce this to a manageable load.

All said this looks quite straightforward, with an existing example in PCEX to guide us.

The slider option should probably be left as a separate enhancement; it is independent of the other features here.

The only complexity that may arise is how to present these options to the user, but I suspect the three options (spatial range, temporal range, fraction), rendered as three selectors, will be clear and intuitive enough. Certainly they could be used for user evaluation.

[jameshiebert]

Additional comments from @faronium

... the precip colour scale is inverted to me relative to my intuition.
Low precip is depicted with cool/wet colours and the high precip range is
depicted with hot/dry colours. This confused me and almost had me thinking
that the summarized precip changes didn't match the maps. I think it's
essential that this is inverted.

... have the colours been tested with colour-blindness in mind?
Someone RG colour blind may see the mid and upper ranges as a confusing
mix of shades.

[rod-glover]

See also #74