Open
Description
openedon Aug 6, 2019
Looking at the density examples, I think there are opportunities for having inline density transform. Here is my first stab at such syntax.
From:
{
"$schema": "https://vega.github.io/schema/vega-lite/v3.json",
"data": {"url": "data/movies.json"},
"transform":[
{
"density": "IMDB_Rating",
"bandwidth": 0.3
}
],
"mark": "area",
"encoding": {
"x": {
"field": "value",
"type": "quantitative"
},
"y": {
"field": "density",
"type": "quantitative"
}
}
}We could consider something like:
{
"$schema": "https://vega.github.io/schema/vega-lite/v3.json",
"data": {"url": "data/movies.json"},
"mark": "area",
"encoding": {
"x": {
"density": true | {
"bandwidth": ...,
"extent": ...,
"minsteps": ...,
"maxsteps": ...,
"steps": ...
},
"field": "IMDB_Rating"
"type": "quantitative"
},
"y": {
// density: string is for customizing density estimate (which correspond to the `c
"density/estimate": "probability" | "count" | "cumulative-probability" | "cumulative-count"
"type": "quantitative"
}
}
}groupby should be derived from other field presented in the encoding (just like aggregate)
Potential Improvement
- There are two parts of density -- (1) one representing the field that we estimate and (2) the estimate density / count. My proposal above uses the term
densityfor both and use types to distinguish their roles (boolean / object for the field, string literals for the estimate), but we could consider using two different keywords (e.g., density for (1) and estimate for (2))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment