Document & unhide stack transform

[g3o2]

• improve diverging stack bar example

Recently, I wanted to reuse this example only to realize that its dataset appears to have undergone some preprocessing outside of vega-lite, thus rendering the example theoretical in a pure vega-lite context.

The fields in question are percentage_start and percentage_end. I can see how to calculate those two fields in vega using the stack transform.

But is it currently feasible at all to calculate the said fields using only vega-lite? Alternatively, would it be possible to showcase this example using vega-lite's layer and stack instead?

{
        "question": "Question 1",
        "type": "Strongly disagree",
        "value": 24,
        "percentage": 0.7,
        "percentage_start": -19.1,
        "percentage_end": -18.4
}

[kanitw]

is it currently feasible at all to calculate the said fields using only vega-lite?

Not yet but we're working on supporting window transform and offset so we can do it.

Alternatively, would it be possible to showcase this example using vega-lite's layer and stack instead?

I don't think layer would help as you still have to offset the position anyway.

[kanitw]

Actually, depending on how we implement scales for offset channels, it might lead to a problem with scale.

Adding an explicit stack transform and window is sufficient as we can just calculate the offset. (We don't really need offset for this example.)

[g3o2]

I've thought more about layering the way you would with an age pyramid. One column would have to be multiplied by -1. Hmm, I'll give it a try ...

[g3o2]

Just realized that I've already gone that road with #3047 ...

[kanitw]

I'm updating this issue to be "Add stack transform and update diverging stack bar example"

[kanitw]

• Actually besides diverging stack bar example, we could try to use stack transform to replicate stack labels as in https://vega.github.io/vega/examples/job-voyager/.

[kanitw]

@invokesus Another good example to add once we have a is a mosaic plot.

Basically, we can stack one direction first, and then stack by another direction within each group.
Then we can use rect mark for each plot.

Here is another similar example.

[kanitw]

We got some questions about motivation and other alternatives for this issue on Slack. Here are some more details.

For stack, it is the only transform in encoding that does not have an explicit version of the syntax available so it is inconsistent with the rest of the language. (I just found out that I noted about it in #3264, not here -- sorry!)

re: alternative approaches such as augmenting our existing stacking, etc.

I don't think augmenting existing stacking with offset is a good idea, as that will be complecting the design as stacking and offset are two distinct operations. (I know that stack has "center" offset, which is a nice shortcut for streamgraph. But offsetting by another field shouldn't be a part of stacking.)

Another good alternative is to offer offset as discussed in #3047 (Too bad we have duplicate issues, so some of you might not notice it).
Stack is actually better for diverging stack bar chart case. But adding offset doesn't solve the inconsistency problem anyway. It also doesn't allow multi-direction nested stack like in Mosaic plot.

While I don't think this issue (e.g., Mosaic plot) is critical, implementing it is a great exercise for @invokesus to understand how transform codebase works in VL as there is already a StackNode in the data component. With this knowledge, he can continue implement other more important data transform for his GSOC project like fold, flatten, density, sample, etc.

(Please comment what you think are worth implementing in #3264. -- We can also talk about in person once we resume our regular VL meetings.)

Given this rationale, what we have explored alternatives is the syntax for it. @invokesus actually has created a design document for the syntax. (Yeah, I forgot to tell him to add this link here.)

Stack bridges data/visual space, and so exposing it as a transform feels like we are overusing transforms as an escape hatch

This point is interesting. So today I think and read more about other “visual layout” transforms.

One important distinction between stack and visual layout transform is that stack only operates in the data domain. It does not takes width/height as input and does not output x/y pixel values.

In contrast, visual layout transforms (e.g., treemap, wordcloud, etc.) take width & height as input and output x/y pixel values. These output are then usually mapped directly to pixel values without x/y scales. (The transform acts as a multidimensional scale.)

Thus, while stack feels “visual”, I wouldn’t categorize it as a visual layout transform (or at least, it is not the same kind of transform as treemap/wordcloud).

That said, I agree that other layout transforms are probably not natural as transform in VL. (We can discuss more about that in #1872.)