Vega-lite: Use `zindex` for layer `order` channel instead

[kanitw]

Currently we use sort transform to determine layer order for order channel.
In Vega 3, we can consider using zindex property instead.

[kanitw]

Maybe we just add zindex or layer as its own channel?

This might allow us to make order means either path order or stack order and free up path channel for Geo stuff.

[jheer]

In case this effects your reasoning (it may not, but just to be safe): zindex is used only for sorting sibling nodes in the scenegraph tree. If zindex is set on individual items, it will have no effect on the ordering relationship between items that are children of different marks.

[kanitw]

Since zindex expects non-negative integer, looks like we have to apply rank transform to determine range of zindex scale.

[kanitw]

TODOs

• [ ] Try modifying Vega manually

  • [ ] add scale for zindex based on origin.
  • [ ] How can we automatically determine range for zindex's scale
  • [ ] Add zindex to mark's encode using the scale above.

• [ ] Modify the code

  • [ ] deal with the range for zindex scale
  • [ ] Add zindex following the typical steps for adding channel in #1278

[kanitw]

How can we automatically determine range for zindex's scale

If we really need to do this, we might want to add this as a part of the layout data source rather than adding a new data source.

[kanitw]

Since this is (1) complicated and (2) doesn't seem that useful anyway. Let's not include zindex in VL2. Whenever users need to re-order zindex their marks, it's a sign of overplotting anyway.

[arvind]

zindex support would be helpful for interactive use cases to pull selected points to the foreground:

z-index-less: partially occluded points can be selected, but then are only partially visible.

with a simple z-index definition (in Vega)

[kanitw]

Actually, one quick question --- do we always want this behavior for selected point?
If so, we could add zindex to the output Vega without adding new encoding channel in Vega too.

(Or even if we don't, we make this a config.)

[arvind]

Good question. I thought about it but wasn't able to think of zindex outputs that would generalize across selection designs (e.g., what if you wanted to highlight points _not in_ the selection, then the selected points should have a lower zindex; what to do with multiple selections per unit spec, etc.)

[kanitw]

@arvind Do we still need this for 2.0 -- if not, we can move to Milestone 2.1?

[arvind]

Not required for 2.0. I switched the query_widgets example to explicitly use layers with #2464.

[kanitw]

Note that I just make order for non-stack, non-line marks affect the underlying Vega mark's sort property, which also affect the other. However, z-index may still be useful for the use case above.

[domoritz]

Why can we not use order for the case above? You could set the order to be a special value if it's in the selection.

[kanitw]

Order right now is designed to be mapped to mark sort, not zindex so it doesn't support ValueDef.

Also, even if we add special case to map "value" order to zindex, order still won't work with line's zindex as for line, order mean order of points in the line.

[cogpie]

Just to add another voice to a request in this space. Ran into the same issue as @arvind above, although somewhat worse as the data is categorical on both axes. It could be I am doing visualisation all wrong, but in this context I have selected points hidden behind others on top.

My current workaround is to have the opacity of others decrease, and the increase the size of those selected. Not ideal but it makes the data visible.

(If you excuse the Elm, I tried to do something like this: encoding << order [ mSelectionCondition (selectionName "foo") [ mZIndex 1 ] [ mZIndex 0 ] ])

[domoritz]

You can also create a second layer with just the filtered data.

[kanitw]

This is a duplicate of https://github.com/vega/vega-lite/issues/4864, which is now fixed.