Opacity is multiplicative!

For the Draw Your Neighborhoods site I wanted to allow contributors and anyone else interested to access instant feedback. Given that it was an off time project, and designed as a learning experience for myself with certain tools (Leaflet, cartoDB, etc.), I did not want to spend a lot of time, or any time really, mucking with the data in the short term. But I did want anyone who contributed to be able to get an instant view of their contribution. So I had to come up with something that could be automated and would respect individual contributions.

So I decided that I would simply allow overlapping transparency to guide the user towards areas of agreement or disagreement. Above is an example. The Wallingford neighborhood in Seattle has 4 versions drawn by various contributors, with a relatively high level of agreement. Using what I’ll call an opacity stack, you can pretty well understand where agreement and disagreement exist.

The process turned out to be a little more complex than I originally expected. The problem is as follows, given N neighborhoods, what opacity should be used to reach a total opacity of 0.8 (my arbitrary choice). Originally I thought this would mean using opacity with an additive blend mode and simply dividing 0.8 by N. Well, CartoCSS does not provide additive blending of opacity(Or didn’t, maybe it does now, these things move fast).

Opacity is multiplicative. Imagine light passing through windows that are 50% opaque. Two windows would not block all of the light, the first would block half of the light, then the second would block half of the remaining light. This is illustrated (poorly) below.

So how would the site come up with the appropriate opacity for a specific highlighted neighborhood?

The answer (hey kids, you will use it when you grow up): Algebra.

Doing a #lazyweb search for the formula, I found a great post here. It contains the basic formula for combined transparency. Which is fairly intuitive once you consider the natural behavior of light as outlined above.

` opacity_new = 1 - (1 - opacity_a) * (1 - opacity_b)`

With this formula our problem becomes clear. We want opacity_new to always be 0.8. And we want that true for **N** elements. Which results in this formula:

`0.8 = 1 - (1-x)^N`

We want to solve for x where N is the number of instances of a selected neighborhood within the database. After refreshing my algebraic brain, with the help of my wife, Alicia Miao, the formula to solve for the oppacity(x) of N objects to add to an opacity of 0.8 is:

`x = 1 - Nth root(.2)`

The formula results in an interesting slope as N increases. The slope works well with what we are trying to show with the overlapping polygons. As more contributions are made it becomes harder to ‘move’ the neighborhood. Here is the opacity curve. And that background isn’t just some chart junk, it shows a gradient from opacity of 0 to 0.8.

This formula is plugged into the code that creates the CartoCSS that is used as the style for the tiles generated when you highlight a neighborhood. After getting the neighborhood name and the number of drawings that have been made of the specified neighborhood, the values are plugged into the formula, and CartoCSS is created.

var n = neighborhood.name;
var c = neighborhood.count;
var fillOpacity = **1-(Math.pow(.2,1/c))**;
style += "[name = '"+n+"']";
style += "{polygon-fill:"+userNeighborhoods[i].color+";polygon-opacity:"+fillOpacity+";}";

In the case of Wallingford in Seattle, **N** = 4. With an N of 4, the above formula finds that the opacity(x) should be 0.33126. Go ahead, plug it into the formulas above….

OK, now that we have that confirmed, we write it into CartoCSS, and ship that off to the CartoDB machine and some how get back pretty tiles. Just like that! This all happens when you click ‘View Maps’ and highlight a neighborhood.

Opacity stacks share some cartographic considerations with Value by Alpha mapping. Check it out here. While Value by Alpha represents well thought out cartographic exploration and experimentation, Opacity Stacks (oh, I capitalized it like it’s a thing!) represent a briefly considered, sloppily implemented, easy answer to real time visualization of overlapping polygons. What these techniques do share is the effective use of visual weight to represent some aspect of the data. In the neighborhood map, this is the number of contributions, and cumulatively, the agreement of contributions. Unfortunately, I just checked my copy of ‘Semiology’ and there was no mention of opacity or ‘weight’. I’ve gone down another cartographic cul-de-sac, and I’m just riding my Mongoose around the empty lot at the end of the block.

Personal flashbacks aside, I still recommend checking out the tools used for this project, including CartDB, CartoCSS, Leaflet. I hope to post some improvements to the site shortly, including availability of comments like the one here. “…But I don’t trust them”. I love it. And a link to download the data (From the public, to the public right?).

PROBLEMS

Lots, but here is one; Conflict creates conflict. The opacity stack formula is based on single neighborhoods, and gives a great view of agreement/disagreement for a single discreet neighborhood. It is carto crap when polygons of different neighborhoods overlap.

Each of the above Portland neighborhoods overlap, but have various drawing counts. ‘Kerns’ and ‘southeast’ are drawn once, while Laurelhurst has 2 versions. So their opacity is calculated only for their own internal N, and overlapping areas are muddy. This isn’t a big enough issue that I feel the need to fix it right away, but it could be really interesting to use some kind of comp-op in the new CartoDB 2.0 with expanded support for CartoCSS to create some blends when neighborhoods have conflict. And of course we could do some more sophisticated analysis of the data to create better maps, but I think the opacity stack works in a pinch.

Most of the maps are screen shots from Draw Your Neighborhood.

As always, your cartographic feedback is appreciated!