NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Thanks Bill, it works! As for my data being weird, well<grin>, it doesn't seem it to me! It consists of measurements that are taken over as close to a perfect grid as possible, but likely rotated and certainly with many gaps and offsets due to physical obstructions in the field. As for the larger sizes, I was enjoying Curtis's DelaunayFast until I started getting triangulation errors. I worry when you mention that co-linear points cause problems, because almost all of my data is similarly co-linear, although often not orthogonal to the axes. That invites my implementing my own triangulation and using a CustomDelaunay that exploits this co-linear tendency, but that doesn't seem trivial even in my near-gridded cases, and I still have to support the general case. I was hoping that in the medium-term I could use well-known algorithms _that_work_ even if they're imperfect: I'm not terribly fussy how equilateral my triangles are, but I do care that the coverage is complete and non-overlapping so that interpolation can work. Can none of the Delaunay algorithms guarantee this? And Curtis, thanks for the DelaunayFast. Unfortunately, I'm getting a fair number of "Delaunay.finish_triang: error in triangulation!" exceptions. But fortunately it's fast enough that I can always try it first! My apologies for the large attachment, I just never succeeded in reproducing the problem with a smaller dataset. It's just as well that it didn't make it to the list. I guess I should've written the data in binary form instead of ascii. Thanks again for your help! Ian
visad archives: