[GRASSLIST:4238] GRASS 5.7.0 (2004) - v.surf.rst strange behaviour

GRASS GRASS user
1

Hi all!

I'm trying to interpolate a laser-altimeter survey in order to fill null
areas. I've mainly followed by hand the procedure contained in the script
r.fillnulls .
The problem arises after the v.surf.rst module because the resulting
elevation map is at a very first glance not correct: it looks like a ramp,
the height values increasing linearly from North to South leading to absurd
values such as 300000 meters at the bottom part...
The lidar survey is a floating point map and it has been resampled to a
3mx3m grid.

These are the steps:

1. Creating and growing a MASK for the null values

r.mapcalc temp_raster="if(isnull(LIDAR))"
r.grow in=temp_raster out=MASK

2. Vectorize the raster file: here i get a warning. Should i care?

r.to.vect -v in=LIDAR out=temp_vector feature=point
WARNING: Raster is not CELL, '-v' flag ignored, raster values will be
written to the table.

Just to verify, a simple d.what.vect gives:

map: 'temp_vector'
mapset: 'javier'
feature type: Point
field: 1
category: 221891
driver: dbf
database: /grassdata/tovel_utm32/javier/dbf
table: temp_vector
key column: cat
cat : 221891
value : 1461.560059

3. Interpolate the points with RST

v.surf.rst in=temp_vector elev=interp_raster

4. View results. This is the history file for interp_raster(note zmin and
zmax)

Tue Aug 24 16:25:01 2004
interp_raster
javier
javier
raster
vector file temp_vector
generated by v.surf.rst
tension=40.000000, smoothing=0.100000
dnorm=96.007102, dmin=1.500000, zmult=1.000000
segmax=40, npmin=200, rmsdevi=1.734224
zmin_data=1.000000, zmax_data=324402.000000
zmin_int=-9.806899, zmax_int=324404.267325

Any ideas?
Thanks in advance

Javier Yebrin

2

Hello

On Tue, 24 Aug 2004, Javier A. Yebrin wrote:

Hi all!

I'm trying to interpolate a laser-altimeter survey in order to fill null
areas. I've mainly followed by hand the procedure contained in the script
r.fillnulls .
The problem arises after the v.surf.rst module because the resulting
elevation map is at a very first glance not correct: it looks like a ramp,
the height values increasing linearly from North to South leading to absurd
values such as 300000 meters at the bottom part...
The lidar survey is a floating point map and it has been resampled to a
3mx3m grid.

These are the steps:

1. Creating and growing a MASK for the null values

r.mapcalc temp_raster="if(isnull(LIDAR))"
r.grow in=temp_raster out=MASK

2. Vectorize the raster file: here i get a warning. Should i care?

r.to.vect -v in=LIDAR out=temp_vector feature=point
WARNING: Raster is not CELL, '-v' flag ignored, raster values will be
written to the table.

I'm not sure if it's really necessary to do all those steps (vectorising etc.). If you run r.resamp.rst specifying the resolution to be the same as the current resolution, it should create a raster covering the current region but with the null areas filled in. You could then use it directly or use it to patch in the holes in the original raster. Perhaps it might be slow though; maybe that is the point in growing the MASK.

The steps would be something like:
g.region -p
*check what current ns and ew resolution are and use these in next step*
r.resamp.rst input=LIDAR ns=xx ew=xx elev=temp_smoothed
Use temp_smoothed as is or if you want the output to contain exactly the same values as the input in the non-null areas then just patch it in:
r.patch input=LIDAR,temp_smoothed output=interp_raster

Does this work?

Paul