I have following use-case:
- Multiple datasets should be displayed as a column chart
- The datasets have different units, 2 in my case, but in theory the datasets can
have 1-n units - For each unit I want to create a separate axis
- Datasets that have the same unit should be stacked above each other
Heres a screenshot (not implemented in SciChart, but I’d like to rebuild this chart in SciChart!):
See attachment or https://ibb.co/2S8fhZb
My approach was following:
– Create one y-axis per unit (so I have 2 y-axes in my example)
– Create one StackedColumnCollection
per unit, with the unit as their yAxisId
– Create a StackedColumnRenderableSeries
for each of my datasets and use the unit as the stackedGroupId
– Add the StackedColumnRenderableSeries
with the same unit to one StackedColumnCollection
– Add the StackedColumnCollection
to the chart
All my series render, in theory. But the last added series of the StackedColumnCollection
always overlaps the other StackedColumnCollection
s. In my 2 other attachments you can see, that the green series overlaps the blue series.
It works fine, when I only use one StackedColumnCollection
or don’t use them at all. But I didn’t see any possibility to use multiple axes in this case.
Am I going for the wrong approach? Is this not how StackedColumnCollection
s should be used? If so, is there any other possibility to cover my use-case?
- Max Geldner asked 1 month ago
- last edited 1 month ago
-
Hello, I suspect the reason for that may be that there is a different number of stackedGroups per StackedCollection. But that’s only an assumption. Could you send us some code snippet with chart setup and mocked data so that we could check and reproduce?
-
Hey, thanks for your quick answer. I created a minimal example with 4 series, 2 axis and 2 collections: https://codepen.io/maxgeldner/pen/KwPqzVL?editors=1011 – 2 series (“electricity” and “heat”) belong to an axis with unit “kW”, they are in the same stackGroup (also “kW”) and added to one collection that maps to the yAxis with Id “kW”. – 2 series (“water” and “pressuredAir”) belong to an axis with unit “l”, they are in the same stackGroup (also “l”) and added to one collection that maps to the yAxis with Id “l”. If I understand your assumption correctly, I addressed it with only adding one stackGroup per collection, but having two collections in total, each mapping to their own axis. So I think the assumption might not be correct. In the example you can see, that series of the “l” collection overlap the series of the “kW” collection. For context: “l” stands for liters and “kW” for kilowatts. The series are energy types which map to their respective axes as their measured units. I hope this helps understanding the example. This is basically our main use case. But of course the issue is applicable to many other use-cases.
- You must login to post comments
I found a workaround for this using series with opacity 0, which create space for the otherwise overlapped series.
My solution was adding all stacked series to every StackedColumnCollection. While this works better then any other solution we found for this issue, it still creates bugs with tooltips in our case and seems very unnecessary and inperformant, especially when dealing with a lot of series at the same time.
Description of the solution:
– Create a StackedColumnCollection
for every unit (axis) in the chart, see post above
– Iterate over all series, then iterate over all Collections and add the current series to the collection (this leads to all series being in all collections)
– If the Collections yAxisId is not equal to the series unit, add the series with opacity 0, and all yValues set to 0 (prevents axisRange errors). The id ist prefixed with a “Phantom” prefix, for later identification.
– Also the phantom series must be exclude from every other diagram part displaying series, e.g. the legend.
A better or built-in solution would still be much appreciated. Just wanted to post my solution for any other dev encountering the same issue đŸ™‚
- Max Geldner answered 1 month ago
- last edited 1 month ago
- You must login to post comments
Please login first to submit.