<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-3" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Maciej Sieczka wrote:
<blockquote cite="mid:46D44BA4.5010901@o2.pl" type="cite">
<pre wrap="">Luigi Ponti wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Maciej Sieczka wrote:
</pre>
</blockquote>
<!----><br>
<pre wrap="">nnbathy performs Delaunay triangulation, not Voronoi tesselation. I
(darkly) understand there is a mathematical relation between the two,
but I don't see how it could apply in your example. If this is just my
ignorance please explain more.
</pre>
</blockquote>
<br>
The Voronoi cells and Delaunay triangles are said to be 'dual' to one
another and once one is known the other is completely defined
(Sambridge et al. 1995). Natural neighbor interpolation relies on the
construction of Voronoi diagrams for determining the areas used in
computing weights. What Sakov did was to use the Triangle software to
compute the underlying Delaunay triangulation (Fan et al. 2005). Or at
least this is my understanding after a brief immersion into the
available online refs! To be true, I haven't been able to find out
where Voronoi polygons show up in the nnbathy source code.<br>
<ul>
<li>Sambridge M., Braun J., McQueen H., 1995. Geophysical
parameterization and interpolation of irregular data using natural
neighbours. Geophysical Journal International 122: 837-857. Available
at <a class="moz-txt-link-freetext" href="http://wwwrses.anu.edu.au/geodynamics/nn/SBM95/SBM.html">http://wwwrses.anu.edu.au/geodynamics/nn/SBM95/SBM.html</a></li>
<li><font size="-1"><span class="a">Fan Q., Efrat A., Koltun V.,
Krishnan S., Venkatasubramanian S., 2005. Hardware-assisted natural
neighbor interpolation. Workshop on Algorithm Engineering and
Experiments (ALENEX). Available at
<a class="moz-txt-link-abbreviated" href="http://www.cs.arizona.edu/~alon/papers/ast.ps">www.cs.arizona.edu/~alon/papers/ast.ps</a></span></font></li>
</ul>
<font size="-1"><span class="a"><br>
</span></font>
<blockquote cite="mid:46D44BA4.5010901@o2.pl" type="cite">
<pre wrap="">
Anyway - what could be done to overcome the trimming to convex hull
effect: you need to make sure that the convex hull for your input cells
covers your whole area of interest - ie. enlarge region enough for
important input cells not to be omitted. If cells in the input raster
are distributed so that a convex hull covering the whole area of
interest is not possible, you need to enhance your input raster.
</pre>
</blockquote>
<br>
OK -- got it: my input raster are weather stations, so it is going to
be hard...<br>
<br>
<blockquote cite="mid:46D44BA4.5010901@o2.pl" type="cite">
<pre wrap="">
r.to.vect -z feature=point followed by v.hull might be faster for
testing than trial and error with r.surf.nnabthy itself.
</pre>
</blockquote>
<br>
Good advice.<br>
Thanks again,<br>
Luigi<br>
<br>
<br>
</body>
</html>