matplotlib-devel Mailing List for matplotlib

Eric Firing wrote:
> I've only glanced so far, but one thing that caught my eye is your
> documentation changes and code regarding the need for simply-connected
> paths.  This is obsolete--mpl now handles multiply-connected paths.

Thanks for clarifying this, I now understand the 'point kinds' in
cntr.c which I originally thought were for debug purposes.  It will
make my code simpler in the end.

> A second initial suggestion is that you divide the work into two patches,
> one of which provides the refactoring of existing code (presumably only in
> contour.py), and a second which adds the new functionality.

Good idea.  I've attached the first patch which changes axes.py and
contour.py, plus adds the new example contour_manual.py.  My approach
to the refactoring is probably more of a C++ than pythonic way of
thinking with derived classes that override base class methods, but it
avoids changing much of the low level code and avoids code duplication
when tricontour is added in.

Ian

Ian Thomas wrote:
> Hello all,
> 
> Attached is a patch file against svn head to add triangular grid
> plotting and contouring.  It will need some serious checking/reviewing
> before it can be added to MPL.  I've tested it on 32 and 64-bit Linux,
> but I don't use other operating systems very often.
> 
> Most of the new code is in a new directory lib/matplotlib/tri.  There
> is a Triangulation class to store an unstructured triangular grid for
> reuse; the user can either specify the triangles or allow
> matplotlib.delaunay to create a Delaunay triangulation.  There are
> three plotting functions: triplot to plot grid lines and points,
> tripcolor to draw a pseudoplot, and tricontour/tricontourf to
> calculate and draw contour lines and filled contours.  You can either
> pass in a Triangulation object to these functions, or pass in the x,y
> points, etc and have MPL create a temporary Triangulation for you (for
> convenience).
> 
> The underlying contouring code is C++, and I've used CXX to access it.
> 
> There are some changes to axes.py and pyplot.py to expose the new
> functionality, and changes to the build scripts to build the new C++
> module.  I've also changed contour.py, splitting the previous
> ContourSet class into ContourSet and a derived QuadContourSet so there
> is separate responsibility for creating contours (QuadContourSet) and
> storage/display (ContourSet).  ContourSet allows you to specify your
> own polygons to draw, which should allow easier extension to other
> contouring algorithms.  QuadContourSet is now used by contour/contourf
> to create contour lines/polygons for a quad grid and the base class
> stores and draws them.  The benefit of this approach is that
> QuadContourSet is a relatively small class, allowing the equivalent
> triangular grid contouring class TriContourSet to be similarly small,
> and there is little code duplication.
> 
> I've added examples to demonstrate the new functionality, including
> manually creating your own contours, and also a comparison between
> griddata and tricontourf to contour unstructured grids.
> 
> Both the C++ and python are documented, but as I'm not familiar with
> the relationship between pydoc strings and sphinx, you may need to
> guide me further to increase/reduce links between and duplication of
> pydocs.
> 
> All questions and comments gratefully received.
> Ian

Ian,

I've only glanced so far, but one thing that caught my eye is your 
documentation changes and code regarding the need for simply-connected 
paths.  This is obsolete--mpl now handles multiply-connected paths.  If 
you look in cntr.c, you will find a "reorder()" function which converts 
the simply-connected paths to multiply-connected paths, which render 
better, because they don't have the cuts.  (Maybe the core routines in 
cntr.c could be modified so that the multiply-connected paths would be 
generated directly, so that reorder() would not be needed; but I find 
those routines very difficult to follow, so writing reorder() was easier.)

A second initial suggestion is that you divide the work into two 
patches, one of which provides the refactoring of existing code 
(presumably only in contour.py), and a second which adds the new 
functionality.  This would make reviewing and debugging easier.  (Your 
contour_manual.py could also go in the first patch.)

Thanks for all the good work!

Eric