Stacking with size channel

[xoolive]

I am not sure whether this is a bug report or a feature request, but I'll show the logic here.
I wrote the code with Altair but will try to share the links to the vega-lite editor as well.

So I first generate a list of temporal events, and shared the resulting json on gist.

I am trying to get a stacked view of different types of events, first the more natural view with stacked bars, (link):

base = (
    alt.Chart(
        alt.Data(
            url="https://gist.githubusercontent.com/xoolive/7cbc548c90bf9eb998e35a20c1971a69/raw/0dde22efc14263bf7dc0662d2d4743e6fa583898/example.json"
        )
    )
    .transform_aggregate(total="count(category)", groupby=["hour", "category"])
    .encode(
        alt.X("utchours(hour):T", title="hour (UTC)"),
        alt.Color(
            "category:N",
            scale=alt.Scale(
                domain=["good", "bad", "very bad", "unknown"],
                range=["#4e79a7", "#f28e2b", "#e15759", "#bab0ac"],
            ),
        ),
    )
)

calendar = (
    base.encode(
        alt.Row("utcmonthdate(hour):T", title=""),
        alt.Y("total:Q"),
    )
    .mark_bar()
    .properties(height=100)
)
calendar

The output is correctly stacked:

Now since my list of days is much longer, I want to encode things a bit differently, with "bubbles" of different size. So the y channel would become the size channel (link):

calendar = (
    base.transform_filter("datum.category != 'unknown'")
    .encode(
        alt.Y("utcmonthdate(hour):O", title=None),
        alt.Size("total:Q"),
    )
    .mark_circle()
    .configure_legend(orient="bottom")
)
calendar

This could look correct, but actually, it appears that the sizes are not stacked and that some bubbles may come in front of others. I wrote the following workaround, generating stacks manually, playing with the order channel, and with a stack ordering consistent with my wishes (is it related to #1734 ?) but in the end I am not sure whether the process could be facilitate so as to get the following output ⬇️ (with (link)) for the previous code snippet ⬆️

cheating_sorts = pd.DataFrame(
    dict(category=["unknown", "good", "bad", "very bad"], value=[3, 2, 1, 0])
)
calendar = (
    base.transform_lookup(
        lookup="category",
        from_=alt.LookupData(data=cheating_sorts, key="category", fields=["value"]),
    )
    .transform_stack(
        stack="total",
        as_=["size", "size2"],
        groupby=["hour"],
        sort=[alt.SortField("value")],
    )
    .transform_filter("datum.category != 'unknown'")
    .encode(
        alt.Y("utcmonthdate(hour):O", title=None),
        alt.Size("size2:Q", title="total"),
        alt.Order("category:N"),
    )
    .mark_circle()
    .configure_legend(orient="bottom")
)
calendar

Thank you for the support!

[domoritz]

Great idea. I think we should apply stacking to sized circles as well.

Here is the simplest example I could come up with.

Open the Chart in the Vega Editor

Would you want to take a stab at a pull request?

[xoolive]

Thank you for the feedback! Glad to see it's welcome.
About the PR, my major weakness is that I need to learn Javascript first 😨 I'm usually ok at copy-pasting bits here and there, but for this one, I would need much more shepherding... 😅

[kanitw]

I talked with @domoritz more about this. I don't think we should support this as it was intentionally not supported.

Even if the circle's area are properly stacked as you suggested, people won't able to effectively compare the area between the inner circles and the outside stroked circles (for the stacked ones).

It'd be better to do a bar chart with less height, or consider using pies (which is basically stacking angles of arc marks).

[xoolive]

Thank you for spending time on this and I must say that the area comparison argument does make sense. I am fine with my workaround for my need, I should consider other options in the future.

Yet, I am not sure the status quo is a good idea either.
I mean, the Color channel does make sense, but its behaviour with nominal variables is not the one expected anywhere else. It returns something, which in the end is wrong.

I would have at least expected a warning somewhere, no?

[kanitw]

I could see an argument for a warning, but this should be rare enough so I don't plan to fix this.

If you strongly feel like a warning, feel free to submit a PR. :)