Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
`minPointLength` shifts all following values in waterfall #6087
When I use
Live demo with steps to reproduce
Use the input below the chart to quickly experiment with different
All of them, AFAICS. (I tested it in IE11, Chrome, and Firefox.)
I was hoping this ticket will get the issue resolved, but it's now supposedly fixed and the issue remains.
Thank you for reporting the issue!
That will be fixed of course. Previous ticket assumed values are noticeable smaller.
I am open for a suggestions here. Minimum point length is applied for all points when height is lower than a set value. Of course, it will increate the last point - instead I suggest to use
In my opinion setting to high
My original zero-adjustments demo was misleading, because the data labels were obscuring the main point of the
Thanks for your feedback!
Then how about this use-case: http://jsfiddle.net/1qu32g9n/5/ - all values are positive, and moving column to the bottom doesn't make sense, right?
Isn't better to use
This mock demo shows how I'd expect the zero-adjustments waterfall to look. This mock demo shows how I'd expect your one-percent-adjustments to look. And these two show pretty much how I'd expect those charts to look if
Tooltips don't really come into it anywhere. The problem is that ATM setting
Thank you for the explanation. And my apologies for a delay.
There is one problem with a solution you propose. For example this demo: http://jsfiddle.net/1qu32g9n/8/ - the first point will rendered below zero which is certainly a a misleading representation.
I am worried, that one way or another, we will break data integrity anyway - that's what
We can change that, but it will break the idea in the waterfall chart: shouldn't every point start at a position when previous ends? Just to be on the same page: of course you are right, the current solution is not a perfect one as the last (sum) column may be very misleading in a certain cases.
My point with
That's not what I proposed though, I proposed for each column to start where computed from the data and then be prolonged in the direction it's "pointing". IMO that's exactly the impact to be expected from the
First and foremost, the chart should correctly represent the data. What you describe is an invariant of the waterfall data. It doesn't mean that keeping this invariant in the visualization should take precedence over keeping it consistent with the data.
I disagree. This issue points out a bug in waterfall rendering -
I don't see though, how the functionality I propose above is much different from how