Ian Thomas wrote:
Chris Barker wrote:
I think it would be great to have in MPL.
What code are you using for the triangulation? Does it do constrained
My code only does the contouring; you have to input the triangulation.
In the examples included with the code I used matplotlib.delaunay to
do the triangulations so as not to reinvent the wheel.
To include it in MPL, I would need to improve it somewhat (there are a
couple of known bugs and insufficient documentation) and there would
need to be a discussion of the API. At the moment I am using
tricontour(x, y, triangulation_indices, z, optional_mask)
followed by the usual contour args (N or V) and kwargs. Is this OK?
I've also written utility plotting functions triplot, trifill and
tripcolor; are these wanted?
In terms of implementation, at the python level I have a TriContourSet
class which is the same as the existing ContourSet apart from a few
lines that deal with input arguments and calling the appropriate
underlying C++ code. Ideally it would be sensible to refactor the
common python code into a new class (BaseContourSet?) and have
relatively thin derived ContourSet and TriContourSet classes. But I'm
not sure you'd like a relatively new mpl contributor to change such
As the person who fixed major bugs in cntr.c, you have wizard status, so go ahead! I have no objection to some refactoring, so long as everything works in the end, and is no more difficult to read and maintain than what is there now--which I am sure could be improved even without the Tri additions.
What sort of timeline do you have in mind?
One possibility would be to develop the tri* functionality at least initially as a module in lib/mpl_toolkits, like axes_grid and mplot3d; or in a module in lib/matplotlib. This could still take advantage of refactoring in contour.py. An advantage is that it would consolidate the triangle functionality so it would be easier to find, track, and document.
I copied this reply to the devel list--let's continue there as needed.