Layouts - (e.g., Treemap, Force-directed)

[amitkaps]

Is it possible to add a couple of layout options other than cartesian.

The first is geographic, something a simple mercator projection that we can use latitude and longitude as x and y encoding and make a dorling cartogram. Here is an example I am looking at http://narrativeviz.com/showcase/pindecode/

The second is treemap, which is possible in vega - https://vega.github.io/vega-editor/?mode=vega&spec=treemap

Happy to help if you can point me in the right direction on how can start on this.

[kanitw]

We have geographic in the roadmap, but it won't be included in 2.0.
Tree map is way more complicated and I don't think we will have it soon.

[kanitw]

An interesting question to think is "whether visual transforms do or do not complicate interactive selection".

(I don't think we should implement complex layout transform like force, treemap, wordcloud now yet, but it's important design decision to think about going forward. So we should note this down.)

Here is my current view after thinking it briefly. Feel free to comment / disagree / let me know if I overlook anything:

---

One interesting observation is that currently selection only does reversion of scale operation to generate data queries.

original data  ---> transform ---> data source ---> encoding (via scale function) ---> visual value
                                              <-scale inversion for selection's data query--

Selection can be applied in filter transform, but the generation of data queries is independent from transform.

---

I wonder if it's a fair policy to say that all pre-encoding transform (transform in Vega data) should be independent from selection's data queries.

For visualization that has (pre-encoding) layout transform e.g, treemap.

There are few cases that selection seem useful:

1. selection on discrete data values (says some category or exact quantitative data values) -- This shouldn't require layout inversion.
2. queries data based on layout position (e.g., brush around certain layout values) -- This shouldn't require layout transform inversion.

In a way, I can't think about any case where layout transform inversion make sense. (In a way, the layout are determine by so many factors, so in most cases there is no clear inversion method anyway.)

What may make more sense is to allow selection to query based on semantics (e.g., select neighbors for graphs / select children of a tree node) -- but that seems like another research project on its own.

---

That said, this is just a quick thought and I might overlook something.

Also, I haven't thought about post-encoding transform yet.

Another related question is how we deal with projections, which are more similar to scales. However, projection inversion is tricky as noted in #3587.)

cc: @jheer @arvind @domoritz

[kanitw]

Another interesting point that layout are like projection in a few ways:

1. They take some fields as input and implicitly affect some encoding output.
2. They act like multi-dimensional scale and do not require additional scale for relevant encodings (e.g., x/y/width/height for treemap).

One possible proposal is that, instead of treating them like transform like in Vega, layout could be a different primitive separate from transform and can generate implicit output encoding like projection.
(Transform never implicitly generates output encoding directly.)

This feels a bit more like a high-level grammar (compared to having layout transforms as just normal transforms).

Here are a few examples:

Treemap

{
  mark: 'rect'
  layout: {
    "type": 'treemap',
    "method": "resquarify",
    "ratio": 1,
    "paddingInner": 0,
    "paddingOuter": 2,
     // size is implicitly the view's width and height
  },
  encoding: {
    size: {"field": "value", "type": "quantitative"} // This is the field that affect treemap's size.  Since size is a layout-based encoding. A size scale is not created as it's taken care by the underlying layout transform.  
  }
}

Wordcloud

{
  mark: 'text'
  layout: {
    "type": 'wordcloud',
     // size is implicitly the view's width and height
  },
  encoding: {
    text: {"field": "name", "type": "quantitative"},  // this is the field for the text. 
    size: {"field": "size", "type": "quantitative"}  // this is the field for font size.  (No size scale is created.)
  }
}

[kanitw]

Note that while this "layout" concept is not critical for implementing, we need to think this through a bit as we may want to use the keyword "layout" for composition operator's underlying layout (#3270).

[kanitw]

Another thought -- for wordcloud and treemap, they could even have their own composite mark.
However, I don't know if we should do that given there are other layouts like "force" that shouldn't have its own composite mark.

[amitkaps]

From a grammar perspective, one possibility is to capture all the space-filling layout under the size encoding and introduce an option tile. This is similar to how stack and bin transform work for x or y encoding. Additional options can be specified as needed.

Treemap

{ mark: 'rect'
  encoding: { size: {"field": "value", "type": "quantitative",  "tile": "treemap"}}
}

Partition

{ mark: 'rect'
  encoding: { size: {"field": "value", "type": "quantitative",  "tile": "partition"}}
}

Unit Chart (Even for a future unit transform!)

{ mark: 'rect'
  encoding: { size: {"field": "value", "type": "quantitative",  "tile": "unit"}}
}

This grammar can work even for arc mark and can be extended for radial layouts, when introduced.

One challenge I am facing is that currently the treemap implementation is based on hierarchical data structure. So an inbuilt stratify transform would be needed to make it work, but I am struggling to make it work even in Vega.

https://beta.observablehq.com/@amitkaps/treemap-with-vega

[kanitw]

I don't think layout should be combined with size encoding as they are two distinct concepts. Moreover, there are also layouts like force that aren't directly related to size.

[amitkaps]

I will give it one other shot at explaining what I meant. This is just my proposal for a succinct grammar. Please disregard it, if this does not cover everything you have in plan.

All visualisations which have a data transformation are inherently layouts. They just operate on different channels. It would be great to capture a large portion of them (if possible) by overloading the encoding channel, similar to what bin and stack does at the moment.

Let me illustrate with a few others not yet implemented ones which are technically also layout transforms, but can be captured by overloading the encoding channel.

Density

{ mark: "area"
  encoding: { x: {"field": "value", "type": "quantitative",  "density": "true"}}
}

Contour

{ mark: "lines"
       x: {"field": "Xvalue", "type": "quantitative",  "density": "true"}}
       y: {"field": "Yvalue", "type": "quantitative",  "density": "true"}}
       size: {"field": "value", "type": "quantitative" } // Count of the lines
}

Hex Bin

{ mark: "hex"
  encoding: { 
       x: {"field": "Xvalue", "type": "quantitative",  "bin": "true"}}
       y: {"field": "Yvalue", "type": "quantitative",  "bin": "true"}}
       size: {"field": "value", "type": "quantitative" } // Size of the hexagon
}

With regards to use of the size encoding channel usage, this is already used for example to change the width of the bar. But it does not have any other layout transforms on it like x and y does. I think it should be possible to overload the size encoding with options to get a large majority of these layouts. Inherently because when we only use the size channel for the mark, the position would be calculated automatically by the tile layout. For reference, here is a ggplot example for overloading geom_rect with stat="treemap" for achieving this.

With regards to hierarchical data structure, it may well require a new encoding channels for nodes and link-path, similar to what latitude and longitude have been done for geographic plot. It would be possible to overload them for non-cartesian and non-radial structure, like force simulation.

[ksingh0307]

Hi All,

Facing an issue while creating a forced directed layout graph in vega-lite. how I can implement a forced directed layout graph through vega-lite. Please guide me.

Thanks in advance.