From: Peter Wang <pwang@en...>  20070913 16:24:18

On Sep 12, 2007, at 3:27 PM, Paul Kienzle wrote: >> Extensibilty: >> >> We would like to make it fairly easy for users to add additional >> nonlinear transformations. The current framework requires >> adding a >> new function at the C++ layer, and hacking into axes.py to support >> additional functions. We would like the existing nonlinear >> transformations (log and polar) to be part of a general >> infrastructure where users could supply their own nonlinear >> functions which map (possibly nonseparable) (xhat, yhat) > >> separable (x, y). There are two parts to this: one pretty easy and >> one pretty hard. >> >> The easy part is supporting a transformation which has a separation >> callable that takes, eg an Nx2 array and returns and Nx2 array. >> For >> log, this will simply be log(XY), for polar, it will be >> r*cos(X[:,0]), r*sin(X[:,1]). Presumably we will want to take >> advantage of masked arrays to support invalid transformations, eg >> log of nonpositive data. >> >> The harder part is to support axis, tick and label layout >> generically. Currently we do this by special casing log and polar, >> either with special tick locators and formatters (log) or special >> derived Axes (polar). > > Another hard part is grids. More generally, a straight line in > x,y becomes curved in x',y'. Ideally, a sequence of points plotted > on a straight line should lie directly on the transformed line. This > would make the caps on the polar_bar demo follow the arcs of the grid. > > The extreme case is map projections, where for some projections, a > straight line will not even be connected. Just wanted to chime in because I've done some thinking on this problem for Chaco. Right now chaco's coordinate transformation process ("mapping") is handled by explicit objects that subclass from 1D and 2D mapper base classes. We're talking about moving to a scheme where the DisplayPDF GraphicsContext is extended into a MathematicalCanvas that is both aware of the transformation stack and is also aware of "screen" properties such as subpixel alignment and such. You would then be able to hand off dataspace coordinates to methods like move_to(), line_to(), rect(), etc., so you could move_to () a dataspace coordinate and then draw a screenaligned box. The MathCanvas would also have additional methods like geodesic_to() for rendering manifoldaware grids and axes. (Of course, grids aren't necessary geodesics all the time.) I don't know if discontinuous map projections could be handled cleanly in such a framework, without the renderer querying the canvas about screenspace limits of the current transformation. > Another issue is zooming and panning. For amusement, try it with > polar_demo. Yes, one of the problems with nonlinear transformations is that panning is very much a screen space interaction, and you have to map it back into data space to do proper data clipping and transformation. Unfortunately (and this is a problem even with logarithmic plots), the user may sometimes want to view things on the screen that are outside the valid domain of the coordinate transform, in which case the code handling the interaction (the "tool", in chaco parlance) has to be smart enough to maintain screenspace coordinates only. Peter 