Contour Plotting of Varied Data on a Shape

Community matplotlib-users
1

Ian Thomas wrote:

To summarise, you recommend the following units of functionality:

1) Triangulation class to wrap existing delaunay code.

The idea here is that it would provide a class that holds the result of the triangulation. Yes, it would use the existing delaunay code by default, and hopefully optionally use the not-as-good-a-license code the Robert Kern put in SciPy. In the future, I hope we can find a robust and well-licensed code -- I may be able to release some in-house code of ours for that some day.

2) Separate the storage of and creation of contour sets so that you
can create your own.
3) tricontour and tricontourf functions to contour a Triangulation.
4) Python utility plotting functions for a Triangulation (triplot,
tripcolor, etc).
5) Simple wrappers for 3 and 4 so you can just pass in the points and
the Triangulation is created for you behind the scenes.

yup -- that all sounds great!

I am happy to make a start with this;

wonderful!

no doubt it will take me a while. I should point out that I don't intend

> to tinker with the

delaunay code, so we'll still left with those pathological cases
that it doesn't work with. Maybe this can be revisited when I'm done.

hopefully, there still doesn't appear to be a really good delaunay code with a flexible license out there -- pity.

Do you want it all in one go, or one unit of functionality at a time
(my preference)?

I don't see any reason to add it piecemeal, as long as the pieces are useful by themselves.

Let's see! I'll hold off starting until there have been some votes
for it from other people.

hmm -- I wonder if a post to matplotlib-devel is in order. Most of those folks are on this list, to, but may not be following this thread.

By the way, it sounds like your contouring code is in C++ -- is that important? I don't expect it should be that computationally expensive, though maybe hard to vectorize -- C++ does make portability harder, though there's a bunch in MPL already. If I was starting from scratch, I'd use Cython, if pure Python didn't cut it.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...259...

2

I did what now?

···

On 2010-03-11 13:38 PM, Chris Barker wrote:

Ian Thomas wrote:

To summarise, you recommend the following units of functionality:

1) Triangulation class to wrap existing delaunay code.

The idea here is that it would provide a class that holds the result of
the triangulation. Yes, it would use the existing delaunay code by
default, and hopefully optionally use the not-as-good-a-license code the
Robert Kern put in SciPy.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

3

Robert Kern wrote:

the triangulation. Yes, it would use the existing delaunay code by
default, and hopefully optionally use the not-as-good-a-license code the
Robert Kern put in SciPy.

I did what now?

I thought you'd put a wrapper of a delaunay code that is GPL'd or something (not BSD compatible anyway) into a scikit or something? optional -- so it doesn't screw up licensing for those that don't want it.

Anyway, the point is, for any code that might be put into MPL, we want a properly licensed compatible default, but ideally with the option of easily plug in in other, better, delaunay code that may not be license compatible.

Now that I've written this, I really should go and look and see if I remember correctly:

I've found this:

http://scikits.appspot.com/delaunay

Though I see no reference to license in there, so I presume it's under the same license as scipy.

So I guess I was thinking of the natgrid toolkit, which I guess is not Robert's work, and is a substitute for nn interpolation, not triangulation.

Sorry for writing too quickly.

While I've got your attention, though -- I suspect you have looked for license compatible delaunay code and the stuff in the scikits package is as good as it gets?

Thanks,
   -Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...259...

4

Robert Kern wrote:

the triangulation. Yes, it would use the existing delaunay code by
default, and hopefully optionally use the not-as-good-a-license code the
Robert Kern put in SciPy.

I did what now?

I thought you'd put a wrapper of a delaunay code that is GPL'd or
something (not BSD compatible anyway) into a scikit or something?
optional -- so it doesn't screw up licensing for those that don't want it.

Anyway, the point is, for any code that might be put into MPL, we want a
properly licensed compatible default, but ideally with the option of
easily plug in in other, better, delaunay code that may not be license
compatible.

Now that I've written this, I really should go and look and see if I
remember correctly:

I've found this:

http://scikits.appspot.com/delaunay

Though I see no reference to license in there, so I presume it's under
the same license as scipy.

So I guess I was thinking of the natgrid toolkit, which I guess is not
Robert's work, and is a substitute for nn interpolation, not triangulation.

Sorry for writing too quickly.

Instead of addressing the misconceptions point by point, let me just lay out the situation:

natgrid is a GPLed library for doing Delaunay triangulation and natural neighbor interpolation. The author is presumed to be deceased, so this code will always be GPLed. It seems to fail less often when doing the Delaunay triangulation on datasets in the wild; however, it is not using robust geometric primitives, so there probably still are cases where it fails.

I wrote a BSD library for doing natural neighbor interpolation using the Delaunay triangulation code using the sweepline algorithm. This algorithm does not (and cannot) use robust geometric primitives, so there are datasets for which it fails to produce a valid triangulation. This is the code in scikits.delaunay. I have not pushed it to a 1.0 release because of this issue. However, this *was* put into matplotlib. matplotlib can optionally use natgrid if it is installed.

While I've got your attention, though -- I suspect you have looked for
license compatible delaunay code and the stuff in the scikits package is
as good as it gets?

Pretty much. I do have some code for constructing the Delaunay triangulation using robust primitives and an insertion algorithm, but it is an order of magnitude slower than scikits.delaunay. Ideally, we would be able to find or write a divide-and-conquer algorithm using Jon Shewchuk's robust geometric primitives.

···

On 2010-03-11 15:49 PM, Chris Barker wrote:

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

5

Chris Barker wrote:

hmm -- I wonder if a post to matplotlib-devel is in order. Most of those
folks are on this list, to, but may not be following this thread.

I'll post to matplotlib-devel shortly and see what response I get.

By the way, it sounds like your contouring code is in C++ -- is that
important?

Yes, it is C++ and it is important - that's what I've got and hence
that's what I'm offering! Portability should be fine as I'm only
using some of the basic STL containers which are already used by, for
example, the matplotlib delaunay code.

Ian