Zooming in on x axis but not y axis about bokeh HOT 13 CLOSED

Tools like "xpan" and "ypan" and "xwheel_zoom" and "ywheel_zoom" have been added to constrain panning and zooming to a single axis.

from bokeh.

@paddymul we had talked about this.. is it implemented, or can you give Julia some pointers?

from bokeh.

it's not implemented, do you think we should do it on the mousewheel zoom, or make this a Box zoom thing? most of the implementation would need to be in the bokehjs repo, under tools.coffee, so you can have a look there, then we would also have to modify the python to output the necessary json

from bokeh.

@jvns ignore my last comment, I was confused.

To implement single-axis scrolling you are going to need to modify https://github.com/ContinuumIO/Bokeh/blob/master/subtree/bokehjs/static/coffee/tools.coffee

As the simplest thing possible, I would implement a class that is a peer to PanToolView that only works on a single axis. Maybe name it XPanToolView , you will need to create the related models also. That should show you how the PanTool works. That will also be enough if you want plots to always only be pannable on a single axis.

I think in the end we are going to want a "panned_axis" attribute on the PanTool model, the PanToolView should check the axis flag of its model and pan appropriately. Maybe it would be easier for you to implement it that way?

from bokeh.

I think constraining pan to a single axis should be an attribute on the PanTool, since its unconstrained behavior is just a superposition (or simple composition) of panning on each axis independently. Making a separate PanTool that only works in X or Y will probably lead to needless code duplication.

For box vs. range zoom (and selection), I think it's more of a toss-up. Creating separate RangeZoom/RangeSelect and BoxZoom/BoxSelect makes sense in that case, since rendering behavior is somewhat different.

Hugo, we need to have constrained mousewheel zoom as well.

from bokeh.

@pzwang, you mean X only or Y only mousewheel zoom? if so, then that would probably be the easiest place for @jvns to get started, add a property to the zoom tool model, which dictates which dimensions it's zooming in, modify the view to respect that, and modify the python api to pass that parameter in

at the moment, zoom/select tools don't have any rendering on it's own. the zoom sets the datarange, and then the plot renders on it's own. the select tool doesn't actually render anything visually, the scatter renderer knows how to render selected data, and there is a box select overlay that renders the rectangular selection region.

should we move the the box select overlay and put that functionality into the tool? I can't think of any scenarios where you would not want to display the box on box select tools.

from bokeh.

When I have done this in the past I decoupled it this way:

I had a generic box selection tool that drew a box selection area (options for corner or center control points, axis fixing, aspect preserving or not, etc). This tool reported the selections to a call back it was configured with so that it could be resused for zooming or selection or whatever. Ultimately, selections went to a selection manager, that performed selection/hit testing against the renderers. The renderers were separately configured with a policy on what to do with (un)selected data (enlarge the glyph, desaturate unselected points, cover the glyph with a transparent outline, whatever) For zooming the call back just adjusted the plot out bounds accordingly.

from bokeh.

Thought I'd chime in, though I'm new to this project. Very promising. As for this topic, I have implemented independent x- and y-axis zoom in my D3 graphs by adding a "zoom" box over the axes themselves. That way zoom would be x AND y for inside the graph region and x OR y if the mouse was over the individual axes. I really liked this and others did too.

from bokeh.

Oh, that's an interesting idea... Do you have a demo of what the overlay looks like, maybe in a jsfiddle or hosted somewhere? If we're going to show any kind of visual indicator over the axes during an interaction, I'd like to make sure it's minimally intrusive.

from bokeh.

Just made a jsfiddle example at

http://jsfiddle.net/6RQpP/6/

Unfortunately I do not currently have access to the code base where I have a nice cleaned up version of the javascript code, this is based off some older code.

from bokeh.

Ah with a scroll zoom. That does seem very nice! Can you add an issue for an enhancement to the Bokeh GitHub repo, including this jsfiddle in the ticket? I think this would be a nice (configurable) addition. However, just to note the upcoming 0.4 release in January already has much work to put in, so this would probably happen after 0.4.

Thanks,

Bryan

On Dec 3, 2013, at 10:53 AM, jgbos [email protected] wrote:

Just made a jsfiddle example at

http://jsfiddle.net/6RQpP/6/

Unfortunately I do not currently have access to the code base where I have a nice cleaned up version of the javascript code, this is based off some older code.

—
Reply to this email directly or view it on GitHub.

from bokeh.

Here is the jsfiddle: http://jsfiddle.net/6RQpP/6/

from bokeh.

Awesome! Looking forward to playing with it.

On Wednesday, April 9, 2014, Bryan Van de Ven [email protected]
wrote:

Closed #17 #17.

Reply to this email directly or view it on GitHubhttps://github.com//issues/17
.

from bokeh.