Talles Lessa
Talles Lessa

Reputation: 71

waterfall chart Powerbi Deneb - X axis not following sort order when using x2 position on a rule

I have created this chart using vega-lite inside vega editor online Vegalite code it works fine (besides the last rule being outside the chart area ).

However when passing it to deneb chart in powerbi (the only change in the code to do so being changing the dataset to be dynamic [but still the same data]) it messes up the sorting on the x axis for the first 2 values.

I cannot figure out why, the only think i have pinpointed is that it must be something to do with x2 encoding here, because when i comment it out the sorting gets fixed.

Cannot figure out if thats a code issue or come setting over on deneb chart in powerbi

mark": {
        "type": "rule",
        "color": "#000000dc",
        "opacity": 1,
        "strokeWidth": 3,
        "xOffset": {"expr": "-(clamp((width / datum.count) / 2, 10, 25))"},
        "x2Offset": {"expr": "clamp((width / datum.count) / 2, 10, 25)"}
      },
      "encoding": {
        "x": {
          "field": "risco",
          "type": "nominal",
          "sort": {"field": "sortkey", "order": "ascending"},
          "axis": {"title": null}
        },
        "x2": {
          "field": "lead",
          "type": "nominal",
          "sort": {"field": "sortkey", "order": "ascending"}
        },
        "y": {"field": "cumulative", "type": "quantitative"}
      }
    }

Vegalite editor

Powerbi Deneb Output

Upvotes: 1

Views: 33

Answers (1)

Daniel Marsh-Patrick
Daniel Marsh-Patrick

Reputation: 181

I took a copy of the values from your Vega Editor version and made a single Power BI table from them (with some basic data typing applied). I was able to repro your original problem:

Reproduction of issue in Power BI


Note the order of fields added to the visual (as per your online version). If I check the raw data being sent from Power BI to Deneb, it looks as follows:

Raw dataset, as sent by Power BI to Deneb

As Deneb doesn't have any sorting options for the Power BI dataset as sent (usually an option in the visual header), it's being sorted in a revised order (risco first).

While the online version works, it's possibly because the inline data is supplied in a particular order compared to how Power BI supplies it. Setting the sort order for the query (like for regular visuals) is on the roadmap, but it's a little tricky to manage this in a way suitable for templates. This is being worked on, but I don't have an ETA yet.

However, this shouldn't matter if sorting is applied correctly against the dataset, but it's possible some slight quirks in the spec are preventing this from working as intended.

Note that you can skip this and keep your spec as is by enforcing the query to be sorted by the sortOrder column:

  1. Drag the sortOrder column to the top of the Values list.
  2. Remove the column that was previously the first column (risco in my repro). Power BI will remove the original sort order and apply this against the first column.
  3. Re-add this column below the first position so that Power BI retains the new sort order and you have the values/granularity of the column in your dataset.

Note that this will probably keep the wolf from the door and may fail if any further changes are made, so I'll explain how I solved it as to how I think it should be applied.


I noticed that your spec has some warnings in the log viewer (in both Vega Editor and Deneb). This is due to some of the x2 and y2 encoding channels having either an instance of a sort or type property. The type is assigned/inherited by the corresponding x or y encoding channel and may cause issues with how scales are worked out if left in.

There are also some explicit sort directives applied in encoding channels for each layer. As Vega-Lite will union scales over layers, I think each one of these instances is perhaps overloading the intended behaviour of the top-level x encoding.

You'd correctly added an op to the top-level x encoding's sort to handle the uion across layers but min is seemingly not returning the correct value and causing the mismatch. If/when I have more time, I'd have to look into why this is and understand it better, but I would typically use max for these scenarios, and changing it after the above removals seems to create the desired output:

Resolved specification, with bars in the correct order


I've also prepared a .pbix with this in for you to go over as and when (or check my changes are actually right!). Hopefully you should be able to download this from here. Let me know if not and I'll try again with the permissions.

Upvotes: 2

Related Questions