-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Aggregated pie charts #2073
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Lego-like constructionOn one hand, bundling logic with view has benefits. A user who needs a histogram has the effortless task of just saying, On the other hand, we know that Yet, Now it turns out that There are benefits to reflecting such structures in code and in the API. In code, it can cut a lot of duplication, because things build on one another (ofc I'm not saying Why is it not enough to let users do their own preaggregation? If they have an alternative binner, they can just compute histogram heights and just use our What's the context here? It's at least the The result is that we can consider our pipeline a directed acyclic graph which
This DAG is not necessarily a layered graph, the user may have a bunch of nodes in sequence along some paths and one transform or direct rendering of data to view in others. It can go further than that. Individual plots, such as a lowly If we deconstruct what individual plots mean, we'll end up with a smallish set of vocabulary and a compact grammar to bind them together, out of which lots of things can be composed. For example, easy to replace an SVG Lego block for a simple point rendering to a Canvas or WebGL Lego block, because the block serves a very limited, narrow, well-specified purpose with clean connections (interface) no matter where it is in the DAG. Basically this is a key idea around tl; drSo in short, I think that a new |
closed by #2117 |
A common use case for pie charts is like histograms - aggregating all entries for a given label into a single slice, either with an explicit
values
field or without (then the value is just the count of items). I'm thinking about cases like https://simonbjohnson.github.io/Ebola-3W-Dashboard/ (the two pies in the middle are aggregating row counts by either activity or country) and the canonical "sales by region" pies where each slice is the sum of revenue within some category label.In principle you can already do this with an
aggregate
transform, but this seems like a common enough use case (and transforms have enough drawbacks) that both we and our users would benefit from it being built inpie
functionality.Things to consider:
pie
type, rather than making a new type (like the distinction betweenbar
andhistogram
). Does this cause any problems? At least at first that would restrict it to discrete labels, I suppose down the line we could add binning but that'd be a weird thing to do with a pie.arrayOk
attributes - do we need to provide egcolor
redundantly for every item? Do we just take the first value we find? Do we make some way to provide this once per slice, like adistinctlabels
attribute and all thearrayOk
items just map to that? I think we do NOT want to match the way we (accidentally) did it withhistogram
where these attributes map to bins (in this case that would mean the distinct labels, in whatever order they might show up)cc @etpinard @monfera
The text was updated successfully, but these errors were encountered: