ordinal interval

[mbostock]

Fixes #513.

When a scale has an interval option, interval.floor is used as the scale transform, and then for ordinal scales, the domain is computed using interval.range(min, max), ensuring that gaps are shown and that ordinal values appear in the intended order.

[Fil]

Taking a bit more time than expected because it has implications on the warnings; for example if you have a date interval on x you don't want a warning that the dates are unexpected in an ordinal scale.

[Fil]

This is going to be so useful! Solving a good part of the trouble with ordinal years.

#852 complements this PR by suppressing the warning on ordinal dates in the case of a scale interval.

[Fil]

A few more suggestions, maybe for a fast follow:

• Should we bail out if this generates tens or hundreds of thousands of ticks? Maybe you passed dates and say "interval: 1" because in your mind it's one day, and suddenly plot wants to compute millions of milliseconds? (If this reaches billions, the browser might bail out by itself, throwing RangeError: Invalid array length, but there is a range where it will try to compute hundreds of thousands of dates.) I think it would be fair to cap this at 1000 or even 5000.

• If x has an interval: 1 (but still a "continuous" mark), then it should be an indication that the user doesn't want fractional ticks? This would feel like a natural way of solving When all the values are integers, skip fractional ticks? #355; likewise with interval: 10 we would only want ticks that are multiples of 10; similar story for date intervals.

• The scale interval creates a transform that is applied after stacking, resulting in non-stacking bars. Which makes me want to allow stacking of events that would belong to the same bar although they don't have the exact same x. Note that using "interval" inside a Plot.barY's options is meant for the other axis. I don't know how we can address this issue.

[mbostock]

Should we bail out if this generates tens or hundreds of thousands of ticks?

Should this be a more general error if you have a Very High Cardinality Domain (VHCD) on an ordinal scale? Or maybe just for a point or band scale? I think it’d be pretty easy to add this check in the scale constructor when the domain is not set explicitly.

If x has an interval: 1 (but still a "continuous" mark), then it should be an indication that the user doesn't want fractional ticks?

If x has interval: 1, then it will have a default transform of Math.floor, so you shouldn’t get any fractional values in the domain (unless you set the domain explicitly).

The scale interval creates a transform that is applied after stacking, resulting in non-stacking bars.

Yeah, I think this is a general confusion around scale transforms, which is that they happen after any mark data transforms. It might be better if they happened before instead, but I don’t think that’s possible (since the scale options aren’t exposed to mark data transforms). I think maybe we just live with this one.

[Fil]

The interval option should be exposed with plot.scale("x"); it is not enough to expose the materialized domain: we are missing the derived transform option.
(A way to solve this is suggested in #852, with tests)

[mbostock]

This should be ready to go.

[Fil]

Excellent! The only thing I don't like is the formatting of integers as 1.0, 2.0 etc in the test/output/integerInterval.svg plot. I hoped we could use the interval to infer that the format should not include the decimal dot—but that will be for another issue.