[cc'ing bokeh mailing list]
Actually the annular case is interesting because how we handle this is quite a deep problem.
Yes, that's what I said. 
Polar is one special case of a generic problem.
I think patch and patches are already handled by checking to see if the data is an array, then taking the min/max over the array. One approach to this in general is to compute a bounding box for every element and use those to determine the data range. Since we are going to have to do this anyway, to use rtree.js for fast hit testing of selections, it might not be a bad idea to go this route. There is a question of how to handle things when a radius or length is given in screen units and not data units.
For polar, however, we can also punt and add polar grids and axes and ranges. Actually this is not so much of a punt because we need to be able to do categorical axes and other non-cartesian axes sooner rather than later.
We should definitely add polar grids and ranges, probably even in 0.4.
Bryan
···
On Nov 9, 2013, at 2:05 PM, Peter Wang <[email protected]> wrote:
On Nov 9, 2013 1:02 PM, "Bryan Van de Ven" <[email protected]> wrote:
Oh, I realized what the problem is.Right now the data range is very naive. It bases its computed range on some x,y, coordinates but it does not take anything else into account. Like for instance the radius for annular wedges. So in the jsmerge branch where my "fix" is, this code works but the range is set to [-1, 1]. That is the special case put in to handle the "every thing is zero" situation. But annular wedges can have a much larger extent than just their (x,y) center coordinate.
Do you have any ideas for an elegant or simple way to handle this in general? It's not a big problem (probably) for "point" type markers, but anything what might render away from its "anchor" point like annular wedge does will have an issue currently. I will try to think about it, but it seems like any solution is going to be a bit ugly.
Bryan
On Nov 9, 2013, at 7:20 AM, Peter Wang <[email protected]> wrote:
> This code example does not work, because annular_wedges does not like it when X and Y are just arrays of zeros. I suspect this has to do with data range logic somewhere in the JS (in fact, it crashed the browser when I try to open the JS console). Perhaps there is also some magical handling of the "x" and "y" data series. I have no idea. But the following code does not work:
>
> import numpy as np
> from numpy import pi, cos, sin, linspace
> from bokeh.plotting import *
>
> colors = ("#A6CEE3", "#1F78B4", "#B2DF8A")
> N = 18
> r_base = 8
> theta = linspace(0, 2*pi, N)
> r_x = linspace(0, 6*pi, N-1)
> rmin = r_base - cos(r_x) - 1
> rmax = r_base + sin(r_x) + 1
>
> output_file("wedgesexample.html")
>
> x = np.zeros_like(rmin)
> y = x
> x2 = np.arange(N-1)
> y2 = np.zeros_like(x2)
>
> y3 = np.arange(N-1)
> annular_wedge(x, y,
> rmin, rmax, theta[:-1], theta[1:],
> inner_radius_units="data",
> outer_radius_units="data",
> color = colors[0], tools="pan,zoom,resize")
> show()
>
>
> Now, if you replace x and y with x2, y2, it *still* does not work. If you then replace y2 with y3, then it works. This is really goofy. Note, the glyphs.py file-based and server-based examples work just fine.
>
> This highlights a weakness in our testing, because ALL the examples work great but this case does not.
>
> Also note: this is *just* a special case with arrays of all 0. If I change x to np.ones_like(min), and set y=x, then it works just fine. What is going on?
>
>
>