adding function to enable custom color assignment algorithm

[abrin]

We have a non-standard color scale that doesn't really fit well within the chroma.js model mostly because the distribution of data across the scale doesn't follow a linear or logarithmic pattern. To this end, I'd like to propose the ability to apply a custom function in the pattern of "valueProperty" that when passed a numeric value will return the hex-code of the color. You can see an example of the color scale we're using in the world-map here (http://core.tdar.org/).

[timwis]

First of all, please accept my apology for the delayed reply and letting this get buried. Thanks so much for putting together this pull request. I'm eager to help resolve your use case in the best way.

The approach you outlined looks sound, though before merging, would you mind helping me understand the use case a little better? Based on my understanding, it sounds like what we need is a way to override chroma.limits(), no?

If you could post example usage that would be great. Ultimately we can add an example to the repo once the feature's implemented (and a test but I'm happy to help with that).

[abrin]

Hi tim,
No worries. If you want to see a working example of why we needed to make the mod, take a look at http://core.tdar.org and look at the choropleth there. The big challenge is that the spread of data is very uneven from 0 - 350,000. a histogram would put most of the data between 0 and 1000 with a few outliers. Thus, we need a way to override the color allocation logic to say, 0-2 (color 1) 3-10 (color 2); 11- 50 (color 3), 50-100 (color 4) …..

Does this make sense? I couldn’t see a way to achieve this without the addition of the new method.

thanks,

adam

On Jul 16, 2016, at 1:01 PM, Tim Wisniewski notifications@github.com wrote:

First of all, please accept my apology for the delayed reply and letting this get buried. Thanks so much for putting together this pull request. I'm eager to help resolve your use case in the best way.

The approach you outlined looks sound, though before merging, would you mind helping me understand the use case a little better? Based on my understanding, it sounds like what we need is a way to override chroma.limits(), no?

If you could post example usage that would be great. Ultimately we can add an example to the repo once the feature's implemented (and a test but I'm happy to help with that).

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[timwis]

Hi Adam, thanks for breaking it down for me - yes now I quite understand. Cool site by the way!

I assume you've already explored the 3 options that chroma.js provides: quantile, k-means, and equidistant. I would have thought that the use case you described is what quantile was for, but to be honest I always forget the differences.

If that's not the case, what do you think of the resolution being to allow overriding of limit calculation?

[abrin]

I'm still looking into this btw -- sorry for the delay.

On Sat, Jul 16, 2016, at 01:12 PM, Tim Wisniewski wrote:

Hi Adam, thanks for breaking it down for me - yes now I quite
understand. Cool site by the way!
I assume you've already explored the 3 options that chroma.js
provides[1]: quantile, k-means, and equidistant. I would have thought
that the use case you described is what quantile was for, but to be
honest I always forget the differences.
If that's not the case, what do you think of the resolution being to
allow overriding of limit calculation[2]?
— You are receiving this because you authored the thread. Reply to
this email directly, view it on GitHub[3], or mute the thread[4].

Links:

1. http://gka.github.io/chroma.js/#chroma-limits
2. https://github.com/timwis/leaflet-choropleth/blob/gh-pages/src/choropleth.js#L30
3. adding function to enable custom color assignment algorithm #9 (comment)
4. https://github.com/notifications/unsubscribe-auth/AALwrq1wuc0wBIC2_MTfbqxWLzU3gNeVks5qWTsngaJpZM4IaQQp

[abrin]

ok. So, I reverted my changes, and tried out the different models for chroma I'm attaching the results with the settings. I can provide more info if helpful. I'm not seeing something that's very useful in either case because of the jumps in the data. "Q" is the closest methodology, but even there 272 and 370,000 get put into one bucket, which makes little sense.

For reference, here's a sense of our data distribution:

chroma Limit "E" -- Equidistant

scale : ['#fff','#FED976', '#FEB24C', '#FD8D3C', '#FC4E2A', '#E31A1C', '#BD0026', '#800026'], mode : 'e', steps: 7,

chroma Limit "Q" -- Quantile

scale : ['#fff','#FED976', '#FEB24C', '#FD8D3C', '#FC4E2A', '#E31A1C', '#BD0026', '#800026'], mode : 'q', steps: 7,

chroma Limit "K" K-Means

scale : ['#fff','#FED976', '#FEB24C', '#FD8D3C', '#FC4E2A', '#E31A1C', '#BD0026', '#800026'], mode : 'k', steps: 7,

[abrin]

here's the source data in the simplest form too (TAB format)
chropleth-source.txt

[brandondadam]

I think what abrin wants is a way to specify the steps manually (and I would also benefit from a way of doing this). So instead doing, steps: 5, you could specify the 5 steps that you want the data to break at, like so, steps: "10", "20", "30", "50", "70". And then the data would be separated at those specific points, instead of whatever mode you select ("e", "q", or "k") decides automatically.

A use case for this is a project that I am working on. I had a data scientist figure out the specific breaks/steps that would look best for a map with my data, and I have the legends being created with those specific breaks/steps. But my choropleth does not reflect that legend because I can't specify the actually breaks/steps that I want. http://bdadam.xyz/eduviz-dev/