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

[Morten Hulden]

Glynn Clements wrote:

> A tile-based cache will work for all practical cases; you just need to
> ensure that the cache is large enough. In practice, this means that
> you need enough space for all of the tiles corresponding to a single
> output row.
> 
> Even in the worst (practical) cases, you will only need memory
> proportional to the size (width or height) of the source map, rather
> than its area.
> 
>> Hmm... I guess this is what you mean with performance 
>> overhead.
> 
> No. I was referring specifically to the design of the segment library,
> in particular:
> 
> 1. Tiles can be any size. The size isn't fixed at compile time, and
> isn't constrained to powers of two, so you have to perform two
> division/remainder operations to convert an (x,y) pair to a segment
> number and offset. If you use powers of two, you only need to use
> shift/mask operations, which are faster; using a fixed power of two
> would be faster still.
> 
> 2. Each cell lookup requires a function call. It may be more efficient
> to implement the "fast path" (where the requested cell is already in
> memory) as a macro.

What about splitting the output area into temporary smaller chunks and 
using r.proj's built-in cropping of the input map, then r.patching the 
chunks into a larger output map?

Of course, this can be done manually even now, but since most of the 
code is already in place, it could be a relatively easy solution.

> Gerald Nelson wrote:
> Is there any possibility that r.proj could become a front end for gdalwarp; essentially doing the steps I did manually behind the scenes?

I guess one reason people still want to use r.proj is because the output 
maps will be aligned and have exactly the same resolution as the current 
grid, and thus be available for further analysis together with other 
maps of the location with the tools that require all maps to have same 
grid.

The scopes of gdalwarp and r.proj are slightly different.

Morten