Cartodb: Category legends should be dynamic again

[saleiva]

Context

This PR made the category legends to not update to only show the categories containning and made all categories to be shown no matter which categories are selected. As legends are designed now, they should only show data in the map. This new behaviour is not aligned with the general vision of our maps and makes this legends to work different to other data-driven legends on the product (numeric legends)

No matter which is the approach for the cartocss, we should make them dynamic again.

[xavijam]

We discussed that here -> https://github.com/CartoDB/cartodb/issues/10805. If we do that (again) take into account the behaviour with the selected categories will not match with the colors selected at the beginning.

[matallo]

jumping in as I'm taking the issue, I was briefed by @nobuti and @rochoa and I think I know the implications, let's discuss this tomorrow? it's a tricky one

[javisantana]

so the problem is: we are not letting turbocarto to choose category neither colors for category maps.

One of the premises to have dynamic legends was to lean on turbocartocss. When turbocartocss picks the categories (in the same way it chooses the choropleth partitions) we can't control how colors are chosen by turbocartocss.

So we have 2 options:

• Modify turbocartocss to allow to send color hints, like "please, use this color for this category when possible" so the BUILDER style generator is able to set those.

• Use information from a category data view (instead of the cartocss response) to show the legend so we know what categories are shown. this is a hack

I do prefer first option but I'd like to hear ideas here.

Anyway, I'm pretty sure there are more options

cc @rochoa

[javisantana]

Ok, looks like @rochoa found a solution, let me explain it with an example:

Imagine we have 5 categories (A, B, C, D, E) so we'd generate the following turbocartocss for the top 3 (we generate up to 10 in BUILDER but to simplify I use 3) (notice there are 2 color ramps)

marker-fill: ramp([cat], (C3, C4, C5), category(3), "=");
marker-fill: ramp([cat], (C0, C1, C2), ("A", "B", "C"), "=");

When some of the top categories are in the map they are going to take the original colors because of the second statement. Those colors will never be used for other non-top categories because of the color ramp used in the first marker-fill

So if there is some filter and you have A, D, E categories on the map, A is going to take C0 color no matter the order and D and E will take a the color from (C3, C4, C5) based on the order (not optimal because we could we showing D with C3, C or C4 depending on how many features with category D the maps is showing)

There are things to change on how the layer metadata from maps api is used to generate the legend. cartodb.js would need to merge metadata for both marker-fill properties.

The problem (@saleiva): there are 2 color ramps there so the UI is not designed for that (but we could just assign an automatic color ramp for "others")

[saleiva]

Sounds good to me @javisantana.

[nobuti]

Why blocked again?

[rochoa]

@nobuti This: https://github.com/CartoDB/turbo-carto/issues/64.

[saleiva]

De-prioritizing due until having more bandwith on engine.

[alrocar]

Stale issue. Closing 👋