Gregor Aisch

Digital mapmakers often have a hard time getting color scales right; it's common to just sort of wing it and end up with something that looks like crap and/or doesn't work well with the nature of the dataset. I'd recommend using one of the tried and tested scales from ColorBrewer (https://colorbrewer2.org). Great info there to help you decide. And when you do pick a scale, Chroma.js (https://www.vis4.net/chromajs) is a fantastic color library that has built-in support for ColorBrewer scales. Also http://turfjs.org has some great tools for manipulating GeoJSON.

I'm impressed by the other mentioned picker, for HCL this time http://tristen.ca/hcl-picker/ This tool is also useful https://vis4.net/palettes/#/9|s|00429d,96ffea,ffffe0|ffffe0,ff005e,930… I have to mention this fantastic presentation on colormaps https://www.youtube.com/watch?v=xAoljeRJ3lU (A Better Default Colormap for Matplotlib, SciPy 2015, Nathaniel Smith and Stéfan van der Walt). It is about perceptually uniform colormaps. https://bids.github.io/colormap/

Good library to begin with, but could do better on the perceived brightness. Since HSV is NOT perceived as evenly distributed to the human eye along the value(lightness) axis[1], would recommend employing chroma.js[2] which uses the HCL and CIE color spaces, which in general yield more pleasing results for use in color scales. [1] http://vis4.net/blog/posts/avoid-equidistant-hsv-colors/ [2] https://github.com/gka/chroma.js i want hue might be a bit of overkill though: http://tools.medialab.sciences-po.fr/iwanthue/index.php

Great points, but in the author's 2D histograms the use of 'color' to show point density is a little misleading. Color is not a scalar, it's a vector, and simply varying hue doesn't map out well to the human perception of lightness or intensity. It also doesn't allow for meaningful interpolation. If you take a look at http://vis4.net/blog/posts/avoid-equidistant-hsv-colors/ you can see a strategy for building perception-aware color palettes/gradients, which would be much more useful in this case. (actually it looks like this wasn't the author's decision, but something built into the graphing library)

While HSL is dramatically better than RGB, it still has the problem of not quite mapping intuitively to our perceptions. In particular, for a fixed lightness value, the perceived brightness still varies widely depending on the hue and saturation (100% light and saturated blue is much darker than 100% light and saturated yellow). For fiddling with colors, I recommend the HCL model (Hue/Chroma/Lightness), which is basically the same idea as HSL except your intuitions actually work: the perceived "grayness" (saturation) and the perceived brightness of colors can be adjusted independently (almost—I'll get to this) from each other and from the hue: http://vis4.net/blog/posts/avoid-equidistant-hsv-colors/ There are downsides, of course, which can all be traced back to one root problem with HCL: it's determined by biology, not physics. This means that any implementation is only going to be an approximation, which is the "almost" I mentioned above: when you muck around with chroma and hue, you'll still see small variations in brightness. This also means that the boundaries of this color space don't form a cube like RGB, nor a cylinder or double-cone like HSL and HSV. Those spaces form super nice shapes because you can physically choose 256 values for each of the 3 components of a pixel (the RGB cube), and the others are straightforward transformations of thereof. But they have no straightforward relationship to perceived brightness nor perceived "grayness". For the same reason,…

Thanks for the feedback everyone. Perhaps I should have included a bit more explanation. I was primarily interested in an algorithmic approach to generating color palettes. I am familiar with the various tools available (Adobe Kuler being my favorite) that use color theory as a basis of providing colors to go with one that you've selected (i.e. complimentary colors, analogous colors, triadic colors). One the palettes that my app provides uses this approach. Another approach I looked at was a trick that I've seen many designers use in which you "mix" a little of the color you want to use with another color. To play with this concept, I generate a random set of colors and blend it with the one that you've selected. Finally, I am a huge fan of Gregor Aisch's work [1] with colors in regard to statistics. My third palette borrows a method of his that I had not seen elsewhere. He essentially maps a particular color space into two dimensions and keeps the third constant. You can sample equidistant colors along a line in that space to derive a set of colors that look good together. In my case I used HSL, where I hold Lightness constant (I use the value of lightness of the color you selected). As he mentions in the post I've linked below, HSL is not necessarily the best color model to use this way. A more perceptually uniform color space like CIE LAB would be better. However, working with this space in this way is a little more complicated because, since this color space models…

It is possible, but not trivial: https://www.vis4.net/blog/posts/no-more-mercator-tiles/ (comments are also informative, particularly Tom MacWright's) https://mapzen.com/blog/escape-from-mercator/

It wasn't just London that voted remain [0]. I hope MP's will vote based on the indication that their constitutes voiced. [0] https://vis4.net/blog/wp-content/uploads/2016/06/brexit-map-1-1371x120…

So I just spent half an hour googling for libraries that could help with this. Chroma.js seems to be a pretty nice option for dealing with this issue in a web context: http://gka.github.io/chroma.js/ The person behind is has some nice blog posts on color generation too: https://vis4.net/color/ The only issue that I see is that the library is focused on translating data to colours. The problems with blurring and downscaling that you mentioned go the other way: the colours are the data.

The blog posts from Chroma.js https://vis4.net/blog/posts/avoid-equidistant-hsv-colors/ https://vis4.net/blog/posts/mastering-multi-hued-color-scales/ are really nice, and help you figure out how to use Chroma.js (and the LAB color scheme). Nice work!

And here's a blog post from a year ago on Chroma.js that goes into a bit of detail about why it matters and some demos: https://vis4.net/blog/posts/mastering-multi-hued-color-scales/

I believe the 'Spectral' colormap (with a capital S) in matplotlib does exactly that. Based on the names, it seems [1, 2] (along with all the other capitalized matplotlib colormaps) to be a ColorBrewer [3] colormap, which are all designed with these perceptual considerations in mind [4]. [1] https://github.com/gka/chroma.js/wiki/Predefined-Colors [2] http://matplotlib.sourceforge.net/examples/pylab_examples/show_colorma… [3] http://colorbrewer2.com/ [4] http://vis4.net/blog/posts/avoid-equidistant-hsv-colors/

All (?) upcoming alternatves to Disqus: (my own listed last) - Mozilla's Talk, https://github.com/coralproject/talk. Open source, install yourself. - Discourse, https://www.discourse.org/. One needs to navigate to a separate page, to post a comment. Not threaded. Min $20/month. Open source. Facebook and Gmail login. - Isso: https://posativ.org/isso/. Open source, install on your own server. - Commento, https://github.com/adtac/commento. Open source. Moderation, spam-protection and hosting is under development. - Schnack, https://www.vis4.net/blog/2017/10/hello-schnack/. Open source, install yourself. Has GitHub and Facebook login. - HostedComments, https://www.hostedcomments.com/. Proprietory. Min $10/month - Remarbox, https://www.remarkbox.com/. Proprietory. Min $4/month - Gitalk. https://github.com/gitalk/gitalk. Open source, install yourself. Comments stored as GitHub issues. - https://github.com/skx/e-comments. Open source, install yourself. - And my own: EffectiveDiscussions: https://www.effectivediscussions.org/blog-comments. Open source, or $2 per month. Has Facebook and Gmail login.