Sharing y axis between density chart and used color plots also affects main plot

[edwardchalstrey1]

• hand-crafted Vega-Lite experiment (either MWE to post to Stack Exchange, or to find a solution)
• resolve_scale: experiment with y='independent' on root chart and y='shared' on subcharts ❌
• scatterplot test case to document that @meta_hist requires encoding.color.bin to be defined
• scatterplot test case to illustrate behaviour we want to fix
• rename tests/test expectations to remove _altair
• test case for encoding.color.bin = False (not the same as undefined)
• is_defined helper
• choropleth tests to assert placement of ticks on left x-axis (as regression test)

---

For some reason, this code in ways.py results in y axis being shared on all three plots - can we respecify so the y axis of the main plot is unaffected?

meta_chart: alt.Chart = (Ways.density_chart(src) | Ways.used_colours(src)).resolve_scale(y='shared')
return (meta_chart | src) \
    .configure_view(strokeWidth=0) \
    .configure_concat(spacing=5)

[rolyp]

@edwardchalstrey1 Reopening this (as I guess it was closed automatically as part of #65).

[rolyp]

@edwardchalstrey1 Yeah, so adding a new test for the IMdB vs. Rotten Tomatoes example reveals one problem. In that example, if you remove @altair_widgets() and just keep @meta_hist, you get AttributeError: 'UndefinedType' object has no attribute 'extent'. @meta_hist is something that needs to work independently of @altair_widgets, so the first thing to do when investigating using @meta_hist with a scatterplot would be to create a new test case with a minimal scenario (rather than a notebook with a more complex scenario).

I feel like there's a lesson to learn from the last few days: we should be working in a more test-driven way. When we discover problems, they should be documented with tests -- either tests which demonstrate that something fails (as in this case), or that record a behaviour baseline that we want to move forward from (so that we can still refactor/redesign safely when fixing the problem).

[edwardchalstrey1]

Agreed, I'll try to make use of draft PRs as well where appropriate so you can see what changes I'm making

[rolyp]

@edwardchalstrey1 Just to clarify, specifying False for color.bin isn't the same as not specifying it at all. I've added new test cases for both: in the unspecified case (where encoding.color.bin is "undefined"), we fail (intentionally) with an exception; the test checks this. (We could implement a different policy, e.g. mapping undefined bin to False, but this seems a reasonable starting point.) In the False case, the "used colours" visualisation disappears, as being dealt with in #63.

[rolyp]

@edwardchalstrey1 I've added some new testing infrastructure which should make it easier to move forward with this issue, #63 and #58. (I'll summarise that separately on Slack.) Re. this particular problem, I haven't managed to make progress -- I wasn't able to find a way to allow y-axis sharing on the subcharts without forcing sharing with the main chart. But you've experimented quite a bit already, so perhaps you'll have more success.

I added regression behaviour to the choropleth tests that means they will fail if the encoding.y.axis.values changes on the density plot. This will rule out a change that, for example, sets that axis to have the same tick marks as the "colours used" plot.

One idea I had (mentioned as a task above) is to create a standalone Vega Lite MWE that illustrates the problem. If we manage to create such a thing, we'll have a succinct description of the problem, which we can post to Stack Exchange. If we don't, then we've solved the problem.

[edwardchalstrey1]

@rolyp ok, so we don't want the same tick marks as the "colours used" plot to be used, but we will need to change the values of encoding.y.axis.values to change the ticks for #58