[GRASS-user] r.denoise segfaults on a raster of 1166468401 cells
nik at nikosalexandris.net
Wed Dec 19 21:35:23 PST 2012
> > > 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?
> > 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.
> 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.
More information about the grass-user