[GRASSLIST:3396] srtm: correct big holes with r.fillnulls

[tatel at euskalnet.net]

Hi Markus and all subscribers,


Markus wrote:
>PS: It seems that you have to reproject to non-LatLong before using r.fillnulls.

r.fillnulls worked fine for me *in* a Lat-Lon location. In fact, after 
reprojecting to a not Lat-Lon location (e.g, UTM) process takes much more 
time because there are now null borders too. (I was correcting an entire 
tile)

Filled a very big hole (many Kms) and a lot of medium-little holes in 
N43W005 srtm3 tile corresponding to Picos de Europa mountains.

I found imported srtm data have NULLs set to zero so I needed to do first 
(to get r.fillnulls working as expected)

r.mapcalc srtm3=if'(srtm3==0,null(),srtm3)'



It is easy to get better results by merging srtm30 data at correct 
resolution.
 
g.region res=00:00:30 
r.to.sites -a input=srtm30 output=srtm30.sites
g.region res=00:00:03
s.to.rast input=srtm30.sites output=srtm30cells
r.mapcalc new=if'(isnull(srtm3),srtm30cells,srtm3)'

So we get a "grid" of isolated cells each 900m into the NULL zone(s). Now 
we can run 

r.fillnulls input=new output=corrected 

In this case, without srtm30 data there's a valley runing S-N which 
becomes divided in a little valley and a closed depresion. Using the 
merged srtm30 data the entire valley is correct.

s.surf.rst as invoked in r.fillnulls worked very well in (maybe not so) 
little holes but produced ugly results (segmentation) with only a 
non-NULL cell each 900 m  

I canibalized r.fillnulls and found that invoking s.surf.rst with npmin=
1000 produced some warnings but worked quite fast with much more smoothed 
segments.

Unfortunately hard disk crashed next day so still I haven't modified 
r.fillnulls. Im writing this on my old powerbook:-((

Hope this helps somebody (probably as newbie as me), and thanks to all 
who helped me in correcting srtm data.

Roman