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

GRASS GRASS user
1

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

2

On Tue, May 11, 2004 at 03:46:01PM -2300, tatel@euskalnet.net wrote:

Hi Markus and all subscribers,

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

A few days ago the LatLong bug in RST has been solved.
It was "just" an integer variable which should have been double.
Fixed for 5.3 and 5.7.

r.fillnulls worked fine for me *in* a Lat-Lon location.

It worked sometimes, but not always - depending on the hole shape
and diameter.

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)

Since the problem is solved, please try the current GRASS.

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)'

Strange. I'll look into this.

It is easy to get better results by merging srtm30 data at correct
resolution.

In case srtm30 data are available .... (only US AFAIK).

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.

I think I still have to upload a change to r.fillnulls to follow
the latest changes in s.surf.rst (v.surf.rst in 5.7).

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

Markus