Vega-lite: Layering with row/column shorthand

[sampsyo]

Here's the output from the trellis_anscombe example:

If I take the mark and encoding keys from that example and wrap them in a single-element layers list:

{
  "$schema": "https://vega.github.io/schema/vega-lite/v2.json",
  "description": "Anscombe's Quartet",
  "data": {"url": "data/anscombe.json"},
  "layer": [{
    "mark": "circle",
    "encoding": {
        "column": {"field": "Series", "type": "nominal"},
        "x": {
        "field": "X",
        "type": "quantitative",
        "scale": {"zero": false}
        },
        "y": {
        "field": "Y",
        "type": "quantitative",
        "scale": {"zero": false}
        },
        "opacity": {"value": 1}
    }
  }]
}

Perhaps naively, I would expect to get the same chart out. There's just one layer, and it contains the same instructions. However, the output overlaps all the trellises onto one set of axes:

I could of course just be misunderstanding the concept here! But with my current mental model, I thought it would be case that wrapping a mark specification in a single-element layers list would be a "no-op."

[kanitw]

@sampsyo Your expectation is right. However, as noted here, we currently do not allow layer of facets. The reason is that will allow cases where users specify one layer with row/column and another without it and that will produce an invalid spec.

To do facet of layer, you can combine the facet operator, which is the full form of the row / column channel.

Here is one example: https://github.com/vega/vega-lite/blob/master/examples/specs/facet_independent_scale_layer.vl.json.

@domoritz Perhaps, we should add docs about to a few more places.

• [ ] Documentation for row / column
• [ ] Add example of facet of layer to facet.html
• [ ] For now, we should make sure there is at least a warning to explain this limitation.

• [ ] We may consider re-writing the normalize method to be smarter about extracting row and column from the inner layers as well as that may be more intuitive for users. (We can only throw warning/error when the spec has one layer with row/column and another without it.)
  That said, this can be a bit tricky for a hierarchical tree structure and maybe not be the most important to do now.

[sampsyo]

Awesome; thank you for the extra background! That really helps.

[domoritz]

Yes, layer of facet makes sense in the algebra but we haven't implemented it. having said that, a layer of facets is equivalent to using detail for simple cases.

[kanitw]

having said that, a layer of facets is equivalent to using detail for simple cases.

I think you're confused by the term. Layering two faceted plots is not.
Facet _by_ layer (which we haven't and won't implement) is equivalent to using detail in _all_ cases.

[g3o2]

In your video, you have used a tree to show an example of how composition operators can be combined. It would be highly useful to add such trees to the documentation to show which combinations of composition operators are common (with an example for each) and which combinations are currently not supported (with workaround suggestions if available).

[domoritz]

@g3o2 That's a fantastic idea. We could add it to https://vega.github.io/vega-lite/docs/composition.html. Do you want to take a stab at it?

[kanitw]

Yeah, I think it's nice to add some tree to demonstrate that these composition can be hierarchical.
The most common ones are probably tree with 1-2 level like facet of layer or concatenating two layered views. The example in the video is a bit more extreme for demonstrating its potential power, but, of course, it will be less common.

Feel free to submit a PR for showing more examples. :)

[g3o2]

I'd love to contribute but unfortunately I stand without laptop atm. However, I can contribute with this example composition tree written in mermaid.js. It is the composition of the dot-dash plot community example.

graph TD
hconcat --> unit_dash_y
hconcat --> vconcat
vconcat --> unit_dot_x_y
vconcat --> unit_dash_x

More ambitiously, one could write a function which would derive the above composition tree from any vega-lite spec, given that vega-lite is by design a description of a visualisation and that the specs already have a tree-like shape in case of view composition.

Maybe one should open another issue for this?