jittering, offset/nudge, dodge

[kanitw]

See http://docs.ggplot2.org/current/geom_jitter.html, http://docs.ggplot2.org/current/position_nudge.html, http://docs.ggplot2.org/current/position_dodge.html for example

[kanitw]

This would require a random transform in Vega (or at least access to random call in expression)

[kanitw]

A tricky questions is whether dx should share the scale with x (and the same for y) and if not, what should be the default scale.

Thinking of a few cases.

For dodge, this is basically having x-scale as a band scale and dx-scale as another band scale that has a range = [0, bandwidth of x scale]. (I don't think we have to care about preserve = "single" option in ggplot, it's a bad idea IMHO anyway)

For jitter, this is basically having x-scale as a point scale, and dx mapping a random value (say from [0,1]) to [0, bandwidth]. Another way to think is mapping random value from [0, bandwidth] with an identity scale (f(x) = x).

nudge is simply mapping fixed value to dx/dy. No scale needed!

For these examples, it seems like dx should have its own scale (not sharing with x).

However, if we think about stack offset example, we might still want the offset value to share the scale.
But that would make the scale domain a bit weird anyway, so it might be better to just have explicit stack transform and calculate the new x and x2 directly.

[kanitw]

We probably have to think what's the right scale type and range for dx based on x's scale type

• x = linear/time (Q/T),
  • dx is Q/T -- should dx be linear too? or just identity?
  • dx is N/O -- ???
• x = non-linear (Q)
  • dx is Q/T -- what's the right thing to do? (I guess identity? -- although this won't make sense for the most case, we should still provide some okay-ish default)
  • dx is N/O -- ???
• x = band/point --
  • dx is Q/T -- identity or linear (this is the jitter case like described above)
  • dx is N/O -- band or point (this is the dodge case like described above)

[kanitw]

We will probably implement the mark definition support for now #3328.

Note that we can't call them dx and dy as dx and dy are offset for text marks that are applied before rotation (with angle) but the general offset would be applied after. So maybe offsetX/Y/X2/Y2 maybe better.

[kanitw]

We are thinking that we will eventually support offsetX/Y/X2/Y2 as channels so it's something like this.

encoding: {
   x: {field: ...}
   offsetX:  ... field or value definition ...
} 

Another possible model is having offset nested under x/y/x2/y2 like in Vega:

encoding: {
   x: {
     field/value: ..., 
     ...,
     offset:  ... field or value definition ...
   }
} 

However, this model has a major flaw when using with condition, in the sense that we can no longer enforce that users can only map only one field to "offsetX" -- which will violate current architecture that only allows one field per channel (condition only support one field in their branch)

x: {
  condition: {
    field: …, type: …,
    offset: {
      condition: {test: …, field: 'a', type: ..., scale: ..., (no axis)},
      …
    }
  },
  value: …
  offset: {
    condition: {test: …, field: 'b', type: ..., scale: ..., (no axis)},
    …
  }
}

Plus, this look super messy.

[kanitw]

The trickiest part of supporting this offset is how to make it work correctly with interval selection.

[domoritz]

Can the x axis be discrete?

[kanitw]

Yes. We need to think this through and prototype different cases. Probably wont get to do that until my thesis is stable lol

[kanitw]

vega/altair#1055 is another use case where offset is useful as an encoding channel so we can do conditional offset.

[kanitw]

I think this is one of a few things that I want to tackle in the next 1-2 months, given group bar is a quite common use case and we don't do it that well yet.

[kanitw]

I'm creating #4703 to propose x/yOffset channel as a solution to this. (This issue is getting too long, so I'm closing it. Let's discuss more in #4703).