two layer or grouped axes label / ticks

[bpostlethwaite]

A request has come in for a feature that could replicate this multi-level axes ticks / labels.

The following image shows something like an x2 attr on bars.

Note that to support positioning axes labels between ticks perhaps this #1673 (comment) will be a requirement.

[nicolaskruchten]

I propose that we break this up into two batches:

1. second-level axis labels, no ticks
2. ticks that extend down from the matching ticks from More control over tick text alignment #1673

[Braintelligence]

Strongly in favor of this feature, especially because it would allow usage of two features that we require.

[chriddyp]

This was asked about in the dash community forum today here: https://community.plot.ly/t/boxplot-with-multiple-categories-in-dash/14652/2. interestingly we already have an R example that fakes it: https://plot.ly/r/axes/#subcategory-axes

[larissaleite]

having this would also be very helpful for me!

[etpinard]

This is what I'm thinking:

(x|y)axis.categorygroups: [{
  name: 'Group 1',
  values: ['a', 'b', 'c'],
  level: 1 || 2 // (to start, more level later),
  bgcolor: '',
  side: '',
  font: {},
  // more style/positioning things ...
}, {
  // ...
},
// ...
]

where categoryarray would not get coerced when categorygroups is set, the ...categorygroups.map(c => c.values) would be the category list.

[nicolaskruchten]

Hmmm to me this is more of a data level consideration than a layout.(x|y)axis one...

data = [{ 
x: ["q1", "q2", "q3", "q4","q1", "q2", "q3", "q4"], 
x2: ["2017","2017","2017","2017","2018","2018","2018","2018",] 
...}]

[alexcjohnson]

It probably has to be both - the data trace needs to have multiple x arrays, and the axis needs style, order, and optional values for each level.

The categories in an inner level need not be the same for each instance of an outer level. There could be missing values (q4 2018 hasn't happened yet, for example) and we should honor that, or the inner level values could be be totally different from one outer value to the next - eg https://peltiertech.com/chart-with-a-dual-category-axis/

An axis.categorygroups container array seems reasonable. Re ^^ seems like values (if not generated automatically from the data) would need to include duplicates, unless we make an attribute (outside categorygroups I guess) to explicitly require/create a cartesian product. So for the example plot up top, we'd have:

categorygroups: [{
  name: 'Year',
  values: [16, 17, 18, 16, 17, 18, 16, 17, 18, 16, 17, 18, 16, 17, 18, 16, 17, 18],
  order: 'category ascending'
}, {
  name: 'Rating',
  values: ['BB+', 'BB+', 'BB+', 'BB', 'BB', 'BB', 'BB-', 'BB-', 'BB-', 'B+', 'B+', 'B+', 'B', 'B', 'B', 'B-', 'B-', 'B-'],
  order: 'array'
}]

order (which would be most useful when taking values from the data) would then sort all these values arrays together, sorting first on the last array (and requiring matching values in the last array to be grouped together regardless of anything else) and working back up to the first array. (Or do we want to reverse the order here, put the outer category first, the inner last? That actually may make more sense...)

Is level necessary? Isn't it just the index in categorygroups?
What would side do per group? Isn't axis.side enough?
name I guess is for hover labels?
What's bgcolor for?
One set of things that will definitely go in there is tick & grid attributes - people will want to for example draw solid gridlines for the outer categories but dashed or no gridlines for inner categories.

[nicolaskruchten]

It probably has to be both - the data trace needs to have multiple x arrays, and the axis needs style, order, and optional values for each level.

Yes, but the base case is that it'll just be specified in data I would expect, certainly from the Editor POV. I would be fine with supporting just the data piece first and then layering on the customizability in layout in a second pass.

The categories in an inner level need not be the same for each instance of an outer level.

Yes, of course, there's no coupling there.

[alexcjohnson]

Yes, but the base case is that it'll just be specified in data I would expect

That might be sufficient... we just look for x2 (and eventually x<n>) in the data traces, and if that exists we "autotype" the axis to 2-level categorical?

[nicolaskruchten]

if that exists we "autotype" the axis to 2-level categorical?

That was what I was thinking yes. Any downside to this?

[nicolaskruchten]

Also, ideally the order would default to the data order such that in cases like {x: [1,2,3], x2: [4,5,4]} the result would be that x would end up in [1,3,2] order so as not to break up the 4 in x2... that makes sense right?

[nicolaskruchten]

It occurs to me that from an RCE perspective at least, treating x as a 2-d array (like z in heatmap) is muuuch easier than having x, x2, x3 etc... Thoughts?

Also: I could easily see this feature being scoped tightly to bar and heatmap-like traces only, if that makes implementation easier.

[etpinard]

In @nicolaskruchten 's

data = [{ 
x: ["q1", "q2", "q3", "q4","q1", "q2", "q3", "q4"], 
x2: ["2017","2017","2017","2017","2018","2018","2018","2018",] 
...}]

the x categories here will have to behave differently than for "traditional" type: 'category' axes. The "effective" categories are x[i] + y[i] - which we'll map 1-to-1 to integers >=0. So maybe adding axis.type: 'category2' or groupedcategory or categorygroup would make sense.

By the way, I'm not a big fan of x2 - it sounds potentially confusing with trace attributes xaxis: 'x2'. Maybe xgroup would be best.

---

Let me try to make my first categorygroups specs attempt clearer. To describe the graph in the PR description, we'd get:

xaxis.categorygroups: [{
  name: 'BB+',
  values: ['16', '17', '18']
}, {
  name: 'BB',
  values: ['16', '17', '18']
}
// ...
]

and with level we could add an additional label level (to be drawn below the BB-, BB, ...) e.g.

xaxis.categories: [
// ...
{
  name: 'Double letters',
  values: ['BB', 'BB-', 'BB+'],
  level: 2
}, {
  name: 'Single letters',
  values: ['B', 'B-', 'B+'],
  level: 2
}]

.... but maybe keeping things "flat" would be better 🤔

---

What would side do per group? Isn't axis.side enough?
What's bgcolor for?

To replicate things like:

[nicolaskruchten]

This categorygroups object seems very hard to map into RCE widgets...

…

On Wed, Nov 7, 2018 at 18:17 Étienne Tétreault-Pinard < ***@***.***> wrote: In @nicolaskruchten <https://github.com/nicolaskruchten> 's data = [{ x: ["q1", "q2", "q3", "q4","q1", "q2", "q3", "q4"], x2: ["2017","2017","2017","2017","2018","2018","2018","2018",] ...}] the x categories here will have to behave differently than for "traditional" type: 'category' axes. The "effective" categories are x[i] + y[i] - which we'll map 1-to-1 to integers >=0. So maybe adding type: 'category2' or groupedcategory or categorygroup would make sense. By the way, I'm not a big fan of x2 - it sounds potentially confusing with trace attributes xaxis: 'x2'. Maybe xgroup would be best. ------------------------------ Let me try to make my first categorygroups specs attempt clearer. To describe the graph in the PR description, we'd get: xaxis.categorygroups: [{ name: 'BB+', values: ['16', '17', '18'] }, { name: 'BB', values: ['16', '17', '18'] }// ... ] and with level we could add an additional label level (to be drawn below the BB-, BB, ...) e.g. xaxis.categories: [// ... { name: 'Double letters', values: ['BB', 'BB-', 'BB+'], level: 2 }, { name: 'Single letters', values: ['B', 'B-', 'B+'], level: 2 }] .... but maybe keeping things "flat" would be better 🤔 ------------------------------ What would side do per group? Isn't axis.side enough? What's bgcolor for? To replicate things like: [image: image] <https://stackoverflow.com/questions/36099799/displaying-separate-means-within-fill-groups-in-ggplot-boxplot> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2799 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMbAxplNLVsmA-bSW6xr6c1c5xJiLDYks5us2n-gaJpZM4VJe-Z> .