Fix gemini axes, labels and other component issues

[giorgi-ghviniashvili]

Even with gemini recommendations it has some errors and does not correctly draws axes, labels, etc. We need to fix this by learning structure of gemini animation specs and building ourselves.

[giorgi-ghviniashvili]

@jhofman ^

[giorgi-ghviniashvili]

Ah I found out that when you want to animate from A to B, we must draw A before animating, I was not doing that and there was an error because of that.

[giorgi-ghviniashvili]

https://user-images.githubusercontent.com/6615532/116115443-749dc280-a6cb-11eb-84f6-2badf56399ed.mov

[giorgi-ghviniashvili]

So recommendations only works for any two specs: A and B, but if you have a set of specs, then it is messed up. We need to write a logic to take into consideration full set of specs, not only two of them.

[jhofman]

Glad you found the source of the issue, the animation looks quite good now!

Curious to chat more about how this logic for considering the set has to be modified. We can discuss at our next call.

Will this solve the issue for the work-degree datamation losing its x and y axes as well?

[giorgi-ghviniashvili]

Will this solve the issue for the work-degree datamation losing its x and y axes as well?

About the work-degree animation, we have two issues there:

• Gemini issues with drawing axis (fixed by drawing source frame before animation)
• We will end up having two x axes on last two frames, because one of them will be for facet view (but in reality it is just x-axis) and the other will be real x-axis. With gemini we can only handle one axis. This constraint requires to develop a way to use annotations instead of real axis for fake facet view.

Will try to find alternate way of labelling faceted view.

[giorgi-ghviniashvili]

Other than that, I still don't like how gemini handles animations for axis, for example in the view, you see the jumping axis labels, which is because that gemini does not correctly render tickPadding, and jumping happens because the target frame (which is source for next frame, is drawn without animation).

[jhofman]

Logging my understanding of this.

Say we have three frames. The proper sequences is to call gemini.recommend(A,B), get B_rendered from this, then call gemini.recommend(B_rendered, C), and so on. (Can't call gemini.recommend(B,C) on the original B.)

[jhofman]

We decided to file an issue w/ the Gemini folks on the padding issue using a small reproducible example.

[jhofman]

We also decided to try to label facets using annotations insteadd of axes, so that we can get taxes in future frames.

[giorgi-ghviniashvili]

We also decided to try to label facets using annotations insteadd of axes, so that we can get taxes in future frames.

Unfortunately labels and annotations are done through layer property which is already multi-view plot and not supported by Gemini. SAD

[giorgi-ghviniashvili]

We decided to file an issue w/ the Gemini folks on the padding issue using a small reproducible example.

https://github.com/uwdata/gemini/issues/5

[sharlagelfand]

We talked today about fine tuning with the facets and how the plots should look. Here is how a faceted plot with jittered points looks in ggplot2:

Note the row facet labels are on the right, and the y-axis on the left contains the name of the variable being shown as well as its range. The x-axis contains sex but I think we're good to continue leaving that blank, since the legend shows it. The way the points are jittered, they don't overlap between sexes.

And similar for the plot that just shows the mean, except I've updated it so that the y-axis is labelled with mean_bill_length_mm, but for our work I could just pass the actual summary function somewhere in the specs (e.g. mean(bill_length_mm)

cc @jhofman @giorgi-ghviniashvili

[jhofman]

@sharlagelfand @giorgi-ghviniashvili: noticed that in some of the datamations (e.g., penguins with sex on the x axis), we have the variable showing up as an integer instead of a label (e.g., "1" instead of "undefined", "2" instead of "male", 3 instead of "female").

can we change this?

[jhofman]

from yesterday's call, we agreed that we'd like to keep x axis position for categorical variables consistent between real and faked vegalite specs (e.g., if sex is on the x axis, then the position of male/female/undefined is always consistently encoded as, say 1, 2, and 3, and the x axis is centered on these values, running from 0.5 to 3.5 in this case).

also, we'd like to have the actual labels (male, female, undefined) on the x-axis instead of the numerical equivalents (1, 2, and 3).

@giorgi-ghviniashvili can you have a hack at these changes?

[sharlagelfand]

Just to confirm @jhofman you're talking something like this?

(the underlying values are 1, 2, 3 but labelled as female/male/NA)

I spent some time yesterday getting these consistent (and also consistently just recoding literal NA to "NA" and ensuring it appears "last" in both the axes and the legend)

[jhofman]

Yep, that's the idea!

[giorgi-ghviniashvili]

@jhofman is this already resolved by @sharlagelfand , or do you need my help here?

[jhofman]

@giorgi-ghviniashvili to answer your question, i'm not sure! :)

is it simply a matter of dropping in the vega spec mockup that @sharlagelfand made, with the new (discrete) x axes labels (female, male, NA)? or does something else need to be done to make things work okay with gemini?

[giorgi-ghviniashvili]

@jhofman I think it is resolved by @sharlagelfand already. We also found an issue with vega that axis.values does not work with floating point values. She will use integers and labelExpr to achieve this.