Deneb: implicitly calculated columns messing up x axis positioning for labels

[sean_cochran]

I have a Deneb visual using vega lite. I used transforms to calculate a field for the x-axis position of labels (a text mark in the same layer object) hovering above bar marks - the field is called "DifferenceHalf":

Relevant code snippet below:

{
      "sort": [{"field": "PromoterCategoryLabelMathSort", "order": "ascending"}],
      "window": [
        {
          "op": "lag",
          "field": "PromoterCategoryPercent",
          "as": "PriorPromoterCategoryPercent"
        }
      ],
      "groupby": ["Series"]
    },
    {
      "calculate": "datum.PriorPromoterCategoryPercent == null ? 0 : datum.PriorPromoterCategoryPercent",
      "as": "PriorPromoterCategoryPercent"
    },
    {
      "calculate": "1 - (datum.PromoterCategoryPercent + datum.PriorPromoterCategoryPercent) + (datum.PromoterCategoryPercent / 2)",
      "as": "DifferenceHalf"
    }

The transforms implicitly calculated two columns ending in "_start" and "_end":

Since these values go beyond the max column size of 1, I'm guessing they are causing the formatting errors. I found very little information on the _start and _end columns when googling. I could not find any reference in the docs.

Can anyone explain why these columns were generated and why Vega Lite is referencing them implicitly in my label positioning? Ideally, I'd love to just use the field I calculated and not have Vega Lite implicitly reference these other columns.

[avadaisyy]

Hello

It appears that the x-axis location is acting in an unanticipated way due to the "DifferenceHalf" field. Have you verified that each data point's field is being computed correctly by the transform logic? Small differences in the computation can occasionally cause the visual to be out of alignment. I'd be pleased to check over and assist with troubleshooting if you could provide more information about the transform or a sample of your code!

Regards

Ava Daisy

Prestige Palm Court

[sean_cochran]

Thanks for the response! I have already solved this issue, but your suggestion was right on the money - DifferenceHalf was not being calculated correctly. However, this issue was confounded by the fact that I had the "stack" property enabled. The stack property adds each calculated value of the field to the prior calculated value (these running totals appear to be tracked in the _start and _end columns I referenced), meaning that in addition to being calculated incorrectly, each new incorrect DifferenceHalf value was added to the running total of the prior values for that series, resulting in some very odd label positioning no matter how I calculated DifferenceHalf. Once I turned "stack" off, I was able to troubleshoot and get DifferenceHalf working correctly using the values I needed. The chart is now working as desired. Lots of user error here!

[lbendlin]

Have you tried using sum instead of lag ?

"transform": [
      {
      "window": [
        {
          "op": "sum",
          "field": "CU (s)",
          "as": "cum_total"
        }
      ],
      "sort": [
        {
          "field": "CU (s)",
          "order": "descending"
        }
      ],
      "frame": [null, 0]
    },
    {
      "calculate": "datum.cum_total - datum['CU (s)'] + 2", "as": "bottomedge"
    }]

[sean_cochran · Accepted solution]

Thanks for the response. I discovered that my problem was unrelated to the use of a window function. The extra columns are created when the "stack" property is enabled. I had it turned on while experimenting to solve an unrelated issue. When I set "stack" to "false", the additional columns disappeared, and labels were positioned absolutely (instead of relative to the _start and _end columns that were created by the "stack" property). I have not tried the cumulative sum function - that could be an elegant way of achieving the desired positioning. I found another way to achieve the desired result.