You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For some data it is possible for the colourbar to cover a fraction of the colourspace smaller than that covered by the data. It can be confusing when the guide for a continuous scale does span the full mapped space of an aesthetic.
Actually, this bug is probably triggered every time there is a colourbar, but in most cases it is small and imperceptible. With colourmaps like viridis, the cases where it is obvious should only go up.
In the reprex below, I had to do some contriving (nbin=7) to reveal it.
The root of the issue is pretty does not guarantee that the breaks it computes are close enough to the limits that the difference is not perceptible when mapped to a colour.
A simple but partial solution is to increase the default guide$nbin parameter. This would give pretty enough wiggle room to work with and reduce incidences of the bug.
A better solution is recognising that the "raster" colourbar does not need to be generated using 'pretty' breaks, a seq(.limits[1], .limits[2], length=guide$nbin) can do. For this solution the current value of nbin need not change except for the craziest of colourmaps.
The text was updated successfully, but these errors were encountered:
For some data it is possible for the colourbar to cover a fraction of the colourspace smaller than that covered by the data. It can be confusing when the guide for a continuous scale does span the full mapped space of an aesthetic.
Actually, this bug is probably triggered every time there is a colourbar, but in most cases it is small and imperceptible. With colourmaps like
viridis
, the cases where it is obvious should only go up.In the reprex below, I had to do some contriving (
nbin=7
) to reveal it.The root of the issue is
pretty
does not guarantee that the breaks it computes are close enough to the limits that the difference is not perceptible when mapped to a colour.A simple but partial solution is to increase the default
guide$nbin
parameter. This would givepretty
enough wiggle room to work with and reduce incidences of the bug.A better solution is recognising that the "raster" colourbar does not need to be generated using 'pretty' breaks, a
seq(.limits[1], .limits[2], length=guide$nbin)
can do. For this solution the current value ofnbin
need not change except for the craziest of colourmaps.The text was updated successfully, but these errors were encountered: