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
I think jittering is an important and often used functionality, especially for statistical and scientific charts. Ideally, I believe it should be so simple to use that it can be introduced right after showing how to do a simple categorical scatter/dot plot as a way to deal with there being too many points. For example, from this simple example:
I would like to reach the following chart with minimal modifications:
However, jittering is currently somewhat tricky to use correctly, and there is in fact no straightforward path to this chart. Instead we either have to use a calculate transform plus setting the offset domain to avoid overlapping points if using the offset channel encoding, or manually specify a multiplication constant and a centering offset if we are using the mark config. I opened vega/vega-lite#9438, vega/vega-lite#9437, and vega/vega-lite#9436, to try to address these issues. If those are all fixed, we would be able to use a syntax like this to reach the effective chart above:
This is quite simple, although it involves the introduction of expr. I'm not entirely against that as it might be beneficial to see this early on and learn that it is a building block to work with later. However, part of me wonders if we should have a dedicated string function for jittering, something like:
Then jitter() could take a numerical argument that specified how much of the bandwidth should be used for the (random) jittering of the points. This would be quite different than all our other magical string functions which reference aggregation method, so I'm no sold on this idea, but thought I would write it down here while we see what happens with the VL issues I have opened.
Have you considered any alternative solutions?
Arguably the function jitter() could be implemented in VL instead, but then it would still need to be passed as an expression and the offset channels do not yet support taking expression at this point.
The text was updated successfully, but these errors were encountered:
What is your suggestion?
I think jittering is an important and often used functionality, especially for statistical and scientific charts. Ideally, I believe it should be so simple to use that it can be introduced right after showing how to do a simple categorical scatter/dot plot as a way to deal with there being too many points. For example, from this simple example:
I would like to reach the following chart with minimal modifications:
However, jittering is currently somewhat tricky to use correctly, and there is in fact no straightforward path to this chart. Instead we either have to use a calculate transform plus setting the offset domain to avoid overlapping points if using the offset channel encoding, or manually specify a multiplication constant and a centering offset if we are using the mark config. I opened vega/vega-lite#9438, vega/vega-lite#9437, and vega/vega-lite#9436, to try to address these issues. If those are all fixed, we would be able to use a syntax like this to reach the effective chart above:
This is quite simple, although it involves the introduction of
expr
. I'm not entirely against that as it might be beneficial to see this early on and learn that it is a building block to work with later. However, part of me wonders if we should have a dedicated string function for jittering, something like:Then
jitter()
could take a numerical argument that specified how much of the bandwidth should be used for the (random) jittering of the points. This would be quite different than all our other magical string functions which reference aggregation method, so I'm no sold on this idea, but thought I would write it down here while we see what happens with the VL issues I have opened.Have you considered any alternative solutions?
Arguably the function
jitter()
could be implemented in VL instead, but then it would still need to be passed as an expression and the offset channels do not yet support taking expression at this point.The text was updated successfully, but these errors were encountered: