gauravkumar13337 / flot

Automatically exported from code.google.com/p/flot
MIT License
0 stars 0 forks source link

bottom of bar will allways default to 0 #177

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
I'm working with flot 0.5 and Firefox3.0.11 on a Mac. I'm developing an
application that will plot a series of bars, they will represent the max
and min points on seismic waveform. The problem I have is that the bottom
of the bars will default to 0 all the time. The submitted data is like this
[time,max,min]. 
    var d2 = [[0, 3, -2], 
              [4, 8, 5], 
              [8, 15, -3], 
              [9, 13, -20]];
If I plot this with:
    $.plot($("#placeholder"), [$
        {$
            data: d2,$
            bars:  {show:true, barWidth:1, align:'center'}$
        }$
    ]);$
I will get a table and all the bars will end at 0. Look at Picture 5.png
First we do minor modification to flot so the third value of the 3-tuple is
evaluated at the time the range is evaluated. Inside 

function processData()
...
 var x = data[j][0], y = data[j][1], z = data[j][2];
...
if ( typeof(z) != "undefined" ) {
                        if (z != null && !isNaN(z = +z)) {
                            if (z < axisy.datamin)
                                axisy.datamin = z;
                            if (z > axisy.datamax)
                                axisy.datamax = z;
                        }
                        if (z == null || isNaN(z))
                            data[j] = null; // mark this point as invalid
                    }

This will include that bottom value in the automatic range only if the
third value is defined. There might be a easier way for this. Then we modify:

function drawBar(x, y, by, barLeft, barRight, offset, fill, axisx, axisy, c) {
            var drawLeft = true, drawRight = true,
                drawTop = true, drawBottom = true,
                left = x + barLeft, right = x + barRight,
                bottom = by, top = y;

            // account for negative bars
            if (top < bottom) {
                top = by;
                bottom = y;
            }
...

Then the same data will produce a plot like Picture 6.png 

In that last modification to drawBar I take into account negative bars as a
possible intention of the user and instead of defaulting to 0 I'm flipping
the values to make a successful bar. 

Can I do this plots using the options for the bars or the modification of
the source my only alternative? 

Original issue reported on code.google.com by jreyes1...@gmail.com on 23 Jun 2009 at 12:43

Attachments:

GoogleCodeExporter commented 8 years ago
You need SVN Flot for the bar bottom support. I'm going to fix the links on the 
front
page now, this is confusing too many people. You can grab it here:

  http://flot.googlecode.com/svn/trunk/

Original comment by olau%iol...@gtempaccount.com on 23 Jun 2009 at 5:14

GoogleCodeExporter commented 8 years ago
If SVN trunk doesn't fix your problem, feel free to get back to this bug, 
otherwise I
think I'll just close it.

Original comment by olau%iol...@gtempaccount.com on 23 Jun 2009 at 5:41

GoogleCodeExporter commented 8 years ago
Thank you for the prompt response. I downloaded the SVN version to my web 
application and ran a simple 
test. The bars will be produced as you can see in Picture 7.png The only 
problem will be with the automatic 
selection of the y-axis range. The bottom of the bars will not be included on 
this process. I'm including 
Picture 8.png of what I will expect the waveform to look on the plot. I 
produced the second plot with my 
modified version of flot (modification are on my first comment). I know this 
might be a very specific case, but 
it's real scientific data recorded by instruments on the field. I this works, 
we will get a lot of development on 
research applications. This is a tiny sample of the data I'm plotting. 
[1245775757.2750001, -1703.0, -1957.0], [1245775764.2750001, -1694.0, -1853.0], 
[1245775771.2750001, -1798.0, -1976.0], [1245775778.2750001, -1641.0, -1901.0],
 [1245775785.2750001, -1602.0, -1860.0], [1245775792.2750001, -1707.0, -1912.0], 
[1245775799.2750001, -1754.0, -1912.0], [1245775806.2750001, -1730.0, -1812.0], 
[1245775813.2750001, -1722.0, -1910.0], [1245775820.2750001, -1717.0, -1912.0], 
[1245775827.2750001, -1615.0, -1996.0], [1245775834.2750001, -1612.0, -1776.0], 
[1245775841.2750001, -1769.0, -1978.0], [1245775848.2750001, -1656.0, -1995.0],
 [1245775855.2750001, -1665.0, -1937.0], [1245775862.2750001, -1786.0, -1964.0], 
[1245775869.2750001, -1693.0, -1881.0], [1245775876.2750001, -1684.0, -1897.0], 
[1245775883.2750001, -1714.0, -1911.0], [1245775890.2750001, -1625.0, -1794.0], 
[1245775897.2750001, -1711.0, -1903.0], [1245775904.2750001, -1670.0, -1858.0], 
[1245775911.2750001, -1749.0, -1889.0], [1245775918.2750001, -1688.0, -1858.0],
[1245775925.2750001, -1701.0, -1928.0], [1245775932.2750001, -1753.0, -1934.0], 
[1245775939.2750001, -1707.0, -1881.0], [1245775946.2750001, -1718.0, -1839.0], 
[1245775953.2750001, -1736.0, -1870.0], [1245775960.2750001, -1646.0, -1854.0], 
[1245775967.2750001, -1702.0, -2025.0], [1245775974.2750001, -1638.0, -1895.0], 
[1245775981.2750001, -1653.0, -1996.0], [1245775988.2750001, -1638.0, -2020.0], 
[1245775995.2750001, -1676.0, -1938.0], [1245776002.2750001, -1736.0, -1945.0], 
[1245776009.2750001, -1610.0, -1901.0], [1245776016.2750001, -1765.0, -1908.0], 
[1245776023.2750001, -1680.0, -1860.0], [1245776030.2750001, -1754.0, -1899.0], 
[1245776037.2750001, -1687.0, -1841.0], [1245776044.2750001, -1719.0, -1935.0], 
[1245776051.2750001, -1689.0, -1937.0], [1245776058.2750001, -1739.0, -1983.0], 
[1245776065.2750001, -1706.0, -1885.0], [1245776072.2750001, -1676.0, -1925.0]

Thanks. 

Original comment by jreyes1...@gmail.com on 23 Jun 2009 at 6:53

Attachments:

GoogleCodeExporter commented 8 years ago
Yes, it's certainly a problem with the current code. I need to generalize the 
data
processing step a bit, fixing that would also fix this. Stick with your change 
for
now, and I'll see if I can find a way to make it work better.

Original comment by olau%iol...@gtempaccount.com on 24 Jun 2009 at 9:33

GoogleCodeExporter commented 8 years ago
Any progress on this data processing step? I am running into the same problem. 
I am
replicating the OP functions, but this _does_ seem like hack.

Original comment by robertln...@gmail.com on 2 Dec 2009 at 11:43

GoogleCodeExporter commented 8 years ago
Aha - my bad. I grabbed the latest source (rev 228) and all appears to be 
resolved.

Thanks!

Original comment by robertln...@gmail.com on 3 Dec 2009 at 5:08

GoogleCodeExporter commented 8 years ago

Original comment by dnsch...@gmail.com on 4 Jun 2012 at 2:52