Added separate color_key for datashader shade to use color cycle by default

[jbednar]

PR #1697 changed the default cmap for datashader's shade() operation to "fire". @philippjfr wanted this replace datashader's default blue cmap, but it also replaced datashader's default color_key of Sets1to3, causing all categorical datashded output to be mapped to the first few colors of the fire colormap, which all look nearly identical (as reported in #1834).

The original behavior for categories can be restored by explicitly passing Sets1to3 to shade.cmap whenever a category is used, but that's awkward and mysterious; the defaults should not be covering up categories.

This PR adds a separate color_key parameter, defaulting to None (and thus falling through to Sets1to3), leaving cmap at the default fire value for now.

Personally, I think cmap should not be defaulting to fire either, because fire is intended only for black backgrounds, and the Bokeh defaults consistently use white backgrounds. So I wonder whether we should remove the "fire" default? E.g. if we set shade.cmap="#30a2da", we get behavior that is similar to the non-datashaded colors used by hv/bokeh:

It's not very pretty, but seems better than fire:

[philippjfr]

This looks fine and I suppose the Working with Large Data user guide will now work correctly. I have no strong opinions about fire apart from agreeing that it can be problematic. I'm not sure I like just "#30a2da" either though, as it doesn't really have much dynamic range.

[jbednar]

Well, what's a good colormap for white backgrounds? I don't really have a strong preference in that case, like I do for black backgrounds.

[jbednar]

I'll go ahead and merge this to get the example working, but I still think "fire" is not a good default for datashaded results.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.