jheer
commented
4 years ago To help seed thinking here are some hypothetical VL-API specs.
I also recommend studying these Vega examples:
- https://vega.github.io/vega/examples/contour-plot/
- https://vega.github.io/vega/examples/density-heatmaps/
- https://vega.github.io/vega/examples/annual-precipitation/
// CONTOUR PLOTS
// contour plot from input raster grid data
vl.data(rasterData)
.markContour({
raster: true || field,
thresholds, levels, nice, resolve, zero, smooth, scale, translate, // isocontour params
})
.project(...projection...)
.encode(
vl.color(), // standard encoding
vl.opacity(), // standard encoding
vl.column(), // standard facet
vl.row(), // standard facet
)
// contour plot from input point data
vl.data(pointData)
.markContour({
raster: false || null,
cellSize, bandwidth, counts, // kde2d params
thresholds, levels, nice, resolve, zero, smooth, scale, translate, // isocontour params
})
.project(...projection...)
.encode(
vl.x(), // -> kde2d x
vl.y(), // -> kde2d y
vl.longitude(), // alternative, output goes to kde2d (x,y)
vl.latitude(), // alternative, output goes to kde2d (x,y)
vl.weight(), // -> kde2d weight
vl.color(), // -> kde2d groupby, standard encoding
vl.opacity(), // -> kde2d groupby, standard encoding
vl.column(), // -> kde2d groupby, standard facet
vl.row(), // -> kde2d groupby, standard facet
)
// HEATMAP PLOTS
// heatmap from input raster grid data
vl.data(rasterData)
.markHeatmap({
raster: true || field,
resolve
})
.encode(
vl.color(), // heatmap color
vl.opacity(), // heatmap opacity
vl.column(), // standard facet
vl.row(), // standard facet
);
// heatmap from input point data
vl.data(pointData)
.markHeatmap({
raster: false || null,
cellSize, bandwidth, counts, // kde2d params
resolve, // heatmap param
})
.encode(
vl.x(), // -> kde2d x
vl.y(), // -> kde2d y
vl.longitude(), // alternative, output goes to kde2d (x,y)
vl.latitude(), // alternative, output goes to kde2d (x,y)
vl.weight(), // -> kde2d weight
vl.color(), // -> kde2d groupby, heatmap color
vl.opacity(), // -> kde2d groupby, heatmap opacity
vl.column(), // -> kde2d groupby, standard facet
vl.row(), // -> kde2d groupby, standard facet
);
kanitw
LeCyberDucky
metasoarous
domoritz
mattijn
jonathanzong
Hi all,
I would really like to expand Vega-Lite with support for 2D density representations, leveraging Vega's
kde2D,isocontour, andheatmaptransforms. Adding these would make Vega-Lite largely "feature complete" for my current visualization teaching needs, and make it more comparable to other popular plotting libraries. However, it is not clear how to best do this.I see two general approaches:
Use existing mark types only (
geoshapefor contours,imagefor heatmaps) and leverage new transforms (density2d,contour, andheatmap) to generate the appropriate input data to the mark. This is the same approach we've followed so far when adding transforms such asdensityandregression. However, Vega'skde2dandheatmaptransforms both interleave data-space and encoding-space concerns in ways that make this difficult. For example, thekde2dtransform takesxandyfield accessors that must return pixel-space values. Typically this is done using an expression that maps an underlying data field through a defined scale transform. So, for this to work in Vega-Lite we need a way to generate / access appropriate scale transforms, introducing a cross-cutting concern. Moreover, we'd like Vega-Lite to also use those scales to add appropriate axes, so we'd also have error-prone redundancy in the specification if we need to provide x/y fields in both the transform and encoding. (This is further complicated by the fact thatgeoshapedoesn't takexandyencodings anyway...) Theheatmaptransform has a separate issue, which is that it accepts expressions for determining pixel color and opacity. While these can be stand-alone, most times we actually want to use a defined color scale (and corresponding legend), again mixing transform and encoding concerns.An alternative is to create new mark types, such as
contourandheatmap. Ideally these marks could accept either pre-calculated raster grid data (from which contours / heatmaps can be directly generated) or point data (to which thekde2dtransform would be applied). The Vega-Lite compiler would need to generate appropriate transforms and encodings. I imagine transform parameters could be passed as mark properties. There are still some limitations to this approach: in Vega we can separately generate heatmap images and then use them as input to image marks, such that we could in theory do things like create an entire scatter plot where each point is a small density heatmap. However, I don't think this extra expressiveness is critical for Vega-Lite. The biggest hurdle to this approach is that I have no idea how to implement it in the current VL compiler. So I can't estimate the feasibility or difficulty. That said, I would be happy to collaborate with someone more knowledgable.While neither solution is completely satisfactory, I'm leaning towards the approach of adding new mark types. I think the interleaving of data-space and encoding-space operations in VL transforms breaks too much, in terms of both output and user mental models.
Any thoughts or feedback, particularly relative to the feasibility of option 2?