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

[Hamish]

Glynn Clements 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.

(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

these are the same rasters, the two images show different r.colors
rules.

WRT "banding". I suspect this is like the first image- it is just an
artifact of using category based color rules with a FCELL raster map.
Unknown values -> white, exact "plateaus"-> original color rule.

#ORIG rules:
% 0 255
0:255
1:0
2:200:0:255
3:241:185:255
4:60:190:217
5:197:235:244
6:98:171:116
7:246:200:110
8:185:150:83

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

% 0 255
0:255 1:0
1:0 2:200:0:255
2:200:0:255 3:241:185:255
3:241:185:255 4:60:190:217
4:60:190:217 5:197:235:244
5:197:235:244 6:98:171:116
6:98:171:116 7:246:200:110
7:246:200:110 8:185:150:83


WRT the bug Glynn found, the above issue hides the bug, but in the
second false-color image you can see that the fixed bilinear method more
closely matches the cubic method. (this is much more obvious if viewed
with xganim)


any reason r.proj forces FCELL output?


Hamish