Re: [GRASS-user] r.proj or r.resamp.rst issues
Bulent Arikan wrote: Cubic interpolation can introduce overshoot, as can other forms of spline interpolation. Linear and nearest-neighbor interpolation don't have this issue. With r.resamp.rst, the problem can be alleviated to a degree by using higher values for the tension= parameter. Also, if your data is noisy, this will tend to exaggerate the gradients, making overshoot more likely. Filtering the data first will reduce the errors. 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. All methods of interpolation introduce artifacts; you just have to choose which sort of artifacts you prefer. Nearest-neighbour interpolation produces extreme gradients at sample points and zero gradient elswhere. Linear interpolation produces extreme curvature at sample points and zero curvature elsewhere. Too low (or even negative) values from undershoot aren't any more inaccurate than too high values from overshoot; they're just more likely to be noticed (there are several places on earth where negative altitudes would be correct). Finally, when you say use higher values for tension parameter, I guess you mean values lower than default 40. such as 30. or 20. Higher tension values cause less overshoot at the expense of greater variations in curvature. -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.proj or r.resamp.rst issues
Bulent Arikan wrote:
I am running GRASS 6.5 svn (Snow Leopard). I have several ASTER GDEMs
(Latlong, 30m res.), which I reprojected into UTM using both 'nearest' and
'cubic' methods ('r.proj'). Only in some imagery that are reprojected in
cubic, I ended up having couple of cells (literally, 1-2 cells out of 8
million in average) with minus (-) values. For example, in a DEM where the
elevation values are between 800-2600 meters, I have cell values between
-150 and -85 meters. This does not seem to be an issue in reprojected
imagery with the nearest method. I am not sure how these minus values are
introduced at the first place.
Cubic interpolation can introduce overshoot, as can other forms of
spline interpolation. Linear and nearest-neighbor interpolation don't
have this issue.
With r.resamp.rst, the problem can be alleviated to a degree by using
higher values for the tension= parameter.
Also, if your data is noisy, this will tend to exaggerate the
gradients, making overshoot more likely. Filtering the data first will
reduce the errors.
--
Glynn Clements gl...@gclements.plus.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.proj or r.resamp.rst issues
Thanks Glynn.
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.
Bulent
On Fri, May 7, 2010 at 5:08 AM, Glynn Clements gl...@gclements.plus.comwrote:
Bulent Arikan wrote:
I am running GRASS 6.5 svn (Snow Leopard). I have several ASTER GDEMs
(Latlong, 30m res.), which I reprojected into UTM using both 'nearest'
and
'cubic' methods ('r.proj'). Only in some imagery that are reprojected in
cubic, I ended up having couple of cells (literally, 1-2 cells out of 8
million in average) with minus (-) values. For example, in a DEM where
the
elevation values are between 800-2600 meters, I have cell values between
-150 and -85 meters. This does not seem to be an issue in reprojected
imagery with the nearest method. I am not sure how these minus values are
introduced at the first place.
Cubic interpolation can introduce overshoot, as can other forms of
spline interpolation. Linear and nearest-neighbor interpolation don't
have this issue.
With r.resamp.rst, the problem can be alleviated to a degree by using
higher values for the tension= parameter.
Also, if your data is noisy, this will tend to exaggerate the
gradients, making overshoot more likely. Filtering the data first will
reduce the errors.
--
Glynn Clements gl...@gclements.plus.com
--
BÜLENT ARIKAN
School of Human Evolution and Social Change
Arizona State University
Tempe - AZ
85287-2402
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.proj or r.resamp.rst issues
Hi,
I am running GRASS 6.5 svn (Snow Leopard). I have several ASTER GDEMs
(Latlong, 30m res.), which I reprojected into UTM using both 'nearest' and
'cubic' methods ('r.proj'). Only in some imagery that are reprojected in
cubic, I ended up having couple of cells (literally, 1-2 cells out of 8
million in average) with minus (-) values. For example, in a DEM where the
elevation values are between 800-2600 meters, I have cell values between
-150 and -85 meters. This does not seem to be an issue in reprojected
imagery with the nearest method. I am not sure how these minus values are
introduced at the first place.
Since I interpolate GDEMs from 30m to 10m using 'r.resamp.rst' (keeping
tension at 40.), I need to fix this problem. I thought of making negative
value cells null but this may create more problems during interpolation
(actually, I tried and r.resamp.rst could not complete interpolation). If I
take absolute values of cells to make negative cells positive, then I
introduce cells with unrealistic elevation data. It seems like after
interpolation –without any correction of negative values–, the number of
negative value cells do not increase, they are still less than 1% of total
cells.
I will appreciate any suggestions why cubic method produces negative values
in some imagery and how to fix this before or after interpolation.
* I did not try changing default r.resamp.rst values, such as tension,
because most of the imagery I interpolated have very accurate results; the
elevation difference between interpolated (10m res) and original (30m res)
is around 1 meter.
Thank you for your comments.
--
BÜLENT ARIKAN
School of Human Evolution and Social Change
Arizona State University
Tempe - AZ
85287-2402
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.proj and r.resamp.rst issues -2
Hi, I might have found a solution to my problem, which I shared with you earlier today. I am writing about it in case someone else has a similar issue and this may be a way of solving the problem. However, I am not certain if this is the easiest or the most practical way of getting the results. The problem was the presence of few negative value cells in 'cubic' reprojected DEMs (from Latlong to UTM). I ran r.mapcalc to make these negative cells NULLs. Then, I ran 'r.fillnulls' in that part of the DEM and patched the 'filled' map with the original map (the one that has NULLs). Finally, I interpolated the resultant (i.e., patched) imagery from 30m to 10m. The values in 10m DEM look accurate and free of negative value cells. If you know another way of doing it and share with me, I will greatly appreciate. -- BÜLENT ARIKAN School of Human Evolution and Social Change Arizona State University Tempe - AZ 85287-2402 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
