support for other color schemes?

[makella]

@dv343

In the CARTOColor library, we have several Colorbrewer schemes that can be accessed (https://github.com/CartoDB/CartoColor/blob/master/cartocolor.js#L1836-L1849).

In Builder, you would do something like,
polygon-fill: ramp([attribute],colorbrewer(Blues),quantiles);

Can we make these available in the renderer also?

[davidmanzanares]

Yes, of course, is it ok if we just "export" all the names, eg:
color: ramp($price, blues)
Or do we need some kind of namespace?

Another question, the colorbrewer schemes are similar to cartocolors in that each palette has multiple sub-palettes for different numbers of buckets?

[makella]

good question regarding the namespace... given that we do that now in Builder, do you think we should follow the same pattern? Thinking also in the future if we want to add other color schemes that are open, we'd probably help ourselves and confuse less people if we have a namespace. Could it be something as simple as cb.blues vs colorbrewer(blues)?

Yes! Colorbrewer actually goes to 9 colors for sequential and diverging schemes.

Another issue that we need to address is that people don't know the names of the cartocolor schemes because they have never seen them, CartoDB/cartodb#9528. I have a wiki page going and hopefully we can get some better documentation about the names!

[davidmanzanares]

Yep, cb.blues, or colorbrewer.blues are easy to implement, and I prefer those instead of a function: colorbrewer(blues).

I guess is fine if we leave the cartocolor ones in the global namespace: ramp($price, burg), right?

Yes! Colorbrewer actually goes to 9 colors for sequential and diverging schemes.

Easy to implement then! 😄

Around the naming issue... Yes, that's clearly needed, I'm exposing the internal names right now, but we'll need to document them giving them a name.

[makella]

I guess is fine if we leave the cartocolor ones in the global namespace: ramp($price, burg), right?

yep! that seems ok... like default space

[davidmanzanares]

Seems like colorbrewer has always been there, exported prefixed by cb_, see https://cartodb.github.io/renderer-prototype/example/mapbox.html#eyJhIjoibW5tYXBwbHV0byIsImIiOiIiLCJjIjoiZG1hbnphbmFyZXMiLCJkIjoiaHR0cHM6Ly97dXNlcn0uY2FydG8uY29tIiwiZSI6ImNvbG9yOiByYW1wKGxpbmVhcihsb2coJG51bWZsb29ycyksIDEsIDQpLCAoY2JfUHVycGxlcykpXG4iLCJmIjp7ImxuZyI6LTczLjkwNDM5MDkwNTU1NTQzLCJsYXQiOjQwLjc0OTExODc3NjQyMTR9LCJnIjoxMS43NDgzMTYzMjg5MTA2MjJ9

That comes from the cartocolor repo, so, to change current behavior, a change in that repo is what we should do, but that would be a breaking change for other packages 🙁

cc: @rochoa

[rochoa]

I'm moving this into future developments. Let's decide later if we want to enable colorbrewer in the cb namespace as an alternative to the ones already present in cartocolor.

[makella]

Actually, we support ColorBrewer... I didn't realize until I was reading through David's guide.

For example, this is the syntax (MAP):
color: ramp($dn,cb_blues)

What I need to check is if we are reading them in from CARTOColors and since we don't include all of the CB schemes in there, I may need to add more.

For example, I tried a qualitative scheme from CB and it doesn't seem to be working:
color: ramp($dn, cb_dark2)

[makella]

@VictorVelarde @rochoa ok, I looked in more detail, and yes, the CB schemes that VL supports are the ones that we have defined in cartocolor.js https://github.com/CartoDB/CartoColor/blob/master/cartocolor.js#L1836-L1849.

As discussed earlier, we made the decision to add these ones for Builder to compliment the schemes we had in CARTOColors and also chose ones that worked well on our basemaps.

I think it would be good to add in the additional ones for use with VL (but not necessarily for Builder). I'm not sure what you guys think the best way to do that will be... but I think it will be important for VL especially since you can use CB color schemes by name (vs. Builder where we generated hex values).

[VictorVelarde]

A simple option could be just to add those schemes to a new CartoColors version (v5?) and freeze the version currently used in Builder

[makella]

@VictorVelarde ok that sounds good. there are also other things that we wanted to look into for VL and CARTOColor schemes. Particularly, since we do color interpolation in CIELab, the mixing of some of the category schemes when there isn't a one-to-one match, can get pretty muddy. We had some ideas for rearranging some of the category schemes to avoid this problem. Maybe this is something we can look into if we decide that we can use a different version of CC for VL!

more info here: #129

let me know what you think!

[rochoa]

We can do what Victor proposes. Decide on what changes we want in CC, incorporate them, and add all CB palettes. We could use that new version to fix this.

OTOH, I would love to know how we plan to avoid name collisions because changing the name of a colour palette in CC is just a workaround. I was wondering if being able to use the namespace in the String API could be an option.

color: namedcolor.teal

What do you think?

[VictorVelarde]

Right now, there is just one level, where all the palettes are included, with no namespace, and CartoColors are included as they are here

carto-vl/src/renderer/viz/expressions/color/palettes.js

Line 8 in 63f4b91

palettes[`${name.toUpperCase()}`] = new Palette(name, cartocolor[name]);

We can explore that idea of namespaces if you think it is interesting. What different namespaces, apart from colorbrewer, should we end with?

[makella]

so we could include more color schemes that are out there.. for example, CARTOColors are available in both Python via palletable and R via rcartocolor.

There are a variety of other color scheme projects that we could think about including similar to how others have included ours.

[makella]

cc @andy-esch