[GRASS-user] r.denoise segfaults on a raster of 1166468401 cells

[Nikos Alexandris]

Nikos:

> > > The following attempt segfaults on GRASS 6.4.3svn (nearly in the end of
> > > the process, if I am not wrong), running on Core i7 with 32GB of RAM.

> > > # mdenoise ASTER GDEM2 over Greece
> > > r.denoise in=aster_gdem2_ellas out=aster_gdem2_ellas_smoothed
> > > iterations=1
> > > threshold=0.8 epsg=2100

> > > The computational area comprises (Rows: 32401, Columns: 36001)
> > > 1166468401 cells.  Is this too much?

> > > Would (re-)running this on GRASS 7.0.svn make any difference?
> > > I should better perform the process on a per (ASTER GDEM2) tile(s)
> > > basis, shouldn't I?
 
Alexander Muriy:

> > Hi Nikos. In my experience, <mdenoise> utility works well with raster
> > sizes no more than 2000x2000 (regardless of RAM size). That's why the only 
> > way to denoise the large rasters — using of tiles and patching of final
> > results.

Nikos:

> Of course! Yet, what about differently smoothed tile borders?  Any
> additional hints?

For the records, there is a statement by John A Stevenson, "Re: [GRASS-user] 
New addon: r.denoise. Denoise topography including SRTM," e-mail on the grass-
user list on 17. 09. 2009:

--%<---
Xianfang also recommended denoising small areas, perhaps with overlap, 
and seeing how well they can be merged.
--->%--

Nikos