Helper methods - Color categories

[makella]

For

• points
• lines
• polygons

[makella]

• All geometries
  • top 11 categories
  • using the bold CARTOColor scheme

note: width, strokeWidth, and strokeColor are the same as outlined in the basic style ticket and should get inherited from there for each geometry type. The only thing that varies here is color.

• Category ramps by geometry
  • points:
    'color': 'ramp(top($category, 11), bold)'
  • lines:
    'color': 'ramp(top($category, 11), bold)'
  • polygons:
    'color': 'opacity(ramp(top($category, 11), bold),0.9)'

cc @Jesus89 @VictorVelarde @rjimenezda

[makella]

category color ramps above for all geometries

[makella]

@Jesus89 as a first pass, let's call this helper color_category i'm still thinking through a pattern for all of the variations of color_, size_, etc. helper methods. for example color_continuous is long but not sure if color_cont makes sense. If we truncate, for color category we could do color_cats but then that sounds like coloring actual cats 😆 soooo just gonna think it through a little more but for now, color_category is ok.

thanks!

[VictorVelarde]

Hi @makella, @Jesus89, nice work with styles!

As we have discussed before, the 'helpers' would probably be even more useful at the Layer level. That way we could include at the same time what we want to add also for Legend or even Popup. for each one of them.

That means that this helper API could be built as something like:

  # 1. Minimum (just field is required)
  aLayer = mapping.colorCategoryLayer(source, { field: 'myCategoryField' });

  # or even...
  aLayer = mapping.colorCategoryLayer(source, 'myCategoryField');

The mapping name could change of course and we could also remove the 'Layer' suffix if you want (eg. layerFactory.colorCategory(source, 'myCategoryField'), but what's important here is to work at the Layer level.

This approach is of course compatible with setting custom parameters for that, as in:

  #2. Custom number of categories or palette (optional params)
  aLayer = mapping.colorCategoryLayer(source, {
      field: 'myCategoryField',
      top_categories: 10,
      palette: 'antique'
  });

[VictorVelarde]

Regarding to altering individual properties in those helpers (style 'overrides'), I think that, as @jorgesancha said, we should think before about finishing them all with good defaults.

After that, we can explore the Style __str__, so a user could see the autogenerated style 'code', and modify or reuse later on, without helpers

[Jesus89]

OK. Thanks for the clarification Victor!

My initial thoughts were about methods to include in the current API, but this is a new API over on top of the current API. So it would be nice to add each of these mini examples in all the tickets regarding helpers to have the definition before starting to implement the code. (Just updating the JS functions colorCategoryLayer by the Pythonic ones color_category_layer :P)

The good point is that the insights implemented for the geom type detection are compatible with this final API too so it won't be hard to implement them as soon as they are defined.

NOTE: IMO there pure style helper methods have intrinsic value "per se" so we could consider to revisit them in the future once we have completed the layer helper methods.

[VictorVelarde]

Let's shaare a PoC of that first one color_category_layer helper, so @andy-esch and @makella can give first an OK. Once we have this, we can easily define the rest of Layer-level helpers, in their corresponding tickets.

[Jesus89]

This is a PoC of the color_category_layer helper.

Do we want to include also default legend and popup?

[Jesus89]

I have added a default hover popup with the category:

[Jesus89]

I have integrated the legends branch and added a default legend in the helper:

OR

[andy-esch]

I love the from cartoframes.viz.helpers import color_category_layer and Map(color_category_layer(...) syntax!

I like the second legend (with large filled circles, the other confused me into thinking it was a classed numeric ramp).

On the others, could we get the name changed to just "Others"?

[Jesus89]

Great 😄

I like the second legend

Yes, I'm using that legend 'basic' instead of the first one

could we get the name changed to just "Others"?

Yes, but I think this should be done in Airship cc @rjimenezda

If we are happy with the approach we can define all the layer helpers using this pattern:

• Function in viz.helpers namespace
• Default style for each geometry (point, line, polygon)
• Default hover popup with the property
• Default legend (does it depend on the geometry? @makella)

[makella]

nice @Jesus89 regarding your legend question, yes, what we envision is assigning default legends that are appropriate for each helper + geometry type. So in the case above, the helper color_category_layer can be used for points, lines, or polygons but the legend that we provide by default in this case would be color category: points.

[Jesus89]

OK @makella

I think this is a feature we should add in the VL bridge, which has the information about the geom_type. cc @rjimenezda.

[makella]

yep! it will come from the bridge :)

[Jesus89]

Closed via #692