[GRASS-user] v.surf.rst question

Bulent_Arikan · March 23, 2011, 3:18pm

Dear List,

I have 30m ASTER DEM from a region (UTM-37) which I am trying to interpolate using ’ v.surf.rst ’ to obtain 10m resolution DEMs. I prefer this module since I will also need additional maps such as slope, aspect, prof curv, etc. I will try describing my problem below and I will appreciate any suggestions/ideas. Since the original 30m res. image covers a large area, I cropped it into several tiles using ‘r.mapcalc’. Each tile has about 12 million cells in 30m res. and 115 million cells in 10m res. and takes an average of 4 hrs to complete one run of v.surf.rst. I sample each tile using ‘r.random’ at 50%. Then I change the region settings in ‘g.region’: I align region to resolution and set the resolution to 10m before running v.surf.rst. I ran the module at different tension settings (55., 40., 25. and 10.) while keeping smoothing parameter (.1) and other parameters at default settings. When I add legend to my 10m DEM from the toolbar in Map Display, the elevation range is usually a couple meters above or below the original map. After each run, I set my region resolution back to 30m, and using r.mapcalc, I prepare a “difference” map [ (30m DEM) - (10m DEM) ]. In this map, I get extremely high and low values (i.e., the range in the difference map can be -70 to 183 suggesting to me that there is both over- and undershooting), which seem to be limited to mountain tops and some canyons. When I run ‘r.report’, I can see that actually these “extreme” values are limited to very few cells (about 3-5% of 12 million cells) and the main variation for 95% of cells is within more reasonable range such as +/- 3 meters. I recently became aware of some accuracy issues related to ASTER DEMs especially in mountainous areas however, I have the same issue for flat parts of this landscape as well.

My question is: How can I fix the issue of having these few cells with extreme values?

I am thinking that:

I may be having this problem because I am trying to interpolate images that are too large (crop tiles of smaller areas?),
I may be able to fix the negative cells by making them NULL and then using ’ r.fill.nulls’ module but even if this is advisable, I do not know of a solution for higher than normal value cells.

Again, I appreciate your ideas and suggestions. Thank you,

–
BÜLENT

Micha_Silver · March 24, 2011, 6:39am

Dear List,

I have 30m ASTER DEM from a region (UTM-37) which I am trying to interpolate using ’ v.surf.rst ’ to obtain 10m resolution DEMs. I prefer this module since I will also need

If you’re starting with an ASTER DEM (GTiff?) then don’t you want to be using r.resamp.rst to interpolate to a higher resolution ?? This module creates, on the way, slope, aspect, curves, etc.
Also, one additional point the bears mentioning. If you simply change the resolution to 10m then use r.mapcalc to make a new copy of the original DEM, it will have the newer resolution. This method doesn’t do any sophisticated interpolation, just calculates new values for higher res cells by (I think) nearest neighbor. But since you’re dealing from the start with the ASTER data, which might have anomalies anyway, maybe this approach might be good enough. It will certainly be much faster to run r.mapcalc at higher res than to do an interpolation.
Might be worth to cut out a small mountainous region and try both r.mapcalc and r.resamp.rst then compare them…

Please post whatever you decide to do in the end.

(attachments)

···

–

Hevra Logo

Micha Silver

Arava Development Co

052-3666918

http://www.surfaces.co.il

Bulent_Arikan · March 24, 2011, 3:34pm

Hi Micha
Thanks for answering. Before I go on, I should also mention that I tried your suggestion on blocking the ocean from DEMs during interpolation. It worked! About this issue: I am becoming more and more aware of the problems with ASTER DEMs however this was the only free 30m res imagery I was able to find. At closer inspection, I see that the imagery I downloaded has some strange “crater-like” formations close to mountain peaks, which become apparent in a shaded relief map.

I think it would be very practical, as you suggested, to use r.mapcalc and copying the 30m res crop, after setting the new res to 10m. However, I am aiming to get a very accurate landscape at the end of this painful process in order to run some erosion models. From my inspection of 30m and 10m interpolated imagery, mountains seem to be the main source of problem during the interpolation. Then again, if the original data has accuracy issues, I am not sure how much I will succeed in this. I will try r.resamp.rst but it will not be until middle of the next week since I have to start a different project today. I will post my results. Thank you for sharing your ideas.

Bulent

On Wed, Mar 23, 2011 at 11:39 PM, Micha Silver <micha@arava.co.il> wrote:

On 23/03/2011 17:18, Bulent Arikan wrote:

Dear List,

I have 30m ASTER DEM from a region (UTM-37) which I am trying to interpolate using ’ v.surf.rst ’ to obtain 10m resolution DEMs. I prefer this module since I will also need

If you’re starting with an ASTER DEM (GTiff?) then don’t you want to be using r.resamp.rst to interpolate to a higher resolution ?? This module creates, on the way, slope, aspect, curves, etc.
Also, one additional point the bears mentioning. If you simply change the resolution to 10m then use r.mapcalc to make a new copy of the original DEM, it will have the newer resolution. This method doesn’t do any sophisticated interpolation, just calculates new values for higher res cells by (I think) nearest neighbor. But since you’re dealing from the start with the ASTER data, which might have anomalies anyway, maybe this approach might be good enough. It will certainly be much faster to run r.mapcalc at higher res than to do an interpolation.
Might be worth to cut out a small mountainous region and try both r.mapcalc and r.resamp.rst then compare them…

Please post whatever you decide to do in the end.
additional maps such as slope, aspect, prof curv, etc. I will try describing my problem below and I will appreciate any suggestions/ideas. Since the original 30m res. image covers a large area, I cropped it into several tiles using ‘r.mapcalc’. Each tile has about 12 million cells in 30m res. and 115 million cells in 10m res. and takes an average of 4 hrs to complete one run of v.surf.rst. I sample each tile using ‘r.random’ at 50%. Then I change the region settings in ‘g.region’: I align region to resolution and set the resolution to 10m before running v.surf.rst. I ran the module at different tension settings (55., 40., 25. and 10.) while keeping smoothing parameter (.1) and other parameters at default settings. When I add legend to my 10m DEM from the toolbar in Map Display, the elevation range is usually a couple meters above or below the original map. After each run, I set my region resolution back to 30m, and using r.mapcalc, I prepare a “difference” map [ (30m DEM) - (10m DEM) ]. In this map, I get extremely high and low values (i.e., the range in the difference map can be -70 to 183 suggesting to me that there is both over- and undershooting), which seem to be limited to mountain tops and some canyons. When I run ‘r.report’, I can see that actually these “extreme” values are limited to very few cells (about 3-5% of 12 million cells) and the main variation for 95% of cells is within more reasonable range such as +/- 3 meters. I recently became aware of some accuracy issues related to ASTER DEMs especially in mountainous areas however, I have the same issue for flat parts of this landscape as well.

My question is: How can I fix the issue of having these few cells with extreme values?

I am thinking that:

I may be having this problem because I am trying to interpolate images that are too large (crop tiles of smaller areas?),

I may be able to fix the negative cells by making them NULL and then using ’ r.fill.nulls’ module but even if this is advisable, I do not know of a solution for higher than normal value cells.

Again, I appreciate your ideas and suggestions. Thank you,

–
BÜLENT

This mail was received via Mail-SeCure System.
_______________________________________________
grass-user mailing list
[grass-user@lists.osgeo.org](mailto:grass-user@lists.osgeo.org)
[http://lists.osgeo.org/mailman/listinfo/grass-user](http://lists.osgeo.org/mailman/listinfo/grass-user)

This mail was received via Mail-SeCure System.
–

Micha Silver

Arava Development Co

052-3666918

http://www.surfaces.co.il

–