Thanks Glynn. <div><br></div><div>That makes sense now. I did not know about the inherent problem of overshooting in cubic interpolation. ASTER DEMs I have seem to be pretty consistent in terms of data ranges and representation of values (based on r.report), so I am not sure about the noise effect in my case. However, does this mean that I am sort of out of "corrective" options if I want to use cubic reprojection of imagery from Latlong to UTM? I mean I either use nearest method for error-free reprojection or I have to be careful about the results of cubic method. Finally, when you say "use higher values for tension parameter", I guess you mean values lower than default 40. such as 30. or 20.</div>
<div><br></div><div>Bulent<br><br><div class="gmail_quote">On Fri, May 7, 2010 at 5:08 AM, Glynn Clements <span dir="ltr"><<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
Bulent Arikan wrote:<br>
<br>
> I am running GRASS 6.5 svn (Snow Leopard). I have several ASTER GDEMs<br>
> (Latlong, 30m res.), which I reprojected into UTM using both 'nearest' and<br>
> 'cubic' methods ('r.proj'). Only in some imagery that are reprojected in<br>
> cubic, I ended up having couple of cells (literally, 1-2 cells out of 8<br>
> million in average) with minus (-) values. For example, in a DEM where the<br>
> elevation values are between 800-2600 meters, I have cell values between<br>
> -150 and -85 meters. This does not seem to be an issue in reprojected<br>
> imagery with the nearest method. I am not sure how these minus values are<br>
> introduced at the first place.<br>
<br>
</div>Cubic interpolation can introduce overshoot, as can other forms of<br>
spline interpolation. Linear and nearest-neighbor interpolation don't<br>
have this issue.<br>
<br>
With r.resamp.rst, the problem can be alleviated to a degree by using<br>
higher values for the tension= parameter.<br>
<br>
Also, if your data is noisy, this will tend to exaggerate the<br>
gradients, making overshoot more likely. Filtering the data first will<br>
reduce the errors.<br>
<font color="#888888"><br>
--<br>
Glynn Clements <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>><br>
</font></blockquote></div><br><br clear="all"><br>-- <br>BÜLENT ARIKAN<br>School of Human Evolution and Social Change<br>Arizona State University<br>Tempe - AZ<br>85287-2402<br>
</div>