Make bars in rank plot perfectly adjacent about qurro

[fedarko]

well, i managed to figure out that if you don't set size explicitly, you can still adjust it in a global bar config via continuousBandSize. As with when I first started working on rankratioviz, setting a size > 1 addresses the problem but makes bars overlap when zoomed out.

All I want is just to have non-overlapping bars that, at every zoom level, are continuous. I feel like that has to be possible.

[fedarko]

See https://stackoverflow.com/questions/55543912/making-vega-lite-bar-marks-adjacent!

Using an ordinal x-scale resolves this, at the cost of losing the ability to change the x-axis labels with zoom level. Options:

• use a slightly larger size value for bars (e.g. 1.5)
  • good: free zooming
  • problem: this still has the "covering" problem when zoomed out
• use an ordinal x-scale and remove the x-axis labels entirely, or use an ordinal x-scale and figure out ways to deal (e.g. setting the x-scale rangeStep to something small like 1-5 makes this more doable, at the cost of slightly strange-looking axis labels that we'd want to manually adjust/fine-tune to make look good)
  • problems: not so great zooming; if rangeStep is 1, the chart fits in the space but the bars are still hard to select, and if rangeStep > 1 the bars are easy to select but the chart gets really long (which can mess up the page layout).
  • good: no covering problem, and setting rangeStep > 1 makes the bars beautiful + easy to select

will think about this

[fedarko]

wait here's a dumb idea. Can we make bar size a signal (default value 1), and increase the signal when the zoom level changes? That might actually work, although there are probs lots of edge cases (e.g. only a few features -> plot might start out with small bars).

[fedarko]

Something worth thinking about is that the "covering" thing still happens, even with size=1.0 (albeit to a lesser extent). If you zoom out far enough, things start to get kind of unreliable.

I'm starting to think that using ordinal might just be the best solution (with "scale": {"padding": 0, "rangeStep": 1} included in the x Vega-Lite definition). This also seems like it'd address #70, since the x-scale is locked (so it's easy to go between types of ranks, even with moving stuff around). I could also probably do stuff like adding a "reset graph" button or whatever, in case the user accidentally zooms in too far.

The downside of this is that it makes it harder for users to select individual ranks. If we can make the rangeStep configurable somehow, that'd address that, I guess?

Update: I don't think there's really an easy way around this, since after a certain point a bar mark's size (width) needs to be less than 1 pixel (and then we get into problems with inaccuracies in how things are displayed). We could possibly set a zoom limit, but:

1. I'm not even sure if this is doable in Vega-Lite/Vega without taking the trouble to set up a signal and updating that when the zoom level gets unacceptable (might not be as easy as in Cytoscape.js where you can just set a zoom limit with one function call)
2. It might just straight up not be possible to show all of the features in the rank plot without getting to some inaccuracy (if rangeStep is effectively < 1) or without a very long rank plot (as discussed below).

A "downside" of the ordinal approach is that it requires the chart to expand to a width of rangeStep * (number of ranked features). So if you have, say, 3000 ranked features (e.g. in the Byrd data), the ordinal chart will extend past the edge of the screen unless you have a super huge screen. You can figure out how to adjust rangeStep based on the number of features (so if you want the chart to be 400px wide, you can set rangeStep = 400 / (number of features), but then the bars have subpixel sizes and we can't guarantee that they're being shown correctly. The ordinal approach (using rangeStep >= 1) is nice because it's correct, but it results in really long charts if you have a large amount of ranked features to show.

Some approaches that might work for this:

1. Making use of high-resolution displays (e.g. the vroom) -- of course, this isn't an option for most users, but it'd be cool to try out
2. At least figuring out when subpixel bars are being used, and inform the user accordingly (via an unintrusive note or something). This would involve messing with the underlying SVG/canvas stuff (as described with the zoom level thing above), but should be doable (will probably have to go below the Vega stack). If we can make this dynamic, then it would let the user see when zooming in to the chart would "fix" the widths.

[fedarko]

So here's a silly thing. Turns out that the order of the data in the rank plot impacts the sort of "order" that the features have in drawing.

As a test of this, check out this old version of the rank plot from a few hours ago. (was gonna paste the spec but the URL is too large lol)

And look at the spec on the current part of the better-no-rank-signals branch:

In the second plot, you can see how it looks like there are far less numerator feature ranks than in the previous plot. (both of them were set to have "Bacteria" or "Bacter" or something as the numerator, doesn't really matter) But nope, these have the same data underpinning them—all that's changed is the ordering of this data.

And this makes sense—the previous approach sorted the ranks by the Intercept, so there was a sort of "bias" towards the later features in the intercept rank for their "precedence" or whatever. But now, we just go with whatever ordering is present in the rank file—and as it turns out, that one sorts features alphabetically, so all of the features with IDs starting with "Bacteria" get shunned compared to all the Viruses in the data.

Sure, we can re-sort the data and at least restore the behavior to how it was before, but ...that won't fix all our problems. The best solution here IMO is one that ensures that at least one pixel is being used for each feature in the rank plot, so I think it's time to switch to using an ordinal rank plot. (Now that #110 has been addressed, this should actually be doable.)

[fedarko]

See vega/vega-lite#4974, which (I think) is currently preventing switching to an ordinal rank plot.

[fedarko]

lol nvm, this should be doable