Add convenience extent calculation for bin transform?
jheer opened this issue · 5 comments
The bin transform requires the extent (min/max) values to be provided/calculated externally, a change from Vega 2. Should convenience extent calculation be added back?
Explicit extents have the advantage that a reader immediately knows when the extent changes.
For instance, if we use a filter before binning, does changing the filter predicate change the extents? If the extent is manually set, no. If it is driven by the data, yes. If it is driven by a signal, the extent changes when the signal changes.
I suppose that a data driven extent by default makes sense but I think the advantage of explicitly knowing where the extent comes from is larger than the benefit of not having to add an extent transform.
If I have to type Vega spec by hand, I probably would appreciate this. However, from programming generation perspective (e.g., VL), extent + bin seems fine.
-
Note that I still see"field"in the bin transform's JSON schema. If we decide not to include this, we should remove it from the schema
The field parameter is used to specify which tuple values to bin. So we most certainly should NOT remove it!
OK, closing this issue for now as it sounds like an explicit extent transform works. Others should feel free to respond / re-open with an argument for including a convenience "auto-extent" functionality.