[GRASS-dev] Re: [GRASS-user] problems using r.proj with large
hamish_nospam at yahoo.com
Tue Dec 19 07:44:49 CET 2006
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:
these are the same rasters, the two images show different r.colors
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.
% 0 255
changing the rules to FP ranges makes the banding disappear, but
introduces new color artifacts due to meaningless inter-cat values.
% 0 255
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
any reason r.proj forces FCELL output?
More information about the grass-dev