There are a few straightforward ways to go about assigning categorical colors for the purpose of distinguishing different data series, assuming you have 10 well tested, distinguishable colors (which is what OUI gives us):
Use the palette once: for each series assign one of the palette colors until you use them up - after that don’t distinguish by color (usually some grayscale value for all other series)
Recycle the palette colors: for the 11th data series, simply use the 1st color. While 1, 11, and 21 are all the same color, they’re still easily distinguishable from all other nine colors
Expand the palette to be as large as necessary: from the original 10 colors, programmatically generate other colors, shades or tints. As the number of series increases, it becomes increasingly difficult to distinguish between series that are technically different colors.
For most visualizations, the choice doesn’t matter a lot, because by the time you have 10 series represented in a single visualization, you likely already have legibility issues, and most sensible tools will guide you to other alternatives. However, OpenSearch Dashboards currently makes this problem much more common and important:
Some visualization tools (VisLib, VisBuilder, and TSVB), rely on a color mapping, which attempts to apply strategy 3 to all legend items on all visualizations in a session. For each series label (such as “average bytes”, a unique color is assigned from the palette, and that color is no longer available for any other legend label to use
The “advantage” of this approach is that if you have the same metric (with the same legend label) in multiple visualizations on the same dashboard, the color used for both will be consistent (all visualizations with an “average bytes” series will use the same color).
Disadvantage 1: The color mapping changes/resets on page refresh, and colors aren’t assigned consistently. So while all the matching series are the same color, that actual color assignment changes on every page refresh or session start, which means dashboards seem to have arbitrary vis colors (sample dashboards generally have manually specified colors to avoid showcasing this behavior).
Disadvantage 2: When creating visualizations, the “best” colors from the palette may be made unavailable without actually being used. If you create a pie chart that splits on airline destination city, then change your mind and split by arrival city, the destination colors are still saved in the mapping, so won’t be reused. However, when saving and loading, or when refreshing the visualization, the mapping is reset, and then the chart will again use the first colors from the palette, which is confusing
Disadvantage 3: Requiring a larger palette always comes at the expense of color quality and distinguishability. While it’s relatively uncommon to have a visualization with. more than 10 series, it’s almost impossible to have a dashboard with less than 10 series across all visualizations.
Additional notes
The color mapping is (unfortunately, in my opinion) made available as a user-facing advanced setting. That means that users can try to specify a big map common series labels like {"Average bytes": "#33dd33"}. The color mapper will use any matching color overrides specified in this setting first. This is not ergonomic for users, and highly brittle (string labels must match exactly).
Other visualization tools, like Timeline and Vega use strategy 1 by default, with the ability for users to directly specify series colors in their grammars
VisLib visualization colors can be manually specified via the legend, and these choices are saved in multiple places - as part of the dashboard saved object if saved on a dashboard edit page, or as part of the visualization if saved on the visualization page. If colors are specified in multiple places dashboard panel legend color > visualization panel legend color > advanced settings matching color map > default color palette
There are a few straightforward ways to go about assigning categorical colors for the purpose of distinguishing different data series, assuming you have 10 well tested, distinguishable colors (which is what OUI gives us):
For most visualizations, the choice doesn’t matter a lot, because by the time you have 10 series represented in a single visualization, you likely already have legibility issues, and most sensible tools will guide you to other alternatives. However, OpenSearch Dashboards currently makes this problem much more common and important:
Additional notes
{"Average bytes": "#33dd33"}
. The color mapper will use any matching color overrides specified in this setting first. This is not ergonomic for users, and highly brittle (string labels must match exactly).