[GRASS-dev] Re: [GRASS-user] problems using r.proj with large data set

[Glynn Clements]

Hamish wrote:

> > > > BTW, in the course of writing r.proj.seg, I discovered that
> > > > method=bilinear was seriously broken (it had the row/column
> > > > swapped, essentially flipping each source cell along the main
> > > > diagonal). The fact that no-one noticed until now suggests that
> > > > either no-one used method=bilinear, or they didn't pay much
> > > > attention to the results.
> > > 
> > > Would this accound for banding in the output from any
> > > method=bilinear warps? I  have noticed this before, but had been
> > > told that it was an artifact in the  source data.
> > 
> > Maybe. It's most noticable if the source data is significantly coarser
> > than the destination region. E.g. re-projecting GTOPO30 DEMs (30
> > arc-seconds ~= 660m x 930m) to the default Spearfish region (30m)
> > makes it quite clear.

Results:

Before fix:	http://www.zen87603.zen.co.uk/proj-old.png
After fix:	http://www.zen87603.zen.co.uk/proj-new.png

> (I tried bilinear last week and got banding, so went back to nearest)
> 
> I've done some trials:
>   http://bambi.otago.ac.nz/hamish/grass/r.proj_methods_ORIG.png
>   http://bambi.otago.ac.nz/hamish/grass/r.proj_methods_BCYR.png

> changing the rules to FP ranges makes the banding disappear, but
> introduces new color artifacts due to meaningless inter-cat values.

Interpolation (bilinear or bicubic) doesn't make sense for discrete
categories.

> any reason r.proj forces FCELL output?

Probably to conserve memory.

-- 
Glynn Clements <glynn at gclements.plus.com>