Overwide heatmap bins coloring areas that shouldn't be colored

[jariji]

From MakieOrg/AlgebraOfGraphics.jl#407.

I reported

I expected the ! facet m row to be empty but it has colored boxes without text. There is also something strange going on with the tick alignment around there.

let
  n = 1000
  df = DataFrame(x=rand('A':'Z',n), y=rand('a':'z',n), z=rand(1:1000,n), c=rand('!':'%',n))
  d = combine(groupby(df, [:x,:y,:c]), :z => sum)
  # Remove values for one facet and row.
  subset!(d, [:x,:y,:c,:z_sum] => ByRow((x,y,c,z)-> !((c == '!') && (y == 'm'))))
  ll = (
      data(d)
      * mapping(:x,:y; layout=:c)
      * (
          visual(Heatmap) * mapping(:z_sum)
          + visual(Makie.Text; align=(:center,:center), color=:red) * mapping(text=:z_sum=>verbatim∘string)
        )
  )
  draw(ll; figure=(;resolution=(3000,2000)))
end

@piever said

What's happening IMO is the following. Makie sees a gap in the axis (from l to n, which has been automatically translated to integers by AoG) and is expanding the boxes to fill in the gap.

The conversion is happening here. This should probably be fixed on the Makie side first. Maybe one could allow an optional width argument to heatmap to help compute correct edges?

using CairoMakie
heatmap([1, 2, 4, 5], [1, 2, 3, 4], rand(4))

[jariji]

Bump. This issue makes heatmaps hard to interpret.

[jkrumbiegel]

Makie supports irregular heatmaps, and the vector conversion just looks at all the center values you're passing and assembles them into a grid. Makie does not care if the grid is regular or not. You would need to add a 3 with NaN value and then the grid would be like you want it. We can't really guess if a grid irregularity is on purpose or not.

[jariji]

In this example, in the left facet/pane, the i row is removed from the data. But the i tick label still exists (due to the other facet still having data in the i row), so when the left facet has colors in the i row, it looks like there is i data in that facet too. If I'm careful I might notice it doesn't line up quite right, but that's risky.

using DataFrames, AlgebraOfGraphics, CairoMakie
n = 1000
df = DataFrame(x=rand('A':'G',n), y=rand('a':'m',n), z=rand(1:100,n), c=rand('!':'"',n))
d = combine(groupby(df, [:x,:y,:c]), :z => sum)
# Remove values for one facet and row.
subset!(d, [:x,:y,:c,:z_sum] => ByRow((x,y,c,z)-> !((c == '!') && (y == 'i'))))
ll = (data(d) * mapping(:x,:y,:z_sum; layout=:c) * (visual(Heatmap) * mapping()))
draw(ll)

Creating cells to fill with NaN is ok as a workaround but I won't remember to do that (or want to) and I'll misinterpret my plots.

The problem is that there is a tick on the axis but it doesn't mean there is data there. In both of these cases, it hallucinates an axis tick: in the i case it comes from the linked other facet and in the 3 case it comes from assuming the integers are cardinal.

So there is a tension between

• stretching each observed data block up to the edge of the next observed data block, i.e. 2<->4 and h<->j
• showing a tick at that meeting point indicating that values for 3 and i are observed there

I think there ought to be a way to resolve this. Maybe in the 3 case, heatmap could be told that those numbers are categorical, not cardinal. Or some other solution...?

[jkrumbiegel]

Ok yes I agree this is problematic, but to me it's an AlgebraOfGraphics problem. It should probably add the missing categories in each heatmap when it links the facets.

[jariji]

heatmap([1, 2, 4, 5], [1, 2, 3, 4], rand(4))

Would it be good to have a way to specify a different partitioning of the x space, e.g. if I want equal-width columns instead of proportional columns? I think that's what piever was suggesting.

eg width=[1,1,1,1] or width=:proportional

[ffreyer]

Closing this a wont-fix.

If you want a gap at x = 3 you either have to to use 1:5 with a NaN column (?) in the matrix or split your data into two heatmaps.