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

[Glynn Clements]

Dylan Beaudette wrote:

> > Assuming that it works out okay, I'll probably end up merging
> > r.proj.seg into r.proj, with the macro handling the details of whether
> > to read from a tile cache (large maps) or from a single block of
> > memory (small maps).
> 
> This makes sense. For small maps is it much faster to not use the cache?

I haven't performed timings; to be of much use, they would need to be
done with "real-world" cases.

As it stands, even if you made the cache large enough to hold the
entire map, it would currently get written out to a temporary file
then read back in on demand.

There's bound to be some overhead to using an extra level of
indirection, but it's probably trivial compared to the projection
calculations (and particularly compared to bicubic interpolation).

One of the next things which needs to be done to r.proj.seg is to add
an option to set the cache size. Once that's done, I'll look into
trapping the case where the cache can hold the entire map, and
eliminate the temporary file in that situation.

> > Consequently, r.proj.seg will tend to enlarge null regions slightly
> > when using bilinear or bicubic interpolation, whereas r.proj tends to
> > fill them in (with values whose accuracy is rather dubious). If you
> > want null regions filled, run r.fillnulls first.
> 
> Indeed. Was this a 'documented' feature?

AFAICT, no. The word "null" doesn't appear in the r.proj manpage.

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

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