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

[Dylan Beaudette]

On Monday 18 December 2006 13:07, Glynn Clements wrote:
> Dylan Beaudette wrote:
> > Interesting work Gylnn. Not having tried your module yet, I am wondering:
> > does the segmenting result in any sort of artifacts in the output raster?
> > i.e. I have seen artifaces related to segmenting with the v.surf.rst
> > module before, when optimal settings are not used.
>
> No. The projection algorithm is unchanged; the only difference is in
> the mechanism used to retrieve the contents of a specific source cell.

Great.

> The normal r.proj essentially does:
>
> 	FCELL val = ibuffer[row][col];
>
> OTOH, with r.proj.seg the code is more like:
>
> 	typedef FCELL block[BDIM][BDIM];
>
> 	#define HI(i) ((i) / BDIM)
> 	#define LO(i) ((i) % BDIM)
>
> 	...
>
> 	block *b = cache->blocks[HI(row)][HI(col)];
>
> 	if (!b) /* block not in memory */
> 		b = cache->blocks[HI(row)][HI(col)] = read_block(cache, row, col);
>
> 	FCELL val = b[LO(row)][LO(col)];
>
> The above isn't actual code; for a start, BDIM is a power of 2, and
> the HI/LO macros use shift/mask instead of division/remainder. Also,
> the details are hidden inside macros to simplify the application code,
> which actually looks like:
>
> 	FCELL *p = CPTR(cache,row,col);
>
> The main point to note is that interpolation isn't affected by segment
> boundaries, which I suspect is probably what was happening with
> v.surf.rst.


Ok, this was my main concern (unfounded it seems).

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

> Actually, there is one minor difference in the observable behaviour of
> the two programs. r.proj.seg doesn't include the half-baked
> null-handling hack used by r.proj for the bilinear and bicubic
> methods; it just propagates the nulls.

Interesting. I am rather new to r.proj, as I have used gdalwarp for everything 
until now.

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

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

Cheers,

-- 
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341