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
>> non-linear 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 screen-aligned box. The
MathCanvas would also have additional methods like geodesic_to() for
rendering manifold-aware 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 non-linear 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 screen-space coordinates
only.
-Peter
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
