Colorize-alpha property, for true heat maps

[peterqliu]

Prior art by @artemp in CartoCSS.

Blurring circles is an iffy approximation for heat maps: there's little control over which circles are on top, and alpha blending gives very limited control over brightness. To make something like @ericfischer 's tweet map (or any true heat map), we need a way to map alpha levels as input, to an rgba as output.

Cursory chats with @mourner and @lucaswoj involved adding a new heatmap layer type, but I think we can achieve the same result by extending the current circle (and perhaps line) types, and leaning on their blur properties.

Properties to introduce: circle-colorize-alpha and line-colorize-alpha
Syntax: {base:<number>, stops: [[<input alpha>, <output rgba>], [<input alpha>, <output rgba>], ...]}

How it would work (conceptually, from someone who hasn't written a shader):

1. Render all circles normally, with their colors, opacities, radii, and blurs.
2. Iterate over each pixel of the layer, get its alpha value (ignoring color), and convert it to the corresponding rgba according to the ramp provided.

Open questions

1. How to set opacity for the whole layer? should we support translucent heatmap overlays? We can take the existing circle-opacity property and apply it after colorization, but that means one fewer dial for users on the input side. Edit: this can be expressed more elegantly in the output rgba's alpha channel.

2. Data driven? I think not, because this colorization applies only after all the features are rendered and blended together. Per-feature coloring on features that are already aggregated together doesn't make sense in my brain yet.

3. Intermingling points and lines? no ideas here

[e-n-f]

This would be wonderful!

I think there is a data-driven case that I was never able to address with the mapnik colorize-alpha: you might want, say, some red dots and some blue dots, where the red ramps from transparent through saturated red to nearly-white red, and the blue ramps from transparent through saturated blue to nearly-white blue, like for a census map like this:

So please don't rule out data-driven if it's possible.

[lucaswoj]

2. Data driven? I think not, because this colorization applies only after all the features are rendered and blended together. Per-feature coloring on features that are already aggregated together doesn't make sense in my brain yet.

Data-driven is a vague term that refers to making the appearance of the map a function of its contents. This is feature provides new "data-driven" capabilities. This is a feature that will use GL function syntax.

[lucaswoj]

2. Iterate over each pixel of the layer, get its alpha value (ignoring color), and convert it to the corresponding rgba according to the ramp provided.

We will not be able to get acceptable performance by iterating over pixels on the CPU. This transformation must be done on the GPU within our shaders.

[mourner]

As far as I understand, this would require rendering circles in a temporary buffer, and only then rendering it while shifting colors in the fragment shader, right?

[kkaefer]

I think we should take a step back here and explore how rendering heatmaps can be done efficiently on the GPU. Rather than rendering individual features and blending them (as in CPU-based rendering in Mapnik), we could use a different approach on the GPU, e.g. using an approach like https://github.com/pyalot/webgl-heatmap.

[mourner]

@kkaefer what's the approach there? It's hard to judge looking at the code.

[mtirwin]

Improved heatmaps came up with @tmcw and, separately, with a major enterprise earlier this week.

+1 to a refactor here, which'll be super useful to our expanding conversations in the BI space.

cc/ @ryanbaumann @msirenko

[tmcw]

I've always been puzzled by the pyalot heatmap implementation tbh; there's an implementation in plotly.js which looks much more readable: https://github.com/plotly/plotly.js

[peterqliu]

this is now a real feature!