Categorical choropleths with legends

[nicolaskruchten]

Right now it doesn't seem like we can make a categorical choropleth by adding multiple traces with the same color and having legend items appear for them: https://codepen.io/nicolaskruchten/pen/MLwyOZ?editors=0010

Ideally I'd want to be able to:

1. set the color directly, like with marker.color, instead of doing a dance with z and colorscale
2. have legend entries appear

So that I could easily switch between choropleth and scattergeo like with this one: https://codepen.io/nicolaskruchten/pen/QYbNax?editors=0010

[etpinard]

That's correct. choropleth don't support legend items.

[etpinard]

You can shrink down the colorbars (one for each trace) to do something like:

from https://nbviewer.jupyter.org/github/etpinard/plotly-misc-nbs/blob/master/geo-maps/discrete-choropleths.ipynb#Suggestion-2:-split-data-into-several-choropleth-traces

[etpinard]

1. set the color directly, like with marker.color, instead of doing a dance with z and colorscale

So, you want z (that should have been called value, by the way) and marker.color to do the exact same thing? I can't say I'm a fan. It would be weird (to me) to have a "primary" data array (i.e. you need it to see stuff) stuck insider marker.

So that I could easily switch between choropleth and scattergeo like with this one:

By a similar argument, should we rename the pie data arrays x and y so that we can easily switch from bar <--> pie? I doubt it.

Now, I'm not saying we shouldn't try to make trace-to-trace correspondences easier. This has been discussed during previous work on relayout. The last item of #2025 is:

add a way to declare correspondence between attributes of different name across trace types (e.g. to generalize type edits involving pie traces, scattergeo lon/lat should correspond to x/y, ...)

Maybe we can find a way to declare those correspondence in the plot-schema. Thoughts?

[nicolaskruchten]

X and Y are terrible attribute names for pie, in just the same way as Z is a much worse attribute name than color for controlling the color of a choropleth marker, so no, obviously I would not favour those for pie!

However, since you bring it up, pie’s label/value would be a great fit for bar, since they would not require transposition to swap orientation, as x and y currently do.

Straw man aside: yes I would favour grandfathering in z as a legacy way of specifying marker.color if we added it to choropleth.

[nicolaskruchten]

The problem with playing discretization tricks with the colorbar is that it doesn’t have the same behaviour as the legend with respect to clicking to hide etc, so it’s inconsistent with the rest of the traces. This is a problem with parcats, parcoords etc as well.

[etpinard]

Maybe we can find a way to declare those correspondence in the plot-schema.

So this ⏫ isn't good enough?

[nicolaskruchten]

My main goal is to be able to specify the color of the country directly like we can specify the color of a marker in scatterX. Z doesn’t permit this atm, so no, declaring a correspondence doesn’t help :)

Conversely, allowing CSS color names in an array called Z seems awkward.

[etpinard]

We could make z accept color names (and omit colorscale).

[nicolaskruchten]

We could, yes. And we could allow traces to be added to the legend. That would indeed allow me to make the figures I want.

[etpinard]

Thinking about this again maybe marker.color for color names + legend items would be best.

That way, user that inputs z gets a colorscale and a colorbar, user that inputs marker.color gets a legend item. There wouldn't be any marker.colorscale and marker.color items couldn't be numeric (not a true "data" array, that makes me 😄 ). It will be arrayOk though.

[nicolaskruchten]

Heh ok that might work also. OTOH I could also see an argument that a true choropleth by definition expresses continuous values and that we should have a new trace type called indicatormap or something that accepts only categorical colors.

Also: choropleth has a “showlegend” attribute atm that doesn’t do anything, which initially led me down this path ;)

[etpinard]

Right, all traces have a showlegend attribute even though some (or most?) of them don't support legends

Related:

• Implement legend entries for surface (and others like heatmap, contour) traces #2642
• Prune unsupported global-level trace attributes #3058

[nicolaskruchten]

For reference, BTW, this is the kind of figure I'm aiming at:

[nicolaskruchten]

Just to drill in a bit on the z vs marker.color thing... @etpinard you said

It would be weird (to me) to have a "primary" data array (i.e. you need it to see stuff) stuck insider marker.

OK, but how is this different from something like scattergeo? If you omit marker.color then all the markers are the same default color. We could do the same thing for choropleth such that if you only pass in location then all the countries (or whatever) are the same color. That's not a useless thing: as an indicator map, it's like "here are all the places where X".

I think it would be quite weird to have choropleth be the one trace where marker.color accepts only colors and not continuous values.